How to Become Outcome-Driven in Product Development. Part 4
Welcome to part 4 of our series on product development. If you haven't checked out the previous sections of this series and would like to learn more about product discovery and how it impacts product excellence, you can view those sections here:
- Part 1 - Product Discovery Fundamentals
- Part 2 - Make Better Product Decisions with Continuous Discovery
- Part 3 - Drive Product Success with OKRs
Let's dive right into where part 3, the importance of OKRs in product development, left off.
The overarching theme we’re covering in the series is how product teams can successfully gather around and accomplish truly customer-focused, impact-driven products that answer real, pressing business needs—with as little lag time as possible. When you use OKRs (Objectives + Key Results) as an overarching goal filter for creating products, you can reduce the lag time between what your customer needs (pains) and actually delivering the product that fills that need - even if they’re not yet aware of that need. With OKR goals harnessing the energy behind your team’s efforts, the next step is to fine-tune and drill further down to create an outcome-driven product roadmap.
Of course, you know that product discovery is not an event, but a constant process. Devising a product roadmap can help you get there with fewer time-wasting detours and pit stops. A product roadmap that focuses on the impact and outcome a product should bring, rather than just the individual features, helps your team create products that people will actually use, and love.
What is an Outcome-Driven Product Roadmap?
A release plan is not the same thing as a roadmap. A release plan is a list of features and dates. A roadmap is a document that is intended to communicate the strategic direction of the company and how to win the market (goals, outcomes).
A product roadmap is a critical piece of communication; a shared vision of the focus, timeline, priorities, progress, and, ultimately, the impact of the product you’re creating. The objective of the roadmap is to ensure that everyone in the organization is on the same train, heading in the same direction, based on both short-term goals and long-term goals surrounding how a project is to be developed. It ties directly into organizational high-level goals and product discovery - meeting the business mission, vision, and strategy, while continuously iterating on the product to solve real user pains.
So, a strong outcome-focused product roadmap will include a clear statement of the impact ("Objective") the product should achieve. Your objective from the OKRs goal-setting sessions can guide you here. The roadmap will then clarify the "Key Results" for each phase of the project, including deliverables, timelines, and expectations about what impact your product should achieve, and why. This is incredibly important. Your “why” here should be focused on the relief of a customer's pain point, without alleviating the pain, your product will not fulfill the long-term business need that's required for a long-term competitive advantage. It's also critical to point out that this type of roadmap changes as feedback from product discovery is collected and implemented into product development. Roadmaps are not fixed plans, they need to be dynamic to truly guide product teams in creating products of excellence.
Here is a template for an outcome-driven roadmap from Denver Startup Week. You can find the full presentation here.
Why Do You Need a Roadmap?
Unfortunately many companies really only have release plans. They try to predict the impact of features months in advance, even though teams rarely deliver as planned, and the features rarely have the needed impact. Companies that don't measure and look at the strategic objectives are shipping features blindly, without delivering any business-to-product value.
An outcome-focused roadmap provides a compass that points you in the right direction. Outcomes measure changes in user behavior, and if the feature that was shipped produced no desired outcome, you are able to measure, improve, and iterate to success. After all, what gets measured, gets improved. This also allows teams to reduce time-wasting detours and use resources carefully to drive activities that provide continuous results.
Jason Doherty, a Technologist and Product Leader, spoke at Denver Startup Week on how to identify if features actually drive value:
- What success looks like for each feature
- How do you measure success
- Measure it
Outcomes are impacts of our features, they need to be:
- Aligned to company goals
- Customer focused
A product roadmap is an essential tool for product teams to bring all levels of the company together under the strategic objective. It is highly visible and clear. It helps different stakeholders across the organization understand the primary vision the product should achieve. Various teams can see where they fit into the strategic roadmap destination and know what part to play in making it a reality. This helps them make day-to-day decisions that logically keep them progressing toward a higher-level destination. It also provides clear visibility for executives and creates both excitement and momentum that moves the organization towards the real objective: creating significant business impact by solving your customers’ problems, and even problems the customer didn’t know they had.
An impact-driven product roadmap communicates clearly the why, who, and how of daily product work, thereby unifying the entire organization in the right direction. We might even extend this a bit further and say that it also allows teams to predict where the product will need to be in the future based on user feedback + shifting environmental forces, it will allow you to confidently build for tomorrow, instead of only meeting pains today.
How a Roadmap Fits into Continuous Discovery
A lot of product teams are already accustomed to the continuous discovery loop in one way or the other. Whether it’s pushing updates out on a daily or weekly basis out to the customer, or you downloading updates for apps on your phone, you’re already part of that continuous discovery system. Code deployment and customer feedback are like the blood pumping through the heart each day. Feedback loops are short and quick. Progress toward the objectives in OKRs can be measured almost immediately. Key results can be measured quickly. Developers can immediately react to this feedback with new code and deploy it within hours or days, not months. An outcome-driven product map views all of this data as signposts along the road to the objective = creating products users love by resolving user pains. User feedback for products and new features are vistas and mile markers telling you whether or not you’re still going in the right direction or need to change course.
Naturally, there will be bumps in the road, and it requires drivers (stakeholders, product teams) to be incredibly responsive and agile to shifts and changes in customer feedback. But it does drastically reduce lag while delivering faster value and impact.
Who Uses the Product Roadmap?
Roadmaps are for everyone in the organization because the success of the product impacts everyone in the organization. And while the overarching objective of each roadmap should be the same, naturally, different teams will be responsible for different short-term goals along the journey, and each team will be able to synch its efforts to its counterpart teams along the way, all under the same objective of creating true value for the customer. Some examples of roadmap variations include:
A Leadership Roadmap
A leadership roadmap is very heavy on the “why” - the central objective that rallies all members of the organization together under one vision. Of course, the why, again, is entirely customer-focused, not product or feature-focused (solving business problems vs. solving user pains). It’s not about removing things from orbit, but putting things in their right places in orbit. The sun in the center is the "why" (customers' needs), which will be determined based on continuous customer feedback from discovery. All other planets rotate around this “why” and the roadmap marks milestones along the orbit to relieve customer pain points quickly and effectively through the creation of amazing products.
Roadmaps for Product Managers
Product managers need a more granular-level roadmap that enables them to keep teams focused on making effectiveness and efficiency flow through their work. It should facilitate communication that connects related teams under the same objectives and key results (OKRs again). It keeps the big picture front and center so that team members can spend their energy on high-priority tasks, helping them avoid getting stuck in the weeds with scope creep. This speeds up the decision-making process and helps eliminate the lag between the product and the customer.
Development Team Roadmap
If your team uses an agile methodology, the “sprint” roadmap is a helpful schema for the development team. Each sprint focuses on activities centered around resolving specific customer pains, not just creating features. These sprints are marked on a timeline so that progress on the roadmap is easy to measure and track via milestones and target dates. Again, the focus of such roadmaps is the “why” more than just the “what”. All features need to show how they will improve the life of the customer. We will elaborate more on this in part 5.
The Difference between Feature-Driven vs. Outcome-Driven Product Roadmaps
If you ask someone what a product roadmap is 9 out of 10 times you'll hear it's a list of features and future release dates. And while features and dates are included in roadmaps, the point of why we even have a roadmap is missed in the casual definition.
Anthony Accardi, CTO of Rue Gilt Groupe, an online flash sale e-commerce platform said "An effective roadmap retains that context of " Here's why we made these decisions, and here are the assumptions we're making." And yet, many roadmaps leave all this rich information out to make room for feature lists, bugs, schedules, etc. Productboard calls this style of roadmaps "a legacy of days of lengthy waterfall projects".
Features are outputs. They are the results of specific changes your team has made to the product, with hopes that it has improved things for the user and organization.
Outcomes are the improvement piece the team hopes for from the output. Outcomes are the driving reason why there is even a roadmap, and they should be clearly defined, tracked, recorded, and worked towards.
The caution here is that, most roadmaps assume that (we, you, they) know what the outcomes are and choose to pack the roadmap with features, bugs, schedules, etc. But that's not a roadmap anymore, that's a release plan. Even if you have the outcomes stored somewhere in your mind, and you verbally discussed it with your team or maybe it's on a Google slide, but by not seeing outcomes as part of a product plan, you tend to forget what you are working towards and end up building functions and features that aren't aligned with goals but rather are just a check off the list.
This is known as being feature-driven. A list of features can create a myopic vision that misses the impact you’re trying to make by miles, according to Adam Bennett at Product Led Alliance. Having a board of features that drives your product teams should also signal that you're solving problems the business is having, and not really listening to what users need solving. This is a common pit some of us fall into especially in times of market uncertainty. But the red flag is that feature-driven roadmaps remove the focus from the customer, placing it on features that may or may not actually be useful. The landscape for a customer may have changed and you need to be agile enough to respond to their needs, but if you’re too busy focusing on features, you may miss that critical opportunity to create big, helpful value that elevates and relieves your customers and fulfills their developing needs.
This is why basing your cartography on an OKRs foundation can help you create outcome-focused strategies that give you the flexibility to respond quickly to user pains while also providing concrete timelines and products that answer those objectives and deliver key results.
What good is a great feature if it’s not something that can help your customers? Centering on outcomes, guides you to create a product that really delivers relief. So how do you step away from a feature list?
Here is an example from Productboard on outcomes.
How to Build a Successful Roadmap
True leaders ensure that product management is not a black box. Roadmaps are strategic tools - this is how you build transparency and communicate what's next for the product. They're dynamic visualizations that are closely linked to product strategy and are the beacons product teams work toward.
Here's how you can begin. ↓
1. Align on product vision, strategy, and objectives
Product Vision -
An overarching goal you are aiming for, the reason for creating the porduct.
Product Strategy -
A clear outline of what you aim to achieve. The plan to bring your vision to life.
Clear, and measurable goals aligned to specific outcomes you're striving to achieve.
Of course, this sounds easier than it is, even if you’ve crunched solid data from reliable sources and have a good idea of what your customers really need. There are a lot of voices to consider, even then. One way to help align the product vision is to anchor it to the organization’s objective (in an OKRs framework). By aligning the product’s vision to the higher organizational objective, there is less friction when teams work together, as everyone should be on the same page, working in the same direction. Each team roadmap should then be able to demonstrate the work done, on a timeline that aims directly at the overarching objective by reaching milestones that show key results. As this part of the product roadmap comes together, all tasks should align back to the main goal and the responsible teams should be able to show accountability for their part in the plan.
2. Prioritize what to put on your product roadmap based on outcomes
- Insights from prospects, colleagues, customers
- Market segments that your product serves
- Date-based milestones, such as conferences, industry events, marketing campaigns
- Capacity planning (whats the bndwidth of your team)
This is where the roadmap starts to become more tangible, and where visibility helps teams stay anchored to the objective. Each action needs to be prioritized in order of importance, as well as what things have to happen before other things can happen. The truth to remember about prioritizing tasks is that there is always an opportunity cost involved. The trick is to prioritize the tasks that bring the most impact and get you the closest to the key results you’re aiming at. But it’s not always easy to determine that without some kind of prioritization framework. Fortunately, there are a collection of different prioritization frameworks you can choose from. Productboard lists the 6 most well-known, which are loosely defined here:
- Value vs. Complexity Quadrant—Simple, but effective, a Value vs. Complexity quadrant uses data to plot tasks where value is always higher than complexity. This naturally accelerates the process of checking off tasks, but it can get complex if you’re working on a fairly mature product with a lot of features.
- The Kano Model—Created by Japanese professor Noriako Kano, this framework prioritizes customer satisfaction data on a y-axis from “frustrated” at the bottom to “delighted” at the top. The x-axis plots functionality from “none” on the left to “best” on the right. The goal is to prioritize tasks so they aim at the “best-delighted” area of the quadrant.
- Weighted Scoring Prioritization—This method uses a list of “drivers” (parameters) ranking the importance (ability to reach the objective) of each potential feature on a scale of 0% to 100%. The closer a feature comes to the 100% mark, the higher the priority.
- RICE Framework—This framework scores features or tasks for prioritization based on 4 criteria: Reach (how many people will the feature affect: e.g., how many users per month), Impact (a 0.5 to 3 score based on the impact on the individual user), Confidence (how confident are you in the accuracy of the data you’re using to base product decisions on), and Effort (how much time will go into creating the feature on a person-per-month scale). Reach, Impact, and Confidence scores are divided by the Effort score to come up with a priority rank value.
- The ICE Scoring Model—A simple, fast “growth hacking” priority scoring model popularized by Sean Ellis, ICE gives a 1-10 score for Impact, Confidence, and Ease of production. While it’s light on research, its speed makes it attractive.
- The MoSCoW method—This agile product delivery framework prioritizes potential features into four categories with a timeframe attached. The acronym = Must have (Mo), Should have (S), Could have (Co), Won’t have (W). Obviously, based on customer data, the “Must have” items have top priority on the roadmap.
- Opportunity Scoring—You may have heard this called “gap analysis” too. You ask customers to rank features on a 1 to 10 scorecard based on two key questions: How important is this feature (Importance)? How satisfied are you with the current tool you’re using (Satisfaction)? The higher the importance score ranks against a lower satisfaction score shows you where the opportunity lies.
You might try a combination of these priority ranking frameworks to populate your roadmap with features that point directly toward the main objectives you’ve identified through good customer feedback.
3. Cast a Wide Data Net
Getting good, solid, non-biased data about what your customer base needs is important. Unfortunately, there’s often a groupthink bias that can blind even the most talented teams into diving down rabbit holes that don’t lead anywhere. This sort of bias can be broken with outside help and good data. Often, the outside help comes from getting a lot of data and feedback from the widest range of stakeholders and customers, not just the biggest or loudest of them. Keep in mind, the smartest person in the room isn’t always the loudest person in the room. In fact, they may not even be in the room. Who needs to be considered when talking about the outcome? A broad spectrum of customers. Bring them in from the beginning of the process. A customer-centric product development loop requires user input. Then verify and evaluate the data and try to remove internal bias so that you know you’re making real outcome-based decisions from solid data from customers, on a consistent loop (discovery).
4. Identify Problems and Solutions
Identify your customers' biggest problems and look at how you can solve them, based on the metrics you’ve outlined so far in your plan. The priority should always be on the solutions that create the biggest, most meaningful user value. In order to do that, you need to be in constant contact with your customers, understand their needs and their frustrations and be ready to help. It’s also useful to keep an eye on your competition during this phase. Where are they lagging, and what are they getting right… and how can you do it better?
5. Set Goals and Anchor them to a Timeline
For agility, you’re not looking at annual goals here. The impact has to be determined and measured rapidly, as the continuous discovery/delivery loop runs. Define goals on the roadmap regarding what is being developed, who is responsible, how you’ll get there, and tie it to a month or a quarter goal, tops. Again, you may have to adjust the steering wheel sooner than that, especially if you’re responding quickly to customer feedback and needs, always heading in the direction of solving user pains. That’s always the “why”, and it should be tied to higher business objectives.
6. Keep Stakeholders and Teams Aligned on the Roadmap
There’s no way around collaboration in a successful outcome-driven roadmap. And yet, realignment is always happening. It’s easy for teams to get distracted, especially if they’re stepping into an agile framework from a previously top-down system. Old habits are hard to let go of in some cases, so constant steering according to the roadmap is just par for staying on course. It’s so important to always tap teams that interact with customers directly for their feedback and sense of direction, as they are usually the first to hear about how customers are feeling about things. This helps you make market-driven steering wheel corrections and establish alignment around the goals.
7. Constantly Measure Key Results
Understanding whether or not you’re reaching your primary objective on the roadmap relies on clearly defined metrics for your key results. Making sure that as you reach destinations on the roadmap, you can answer these questions:
- What is the long-term impact? (Example: Increase hourly sessions by 70% by the next quarter)
- How is the impact going to be measured? (Number of hourly sessions)
- How will we update and communicate the progress towards these key results?
Constant communication and touch points with teams, customers, and stakeholders as the roadmap progresses are key to ensuring that you reach your desired outcome: great impact for the customer.
The Spark Equation team is a big believer in outcome-driven product roadmaps and we have worked with many clients on helping them achieve their OKRs based on clear, straightforward roadmaps that focus on impact. We help clients progress along their desired trajectories every day through deep expertise engineering, objective-based product strategies and consulting.
Want to learn more about how to create your own outcome-driven product roadmap? Chat us online or send us a message and we will work with you in creating an impact driven roadmap.