When I built my product management course for the Adelson School of Entrepreneurship at Reichman University (formerly IDC), I wanted to make sure that the students don’t only hear the material but also experience some product work, to make sure that they truly learn. However, teaching product management to students who most likely never had a real job before, let alone saw the inside of a tech company, is quite challenging. I consulted with a training expert to think about creative solutions that can on one hand be taught in a classroom without too much context and on the other hand deliver some real product management experience.

Lesson #7 was about writing requirements. Before getting into the nitty gritty of the format and what needs to be included in each user story, I wanted to convey the complexity of giving clear requirements. I thought of showing them the video of the peanut butter and jelly sandwich making exercise, but that would take them too deep into defining and explaining every little detail, and I wanted to convey a slightly different message. So I decided to start with a different exercise: I asked for two volunteers and gave one a simple line drawing. They would need to give instructions to the other to draw it on the board. In this class, the first volunteer needed to record full instructions and hand them to the other volunteer, while in the following class I did it again but this time allowed them to give the instructions in real-time – that helped me with demonstrating the power of agile.

I ran this exercise a few times, and regardless of the method I saw two types of instructions: some of the students started by giving context and explaining the bigger picture: “we are going to draw a boat”, while others dived immediately to the details of what needed to be painted: “draw the lower half of a circle”. Those who didn’t give context (for some reason, although I didn’t say anything about it, they thought it was not by the rules) had to supervise every little detail that the other student was drawing. They couldn’t refer to the boat parts such as sails, bow, hull, and mast as part of their instructions, because they didn’t create this common language and context before. The fact that they were instructing the other student to draw a boat was left entirely in their head, and they needed to do the heavy lifting to make sure the result is satisfactory. Unsurprisingly, in most cases, it wasn’t. The students who first said that we are going to draw a boat got much better results, and the outcome drawing, while maybe not 100% similar to the original drawing they got, was always a boat nonetheless.

I always say that you must give as much context as possible when you write requirements, but that’s the easy part. The same principle applies when you are building your entire roadmap, and that’s not always as easy.

Discuss the What and Why First

Roadmap discussions are a common topic in the CPO Bootcamp. As product leaders, you need to both facilitate such discussions with your team and contribute to and even own the same discussions with senior management. Oftentimes, when asked to prepare roadmap candidates, I see both product leaders and product managers immediately dive into the backlog and start picking up features that are worth discussing. Even product leaders who are usually very strategic get confused by the term roadmap, due to a common misconception in which roadmap means work plan. 

But the roadmap isn’t a work plan. It is – as its name suggests – a map. As a product leader, you should highlight the right path on the map, the one that will lead you to your goals. Many companies don’t bother discussing goals clearly, and that should be the first thing you do when you prepare your roadmap discussions. But even when the goals are clear, don’t dive right into the features. Discuss with the team – both your product team and the management team – the best path to get to the goals. Debate alternatives and priorities. 

Since the roadmap isn’t a work plan, roadmap candidates are not features. Instead, they are the bigger initiatives and sub-goals that you want to work on. These can be things like making your product enterprise-ready (which has many features in it), or better yet – setting a sub-goal of selling to at least 5 enterprises by the end of H1, and thinking what it would take to get there. Other candidates can be things like reduce onboarding time, improve retention for a certain customer segment, increase conversion rates to the premium plan, and many others.

Make the Roadmap Discussions Work for You

The roadmap discussions are not only something you need to get through in order to get to the desired outcome – a roadmap. The discussions are an important tool that serves you in and of itself. Here are a few ways in which keeping the roadmap discussions at the higher level mentioned above can help you as a product leader:

Discuss what matters most first. Like in the rocks, pebbles and sand story, if you want to make sure your roadmap sets you in the right direction to meet your goals, you can’t start by discussing all the features. You won’t be able to see the direction this way. Moreover, since the roadmap isn’t a work plan, it doesn’t need to include every feature you will be working on. It needs to show the way, features will follow (and will most likely change).

Keep your roadmap stable. One of the things that often creates tension between product and management is that management sees the roadmap as a commitment while the product team knows it will change for sure. As a byproduct of the previous point, keeping the discussions at a higher level and keeping features out of them at first (they should come in later as examples of what you are going to do for each outcome), allows the roadmap story to remain fairly stable over time. Features change a lot, strategic priorities not so much. 

Create a common language. Like with the students who first explained that we are going to draw a boat, discussing the roadmap at a higher level gives you the tools to discuss it differently. Once you say you are going to draw a boat, you can refer to the boat parts by name, and it is also clear to everyone which parts might be missing from the drawing. Similarly, talking about clear goals and desired outcomes allows fruitful discussions and a point of reference for any decision you would be making in the future. That’s the real purpose of the roadmap anyway, isn’t it? 

Context gives you freedom. Last but not least, a major advantage of having the roadmap discussions at that level is the level of freedom that you can give your people in working on the details of the roadmap later on. If you have created the general path to the goals, you can then assign each team a specific outcome and let them figure out the best way to achieve it. It doesn’t mean that you can avoid monitoring it altogether, but it definitely means that you don’t need to figure out all the details by yourself. Even more importantly, since you have explained how the bigger picture is made out of smaller parts (but not the details), now each part can be broken down independently into its own details. Even if one of the details is not 100% right, it doesn’t risk the entire picture, only this specific part.

Going back to the boat story, keeping the roadmap discussions at a higher level serves as your anchor: once you have cast it in the right place, the boat can still move (and it’s important otherwise it will need to fight the current), but it will generally stay where you want it to be nonetheless.