If I asked you what currency your company trades, how would you respond? Australian Dollars? Labour Hours? Product Value? Leaving the literal answers aside, every company trades their knowledge, expertise and their ability to fulfil their customers’ needs. In this article, I'll focus on building your currency's value through the concept of a 'product roadmap'.
What is a product roadmap?
To begin, we'll observe Atlassian's definition of what a product roadmap is. "A product roadmap is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time. It's a plan of action that aligns the organisation around short- and long-term goals for the product or project, and how they will be achieved."
My observation is that this is essential to your business, even if you were to replace the word product with service.
The reason a roadmap is essential is not the artefact itself. Rather, the importance is the organisation's alignment to the roadmap. A roadmap created in a vacuum will be useless to you, your team and your customers. The process of creating a roadmap forces the leadership team to articulate your goals and strategy clearly, ensures it's solving your customer's needs and stops stakeholders from misaligning on priorities.
What should the roadmap look like?
No single format works for everyone. The roadmap should reflect the maturity of your business. A startup’s roadmap could be a whiteboard with some post-it notes, whereas an enterprise may be documented in a report and recorded through a presentation.
Tip: 'The format is less important than key stakeholder support.'
The typical format is product categories on the left and milestones on the right, as per the image below
You’ll notice in the graphic above that the product roadmap isn’t created at day 1. That brings us to our next point.
When shouldn't you build a roadmap?
There's one critical time when you shouldn't build a roadmap. That time is if you don't have an active and engaged customer base (ie. you don’t yet have a product or you don’t have users). In this scenario, you should have a set of hypotheses your project is trying to validate or invalidate. You can still use the roadmap process to create alignment on your present hypotheses. The difference is that you will be pivoting your product too quickly for a maintainable roadmap. What’s the point of strategising 10 months from now if a learning 1 week from now could significantly impact the future of the product?
Product Stakeholders
So, who are the product stakeholders? Simply (and broadly) a product stakeholder is anyone who influences the direction or value of your roadmap’s elements. These will be different for every organisation. The key groups you may wish to consider are:
- Customers
- Customer-facing groups: sales, marketing or customer support.
- Investors, board or sponsors.
- Architect, engineers and designers.
- Human resourcing.
- Legal.
Creating Alignment With the Roadmap
When people are involved in shaping something, they feel ownership. Let’s face it, the best idea is your idea. If you include stakeholders early, ask them for feedback and keep them updated, you will increase momentum. Successful roadmaps have three things in common:
- They’re based on a sound strategy.
- Realistic.
- Fully supported.
One of the most common failures is shortcutting one of these factors. This often comes back to leadership. If you are not the leader of the business but are accountable for the roadmap, a founder or CEO will likely impact the process.
The reason is that the founder or CEO usually knows a lot about the market and has an innate sense of what has worked in the past and what will work in the future. It would be best if you channeled your leader's passion and energy into the process otherwise you risk changes at the 11th hour, flawed assumptions, a lack of alignment (some people will try to undermine) and ultimately, a roadmap that doesn’t carry any importance.
Similarly, lack of buy-in at the operational level can be detrimental if leaders are dictating the product to their employees.
To mitigate:
- Spend time with all stakeholders at the beginning of the process
- Ask for the CEO’s ideas and the most critical development projects. Ask for their underlying thoughts.
- Explain the importance of including other stakeholders.
- Run the process quickly - ask the CEO to choose who to be involved with the product development.
- Once you've done this, it's now a plan that has buy in at the top level of the organisation. Be sure to keep stakeholders updated throughout the process.
The currency of a roadmap is customer knowledge.
The more customer knowledge you can gather before commencing the roadmaps process, the easier it will be to align stakeholders.
The best way to arm yourself for the process is with direct qualitative research directly from the customer. The different ways you can do this are:
- Initiate a research group.
- Ask customers yourself
- Participate in sales or customer service meetings.
- Reach out to the customers directly and ask them for a few minutes of their time.
- Observe them using the product.
Good questions to ask:
- Why did they start using the product?
- What were the other market options they reviewed?
- Why do they continue to use the product?
- What they wish was different?
You will know when you've completed enough customer interviews when you can predict the answers to their responses. Usually, this is about five times.
For more information on how to do user interviews check out: ‘What are user interviews and why are they important?’
The Process
Okay, that's the background information completed. You are now at a point where you can start the process. Here's a quick summary of what to do at each stage.
Product Strategy
You can't evaluate a roadmap without understanding the strategy. A product strategy describes how your company will achieve its business goals. It would be best if you discovered the answers to these questions:
- What are the business goals?
- How will you measure success?
- What benefit do you provide your customers?
- Who are your competitors?
- What differentiates you?
- Who are your customers?
Write down the answers to these in a brief document. The business leader should feel like they own this in order to promote and defend it.
- Discuss your strategy with product stakeholders and document learnings.
- Start with 1on1 meetings.
- Have a group meeting.
- Refresh if you need more alignment.
- You are now ready to start building the roadmap.
Identify milestones
Now it's time to identify your milestones. You are the best person to start this process. Create version 1 considering the following:
- What are the barriers?
- Understand your customers decisions.
- Reread your product strategy.
- Research the market and your target customers.
- Try to imagine the product evolution.
Milestones can be impactful in different ways. For example one milestone may focus entirely on small changes and quality improvements in order to reduce churn, whereas another milestone may be entirely focused on feature development.
Record the strategic objective each milestone supports and its rationale. Now, meet with your product stakeholders, 1on1.
- Review the strategy and ask for their ideas.
- Review your ideas.
- Merge the feedback.
Estimate Effort
It's time to seek feedback from your product or engineer team. Clarify that these will only be estimates and may change as more is discovered. If some milestones are small, consider merging them together.
Table them out: Milestone name, strategic objective, summary, source and time.
For different techniques on software estimations check out our article on scientific software estimates.
Build the Strawman
The strawman is the first sequence and schedule with the milestones. Use the estimations and place them on a timeline as per priority depending on your product team's capacity.
Now, sanity check-it. Does it implement product strategy, and is it feasible?
The product roadmap meeting
Finally, you have your first roadmap. Now, it's time to check alignment - get everyone together and review. Plan and run the meeting with all business leaders.
- Explain the goals - emerge with a shared product roadmap that everyone supports.
- Quickly review the product strategy (if there is no alignment, do not continue).
- Review the development capacity and estimations.
- Walkthrough your product roadmap strawman.
- Ask the team what they wish was different.
- Modify the roadmap directly in the meeting (show everyone the trade-offs).
- Think about future success.
The best case is that you have a consensus. If there is misalignment, the business leader often decides the direction, but everyone should publicly support it.
Evangelise the roadmap
It's now your responsibility to ensure the alignment flows down the organisation. To do this create a short presentation that shows:
- Top-level objectives.
- Target customers.
- Competitive advantages.
- Show the diagram.
- Include rationale.
Present directly with people who are impacted by the roadmap. Check for alignment. Is there something we need to revisit?
Now, roll it out to an inclusive meeting. Ensure it is 10-20 mins max and try for a public Q&A. Always present the roadmaps as a team effort. Make sure the company has a way to share the roadmap with customers.
Maintain the roadmap
Update the roadmap when you've learned something new. New info could be:
- Customers needs/desires have changed.
- Competitor information.
- Development time and cost of product development.
Try to understand the reasons for the change. What's the new information? The decision on when and why you're updating the roadmap is your responsibility.
What's Next
- Spend time with customers.
- Spend time with product stakeholders.
- Build your first roadmap.
- Keep your roadmap relevant.
The information outlined is this article was recommended as part of Project Management Institute’s (PMI)® Product Management: Building a Product Roadmap Head over to Linkedin Learning if you would like to complete the course in full.
