Roadmapping is at the core of product strategy and product management. As a product person, and the VP of Product at Yesware, I’ve never come to fully embrace the discussion of what each team would deliver, in what sequence and within a long timeframe. Output-focused product roadmaps provide a false sense of certainty, all while limiting product work to a few big bets, which may or may not pan out.
I want to make the case, informed by the writing of Marty Cagan, particularly his book Inspired and by learning from Teresa Torres, through her workshops and team coaching, that output or feature-based roadmapping is a thing of the past in product management. Product management is moving towards outcome-based product-planning. Rather than simply delivering features A and B, we aim to move metrics A and B.
Output-Based Planning
Output-based product roadmapping frequently looks like jostling and negotiating to sequence a given set of features over time and across several swimlanes, each representing an engineering team.
Product managers and their teams almost always inform their roadmaps based on various data, market and user insights.
Then they solicit feedback from internal stakeholders to inform planning. Different stakeholders lobby around feature proposals. Ideally, stakeholders come to the table with informed and researched perspectives as to how they would force rank feature priorities and what the features could achieve once delivered. Sometimes, they come with more instinctual suggestions or over-emphasize issues that are most top of mind.
Other times the executive team informs roadmap planning, creating a rough outline of a product roadmap across each area of focus. Earlier last year, before we transitioned to outcome-based planning, the leadership team at Yesware did a thought exercise during an offsite. We broke into pairs and then each pair developed a feature roadmap along a particular area of focus. Putting all the themes together, you could see a rough annual roadmap.
There is something assuring, if not falsely assuring, in seeing a yearly feature-focused roadmap. A plan is the first step on the path to delivery. You can align on direction. You can sell to the future of where the product is headed. You can provide confidence to current customers that their expressed needs are prioritized. You can create sales training and prepare go-to-market plans for upcoming feature launches months in advance. You can hire and staff teams around needs and skill sets by having foresight into future needs and areas of investment.
In an Agile, fast-moving and competitive environment, what you are frequently not able to achieve with output-focused product planning, however, are desired user and business results. Output-focused roadmaps assume that your few big bets become home runs. In reality, our understanding of user needs evolves, the market landscape changes, and you focus on de-risking execution, thus pushing aside new ideas or experiments. Planned work shows disappointing results. New risks and opportunities arise. Users provide feedback only to have ideas and suggestions added to the end of a long queue (“we’ll consider that in 3 quarters”). The teams doing the work ends up executing on solutions that no longer meet the user needs they are hearing about and you spend months executing something that is no longer a priority.
Outcome-Based Planning
Over the last six months at Yesware, we’ve gradually transitioned to outcome-based product planning. Here are seven lessons we have found to be important during the transition from output to outcome-based planning.
1. Start with company vision and direction
To reiterate the obvious, the leadership team needs to set the company vision and direction. This involves defining the core user(s), articulating the user’s “jobs to be done“, and identifying how the company is differentiated. Everything flows from this vision.
2. Define high-level company outcomes
Then, the leadership team should align on the key business outcome the company is aiming to achieve and ideally one North Star metric that is a leading indicator of that business outcomes’ success. While the business outcome is frequently financial (e.g. “50% revenue growth”) and a lagging indicator of impact, a North Star metric is a leading indicator of impact, which reflects the value your business delivers to users. Defining the right North Star metric drives the opportunity and solution space—the core work of your product teams—and is thus some of the most strategic work for a leadership team.
At Yesware, we first made a transition from defining outputs to defining several key outcomes, because moving to one North Star metric for the business was too much of a rapid change. Thus we started by defining high-level user outcomes in each of the main areas of business focus. Each area had a key user outcome that it was seeking to drive. Thus, the next time the Yesware leadership team got together for an offsite, instead of planning that in Q1 we would “deliver a report that does the following,” we were focused on outcomes: In Q1 we will “increase the number of users getting value from reporting” and “increase the number of meetings our customers book with their customers.”
After the transition to a few key outcomes, we were better able to tackle defining one North Star metric, because the muscle of setting outcomes and driving towards them was beginning to strengthen.
3. Allow the team doing the work to refine their specific outcome
It has been key for the teams working on each focus area (main inputs into the North Star metric) to come together to refine and align on the specific outcome for which they would be accountable. While the leadership team sets the North Star and frames for the inputs driving the North Star, the team doing the work (e.g. product manager, designer, engineers) signs up for the specific outcome within a defined period of time. This drives greater ownership and accountability. It allows the goals to be more informed. Tactically this means taking a goal, such as “increase the number of meetings our customers book with their customers” to the team who then refines it to something like “achieve an average of 10,000 customer meetings weekly by the end of Q1.”
4. Align on opportunities before diving into solutions
In our experience, it is critical for the team doing the work and its key stakeholders to align on the most important opportunities to explore to achieve the defined outcome. Note that this discussion is best had at the level of opportunities and not specific solutions. Opportunities are significant user needs with varied possible solutions. In our meeting scheduling example, “help users book more meetings with their customers,” two different opportunities could be:
- Help users set up meetings efficiently and
- Ensure that booked meetings actually occur.
In contrast, a meeting tool that sends meeting reminders to recipients is a specific solution. Not aligning on the priority of the different opportunities leads to team and internal stakeholder friction. You may be experiencing some misalignment if you are hearing lots of solutions that align with opportunities which you are not focused on. In these instances, the product manager needs to be able to show their own work—data and insights from ongoing customer discovery—that has led to the opportunity prioritization and engage with stakeholders to understand what is driving the misalignment.
5. Compare and contrast similar solutions
Once the team has a clear user opportunity focus, the deepest discussions around solutions occur. Relative to output-based product planning, the conversations around solutions can seem delayed. All the work around alignment, however, allows for the comparison of solutions that meet a similar need. Instead of trying to compare and prioritize solutions that meet dramatically different needs, you are now evaluating how a solution will impact a specific opportunity and outcome. Instead of immediately focusing on one solution and moving it directly to execution, the team is surfacing many different solutions that meet the user need and comparing these against one another. Trade off and prioritization discussions are easier to have, internally and with customers, when you are comparing and contrasting many similar options versus just serving up one solution for validation.
6. Take small bets first by de-risking solutions
When you’ve narrowed down the solution space, instead of taking on a large multi-month project, we’ve found it valuable to start with small bets. Specifically, we are learning to identify and de-risk the highest areas of risk within a solution, which will have a big impact on the results. We are also trying not to spend time testing things that aren’t risky or those that are well-known—those can just be built.
When it comes to assessing risks, it’s helpful to identify a project’s risks and then determine what can really throw you off course. These could be:
- Technical or viability risks (e.g.: Can we execute this within a defined time? Can it scale?)
- User risks (e.g.: How desirable is this? Is the solution intuitive? Are people willing to pay more for it?).
A way to de-risk a solution maybe through user testing, a technical proof of concept, or a light test within the product. For example, we wanted to test the demand for a “best time to send” feature which would allow users to identify the best time to send an email in a way that increases the likelihood of reply, based on the recipient’s location. We have a similar tool on our marketing site. Instead of building out a seamless integration of the tool within the product, we iframed the marketing tool in the product and measured the level of engagement to determine if and how we should invest further. It wasn’t the greatest user experience. But why build the best user experience if you are still trying to test user demand?
7. Continue to come back to your outcomes
Finally, the team needs to have the right instrumentation to continuously monitor how it is impacting the target outcome. When setting the North Star and the inputs that drive it, it’s valuable to have outcomes that can change on a regular basis versus lagging outcomes that can take months to move or can only be measured infrequently. The more responsive an outcome is to your work, the easier it is to track and monitor. We’ve found it valuable to have outcomes that can be measured weekly. Also, setting up the instrumentation in a way that is automated—at Yesware, the data we measure lives in Amplitude—has increased transparency. Tactically, both the teams doing the work and stakeholders across the company have centralized access to the dashboards measuring the key product outcomes. This way the team can course-correct, if needed, and surprises are minimized.
Moving from Outputs to Outcomes is the Product Development Strategy That Works in the Long Run
Making the shift to planning around outcomes is ultimately about putting customer needs center stage and creating roadmaps that don’t check the boxes on features delivered but measure the impact on customer needs. It’s a process that takes alignment and organizational change, but is well worth the investment. We are glad to be moving forward on this journey at Yesware.
