How to lead your product – Part 2: Problems and roadmaps

I recently covered the first part of how to lead your product, with a focus on how to bring others along in uncovering insights from your User Research. You can do this with activities like affinity mapping, where you and your team work together to identify common themes emerging from your research, rather than giving them a fully baked user research report to read about your findings. If you’re interested in learning more about this topic, you can read How to Lead Your Product: User Research, you can do that here.

The next part of the series discusses how to lead your product by keeping calm in the problem space, before jumping to solutions.

How to lead your product: keep calm in the problem space

There is an opportunity to lead your product in how you handle requests from users and from stakeholders. One approach is to spend time transforming those requests into user stories and features (should it make it on your roadmap?). A better approach is to pause and spend time understanding the problem behind the request. Perhaps there is a more effective solution out there, or perhaps the problem isn’t that problematic and doesn’t need to be solved.

This questioning piece is leading your product: you are getting at the real problem statement behind that request. You are driving to uncover assumptions that need to be validated to prove that it’s a real problem, and that the solution brought to you is indeed the best approach to solving the problem.

One way you can help your team spend more time in the problem space is by conducting a molecule map exercise. This forces a list of features to instead become a group of molecules, each feature linked to a specific problem for a specific type of user. This makes it easy to visualize when a solution is disconnected from an actual problem experienced by an actual user.

Let’s return back to our Chefs on Demand product that we covered in How to Lead Your Product: Leadership and Management. This is a mobile app that enables users to find a professional chef in their area to come to their home to cook a meal. We have a ton of feature requests coming in, but it’s unclear who they are for — the chef? The person booking the chef? And it’s unclear what problems are being solved, and if they are even real problems.

By going through this exercise, you are positioned to better define the problem, see if there is another problem behind it, or come up with alternative solutions. You do this by connecting the persona to the problem to the solution.

Here, we’ve turned the chef profile feature request into the following molecule map, where our chef profile solution addresses the problem of clients wanting to learn more about the chef before booking. With this, we can start to ideate different solutions to that problem. We can also start to explore deeper root problems, like maybe it’s actually that clients don’t feel comfortable with a stranger in their home, so how could we make them more comfortable?

This helps us slow down a bit, and not become an assembly line pushing out features from every request that comes in.

The next part of this series discusses how to lead your product in the context of the product roadmap. In other words, how do you lead others in engagement and excitement for the product roadmap?

How to lead your product: The Product Roadmap

Ask yourself: do you spend more time driving the execution of your roadmap, or creating excitement and alignment around your roadmap? A predominantly management mindset looks like driving the execution of features, tasks, and bug fixes.

But no matter how effectively you are making progress on your roadmap, if you’re not communicating how the product or feature rolls up to larger product milestones and company goals, and if your developers don’t know why they are working on those features, then you are not bringing others along with a shared excitement of your roadmap — and you are not leading your product.

Leading your product means connecting those user stories to larger milestones and objectives. It should be clear to everyone not only what they are working on, but why they are working on it. It is also good leadership practice to give the team a role in determining the “what” based on their shared understanding of the “why”. And a huge bonus to this approach is that when engineers and designers understand how the work they are doing ladders up to bigger goals, they will actually bring better solutions to the table and help create better products.

One way to make sure you are communicating this is to have different types of roadmaps for different audiences, in order to continue to drive execution in the now, while also building continued excitement and enthusiasm for the future. A roadmap is like a product you are designing: it requires some discovery on your part to identify the needs of those who will be consuming the roadmap. The sales organization may be most interested in features and timelines, while the leadership may care more about business outcomes. So it’s important to talk to your roadmap audience and know what they are looking to see in your roadmap.

One idea to consider is using a now, next, later roadmap for your engineers and designers, where you outline the following: Now, or stuff that you are currently working on, next, or stuff that’s coming up soon, later, or stuff that you’d like to work on in the future (because further out, this can be more about possibilities than specific features). The goal is to show the timing of the work, but also to show how the work rolls up to a larger business objective.

Let’s return back to our Chefs on Demand product that we covered in earlier parts of this series. This is a mobile app that enables users to find a professional chef in their area to come to their home to cook a meal. In this example, the “Now” work listed is for product milestones: logging in, creating an account, and creating a chef profile, with specific features within, such as email validation.

In the future, we have product milestones for being able to search for a chef search and contact a chef. This work is coming up soon, but is less granular in terms of how it’s defined on the roadmap and offers more flexibility in terms of how it will be done: will chefs be searched by location? Cuisine? Will contact be an in-app chat? Or a link to email?

And even further in the future, we have a product milestone for building payments in-app, but this is very broad and with a high degree of flexibility and variability. It requires way more research to determine whether or not it will be done. This shows the larger vision, without committing to too many details early on. If this topic interests you, listen to this podcast on product roadmaps, OKRs, Vision and Prioritisation with Bruce McCarthy.

This is a good way to keep your executive team aware of your progress towards solving certain user problems, and the resulting impact on the business that you expect.

If you’re struggling to get buy-in for your roadmap, maybe try talking to your different stakeholders about what they would like to see in a roadmap. And just like a product, try not to get discouraged if it takes a few iterations to find roadmap-stakeholder fit.

Stay tuned for the final part of this series when we’ll discuss how to lead your product through communication and prioritisation. 

Discover more content on Product Leadership. Learn about Prioritised and MTP Leader membership today.