What's your process for scoping and prioritizing a product roadmap?

The idea of identifying customer needs and requirements is valid but in my understanding only to the extent of improving an existing product. However, when you are operating in the blue ocean then it's actually about creating a need. The best example is the iPhone. Simply, the customer (largely) did not even know about such a feature to even express the need for the same. However, the need to constantly know the market and competitors is always crucial, irrespective of whether you are operating blue or red ocean. Using another example from the same industry, if Nokia had not passed on the touch screens early on, they would not have had to play catch-up and eventually lose. They missed out on a newly created need of their customers.

While I agree understanding your market is critical, ensuring clear understanding and alignment of the business needs and company direction is as equally important. I've observed and had to help unravel sticking points when the (perceived) customer needs weren't aligned with the company direction. For example, the medical device startup I'm currently supporting from a product consulting and business excellence perspective was having an identity crisis of sorts. Members of the board felt that the industry agnostic device will be more successful with the Department of Defense to detect explosives and such. The company vision is focused on disease diagnostics. This was a critical step before diving into the development roadmap

In my experience, understanding your customers and market is very crucial to building a product that will address their pain points, ultimately a product they will love. Market research, building and releasing an MVP to further understand what your customers are looking for. Engage with them in various ways through interviews, surveys, data drawn from pilot testing and so on. Another angle is to look at what your competitors are doing, what are the gaps you can realise and capitalise on? What makes them stand apart and why are they the preferred choice?

I would nuance this more. Before getting into what to solve - find who to solve for. Start with identifying your target user persona / problem. Once the team / stakeholders align on that - then move forward with user research, competitors and so on to identify what exactly is to be done for solving the use case you identified.

In addition to the traditional methods mentioned, it's important to incorporate a holistic and empathetic approach when understanding your customers and market. This involves recognizing the evolving dynamics of society, technology, and culture that influence customer behaviors and market trends.

How I see it is defining the ideal state of your product. If you had no resource constraint, what would you build. This is what we can call a divergent phase where we should think expansive. This will also sell well with the team as they see the promise of what the product is. Fully agreed this has to align with the broader organisation goals.

Building on the above experience, the mission and vision was very specific with this startup to focus on medical diagnostics - identifying human health and not safety to ensure clarity around the markets we're targeting. This was an important step for company leadership to bring their dissent to the table in order to have meaningful conversations that ultimately led to a solidified vision for the company.

It's crucial for the product manager to address pain points: Align your mission and goals with addressing customer pain points or providing solutions to existing challenges. This enhances the value proposition of your product.

Vision and strategy are the guiding light for any product. They set the course and form the bedrock upon which daily decisions are made. While tools like vision statements are useful for orientation, developing a deep product sense empowers product managers to make practical decisions. It's about aligning the team, values, and goals, ensuring that everyone marches toward the same true north

Following from the vision you sold. It is important to be able to divide that ideal product into meaningful feature sets / phases. Using frameworks MoSCoW and RICE really helps. Although once you get a hang of it you'll not call it frameworks. It is basically maximising value to effort ratio. And then based on effort available you can draw a line on what your current scope will be.

Then take the highest priority items and find ways to test the feasibility, usability, and value. This will allow you to learn quickly and integrate those learnings into the full development.

When you have literally hundreds of features or functions you're needing to develop, a prioritization matrix based on weighting and consistent understanding of the criteria is critical. I use a basic spreadsheet that creates categories such as strategic fit, level of effort, number of dependencies, external factors, and overall value (for company and customers). This helps move the team past only relying on gut feel - which is a great start but can be riddled with harmful bias, on what the do next. This methodology needs to be adapted for the relevant stage of the product development lifecycle.. and highly respected. No work should go through without being scored by the calculator. This should inform the backlog and ultimately your sprints.

We have a framework that is relevant to our market, business, and users (desirability, effort, production vision alignment, reach...) All opportunities and features must be categorized by themes, outcomes, user pains & personas to ensure that the opportunities and features we identify are aligned with our product vision. With hundreds of features in our backlog, and the market is constantly changing and moving faster, we have to focus on IMPACT (for the company and the customers). Do things that will change user behavior for the better, bring value, and reduce time to value (Product value, aha moment). Each opportunity has an impact field where we can add the business value impact (€) if we choose to pursue that opportunity.

Identifying and prioritizing goals and initiatives is pivotal. Goals define measurable outcomes, while initiatives outline high-level projects to achieve them. In my experience, I advocate for the 'cost of delay' framework, coupled with WSJF, to prioritize initiatives based on value and urgency. While prioritization is essential, it's not set in stone. In the rapidly evolving tech landscape, teams should periodically reevaluate themes to ensure continued relevance, at least quarterly.

This is an important step and how you define it will eventually define the success of the product as this is where actual magic starts to happen. While the initiatives are getting broken down it is of utmost importance to ensure the focus is still on delivering the initiatives which are higher on priority and delivery higher business value to end customer. Constant feedback from the customer on the business value delivered to customer and getting that feedback incorporated into the system will help in improvement of breaking down of initiatives in more precise stories with correct estimations.

Once the outcome is defined, it is really important to get into the details to avoid any mismatch in engineering and expected outcome. Do this on doc / design / through user journey video, but explain the why and the what of the solution to your team. Also helpful to get the estimate of each task from the implementation team.

Same reference to the prioritization matrix applies. It's important to also start thinking about success criteria and definitions of done in this stage - but then plug that into a system like Jira or ClickUp to create the delivery plan. Agreeing to the method of estimating complexity/level of effort is really important at the outset of the work. Sometimes, more abstract estimation like story points can be more liberating for engineers rather than using firm hours. Hours at times can signal micromanaging. Not all teams will react the same way - consensus here is critical toward consistency and measured success.

Same as my previous comment on "Identify and prioritise your objectives and initiatives". The work is the same but at different levels.

Allocate a portion of your goals to innovative ideas that might not have immediate ROI but could lead to future breakthroughs and differentiation.

Don't forget about cross-functional collaboration. Involve key stakeholders from different departments, including engineering, design, marketing, and sales, in the roadmap planning process. Collaborative input ensures that the roadmap aligns with the capabilities and constraints of each team, facilitating buy-in across the organization. Additionally, avoid overcommitment. While it's tempting to fill the roadmap with numerous features, it's important to steer clear of committing to unrealistic timelines. Be mindful of your team's capacity and avoid creating unnecessary pressure that might compromise the quality of deliverables.

Most important thing with communication of roadmap is laying out the assumptions, things you worked on initially. Who is the target user, what's the usecase. This is important to get support from relevant teams whose main work is not to support you. It is also important to be flexible in minor details of the roadmap and change it based on any new information

In my experience from the various products that my team has delivered, it is always important that there should be time accounted in the plan for change requests. The product requirements and use cases that are approved of by the customer are based on the knowledge available at the beginning of the product lifecycle. As the product is getting delivered in multiple iterations, customers get more clarity of what they want and would like to get changes to the original plan incorporated in the timeline. This becomes tricky if you have not planned and budgeted for CRs and the schedule overruns are bound to happen.

A roadmap is a communication tool and it should always be assessed. Be on the same page with at least all the leaders. A roadmap that is only for the product team will fail. A roadmap created with the Leaders and shared with the company will be supported by everyone and your chances of success will be greatly increased. Never lock in your roadmap. Always be able to explain WHY the items on your roadmap are there. There are different types of roadmaps, such as NNL (Now Next Later), Quarterly, or Planning. I am a big fan of the NNL roadmap, but you need to be very aligned with the stakeholders (at least the leaders) and have very strong internal communication. The best roadmap for your company will depend on your specific needs and goals.

Strike a balance between short-term goals (quick wins) and long-term objectives (strategic growth). This prevents tunnel vision and ensures sustained progress.

A roadmap is a constant work in progress. Use a roadmap to validate your strategy further, and be flexible when you see opportunities or changes based on data and trends. A roadmap should change over time, and it is not healthy to plan ahead for a long-time. Make sure to leave space for experimentation within the limits of your strategy to make a bigger impact over time.

A roadmap is a living piece inside an organisation. It ties the very high level startegy to the details of features to be built. Its input is varies assumptions and decisions. Hence when any assumption or decision changes, the roadmap should reflect it. Another aspect of a roadmap is that it is a shared understanding between different departments. Hence sharing the why are we doing whatever is mentioned, is important to keep everyone aligned and move forward on the desired roadmap.

While a standard roadmap captures a linear strategy model, I suggest considering other perspectives (layers) and decision points (nodes) to incorporate into the roadmap. This approach can transform the roadmap into a more graph-like representation, allowing for more thoughtful planning, execution, and enhanced control.

Clearly communicate your mission and goals to the entire team. Everyone should understand the bigger picture and how their work contributes.