Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Intro: Roadmap Stakeholder Aligment - The Impossible Dream?

One of the biggest challenges of Product Management is to get all stakeholders to agree on a roadmap that is best for the company. What often happens in B2B is that Sales forces features onto the roadmap to close the sale with a big new customer, or that the CEO has a pet project for which actually there is very little customer demand. Even Support can unintentially derail a product if force too much time allocation for bugs and minor improvements. Also various stakeholders (i.e. CEO, investors) can blow up the roadmap by demanding that 'version 2.0' of a certains way to many feature before launch. Finally disagreements between stakeholders can also lead to feature bloat, by trying to address too many persona's or too many user needs.

Many PM's see stakeholders setting the roadmap as inevatable and accept this or give every stakeholder a set of points to spend on features which is just as bad. Doing this is signing the death warrant of Product as only products with the highest business and customer value will survive.

Taking charge of the Roadmap process is one of the core duties of a PM, and it's totally learnable and doable and does not require stellar negotiation or presentation skills and certainly does not require a company off site (those are great for team building and brainstorming, not for roadmapping).

Foundations of Roadmapping Success

First of all you need to accept that you cannot force a Roadmap on your stakeholders, even if it's the best roadmap in the world. Stakeholders like a CEO or CPO have end responsibility for the Product and to need to buy in to your ideas. However with the right process you will be able to get your stakeholders to accept 90% of your roadmap proposals within 2 hour Product Council meeting. The Product Council makes all Roadmap decisions and typically consits of the Product Manager, Head of Product and most of the C-suite and typically meets once a month

The Product Council decides on the priority order of the Roadmap Theme's. A roadmap theme based on a single high level user need i.e. "B2B Fruit Basket subscription MVP", and typically one to three months of development work. The Product Council does not go into detailled requirements and does not provide design feedback, but instead trusts the underlying processes and experts for that.

Roadmaps should be managed using the same Agile principles used to manage a scrum backlog, not as waterfall project. The only difference is that on the Roadmap the user stories are bigger. Most companies have learned and embraced scrum, yet when it comes to the Roadmap they fall back to Waterfall thinking (see table below).  


Waterfall thinking RoadmapAgile Roadmap
Roadmap work items are feature based (i.e. payment provider x integration).Roadmap work items are user need based (One time payment by Creditcard or Paypal).
Estimated by 1 or 2 people, not always developers.Estimated by team including designers and testers, comparing it to past projects.
If development is delayed the deadline gets postponed.If development is delayed the scope is reduced, but deadline is fixed.
Often big projects / large scopeSmall as possible theme's (MVP's)
Planning doesn't get updated until first deadline is missedConstant re-prioritization of the roadmap
One big release planned, i.e. 1.0 release on 1st of April.Intermediate Release every (2 week) sprint.
Planning 6 months or more ahead, with details even far aheadDon't plan too far ahead. Theme's who are at the top of the backlog get more detail.
Team working on several projects in paralell.Just one theme per team at a time (until design is done and tested, then the designers can already start on the next theme)

Companies that need to transition from a more waterfall approach could start with just some of these practices and instead of a 12 month roadmap do a 6 month roadmap. 

 Every roadmap theme is an MVP (Minimal Viable Product), meaning that only that only the bare minimum features are developed that are needed to address the user need and provide the proof if the user will actually buy or use the solution as designed. For the fruit basket example this means that customer can only change his subscriptions by calling customer support and that the customer cannot (yet) change the contents of the actual basket. Every theme will have a short financial business case (i.e. 10% of users will order it) which can be tested against.

However not all software development is managed through the Roadmap, as this would blow up the process with bugs and minor improvements which are of less strategic importance. Only theme's are managed through the Roadmap. For these strategic theme's a time bucket is allocated, i.e. 60% of the development time. For bugfixing there is a seperate bucket (i.e. 15%) and for Minor Improvements (a.k.a. Business Blockers) there is another bucket (i.e. 25%). These percentages are set by the Product Council for a longer term. The PM has full authority to manage the priorities of bugs/stories in those buckets without consulting the Product Council, however he/she might have to report on those retrospectively. Prioritizing Bugs and Minor imporvements is outside the scope of this article, but typically improvements are ranked by financial business value and bugs by the number of people impacted and the severity (i.e. is there a workaround or not).  

The decision the Product Council has to make is the order of roadmap theme's or at least what Roadmap theme goes next. The hard way of doing this is asking everybody for their opinion and arguments, who will mostly be subjective. This will lead to endless discussions that are not grounded in data on what the customer wants and therefor lead to bad compromises. The easier way of doing is that A) the PM convinces the group of the importance of data driven decision making. B)  The PM convinces the group based on what data points theme's are prioritized C) The PM collects that data D) The PM presents a top 3-5 of next roadmap theme's supported by the he collected E) The Product Council orders the list. 

Priorirization should be driven for 95% by a scoring formula that the Product council agrees on. Every company will create its own formula and on the page Theme Prioritization you can find an example. In general I recommend a formula that accounts for the strenght of the user need(0-100%), the additional profit this feature would bring per customer (0-100%), the number of customers that will use this feature (reach)(0-100%) , the alignment with the product vision or business goals(0-100%) and devide all the above by a rough effort estimation. Since all elements in the formula are based on a score (often (0-100%) you can literally calculate a score per roadmap theme. When you first place a new theme on the roadmap you do a quick estimate on all factors. And if the theme has a chance of making it into the top 5 or so, you start improving those estimates by collecting more data. Just like you don't make detailled plans for a far away future theme, you don't collect too much data on them either. 

Example formula: (((Impact - Satisfaction)+ ProfitPerCustomer + BusinessGoalAlignment) * Reach * Confidence)  / Effort 

I have seen too many PM's don't even start collecting supporting data for any roadmap theme, because they think the effort is too big. This is often based on a limiting belief that data needs to be statistically significant and therefor a large deal of data points is needed.  However do you really believe that decisions made based on some data, are worse than just relying on gut feeling? What I like to do is play Sherlock Holmes and put all 'clues' that I collected into my roadmap theme's. This can for instance by things like "Place 3 in top 10 customer pains reported by Support" , "In Januari survey this 75% agreed or strongly agreed with the statement ...", "23% of non customers leave the funnel at stage y". The ultimate data points are often user behaviour and survey answers, but often some imperfect data can be perfectly right for prioritizing the roadmap. Collecting data is ongoing work as part of the Discovery process (i.e. quarterly surveys, bi weekly user tests, weekly analysis of support tickets, NPS score, analytics, etc). 



greenlight for built or just to design. 


FAQ

Why 1-3 month long theme's? Isn't that too waterfall? Why not smaller steps to reduce risk and develop more incrementially?

Isn't an experiment backlog better than a roadmap, with smaller items and learning every sprint?

I often see some companies try to be more 'experiment & data driven' but then overshoot. On one hand you shouldn't start a roadmap theme for which there is unsufficient supporting data, on the other hand you shouldn't endlessly keep experimenting and collecting data until you are 'sure' a theme will work out. To quote a famous Amazon principle: If you're 70% sure of something, go for it!

One startup I worked for had as 'most important' learning experiment if a different background picture for the homepage would increase conversion. Another one was experimenting with button colors. You only have a limited bandwith for running experiments and collecting data until the development team needs a decision on what to build next. For the 'Fruit Basket subscription' example customer interviews followed by a larger online survey gives you the impression that circa 20% of your customers will order it. You could further proof this by offering it via mail to some of your existing customers. However at some point you should just 

 



Process

Product Council = PC = PM, CEO's, HoP
All Milestone decision making below is by the PC. 

Phase 1: Collect Customer Need Hypothesis (aka Collect Ideas)

  • I.e. brainstorms, customer feedback analysis, market research, etc. Let's start with what we have plus ideas by Thomas/Arco/Davide. 
  • Do a quick sort of needs we want to validate and select some (PC) 
  • Who: Anyone can deliver input. First grouping/deduplication/sorting by PM's. 
  • Output: Needs hypothesis to validate and / or collect data on 

Milestone 1 Decision making: Which Needs will we investigate & test? (this period, i.e. 4 weeks). 

Phase 2: Test Need Hypothesis 

  • I.e. brainstorms, customer feedback analysis, market research, etc. Let's start with what we have plus ideas by Thomas/Arco/Davide. 
  • Do a quick sort of needs we want to validate and select some (PC) 
  • Who: Either GHT or PM&IT as desired per need.
  • Output: Needs hypothesis to validate and / or collect data on 

Milestone 2 Decision making: For which Validated needs we want to design and estimate a high level solution

Phase 3: Test Solution Hypothesis & data collection

  • Discussion of Solution ideas with team & estimation
  • Gathering data, doing experiments.  
  • Creating short business case
  • Sorting Needs based on gathered data and tests (using combination of data and input by PC). Ideally as objective as possible using PC predefined prioritization formula.
  • Who: Either GHT and/or PM&IT as desired per need. (depending if a 2d solution (test) is possible). 
  • Output: (In)validated Needs incl supporting data sorted by priority

Milestone 3 Decision making: Theme Prioritization: Which Theme's (solutions) we'll put on the roadmap? (next 3) 


Roadmap priorization

See sub page


Long term solution / process



Roadmap 6 week blocks with 2 week "break"


https://medium.com/intercom-inside/6-weeks-why-its-the-goldilocks-of-product-timeframes-c7b14c493993?_hsenc=p2ANqtz-9kCI_7bhsnE8eM_3RQurUPYxr1gxjI0rcdjC3O-ogW3Faolu2ZuO7Up6muV-NUAuU5TR16Xn3G5-IGdr_QNYrwVc5b1Q&_hsmi=52577947


Product Council & Decision making milestones

  • The purpose of the product council is to set the strategic product direction, allocate product resources and investments, and provide a level of oversight of the company’s product efforts. This group is not trying to set the company’s business strategy, but rather—given the business strategy—come up with a product strategy that will meet the needs of the business. Typical members:
    • CEO, COO or Division GM VP/Director of Product Management (leader of the product council)VP/Director of User Experience Design VP/Director of Marketing VP/Director of Engineering VP/Director of Site Operations VP/Director of Customer Service


For each product effort (except minor updates or fixes) there are five major milestones ("gates") for product council review and decision making:

  1. Milestone 1: Review proposed product strategies and product roadmaps, and initiate opportunity assessments for specific product releases. That is, select the product opportunities to be investigated.
  2. Milestone 2: Review opportunity assessments and recommendations, and issue go/no-go decisions to begin discovering a solution (=design prototype, do estimate).
  3. Milestone 3: Review product prototypes, user testing results and detailed cost estimates, and issue go/no-go decision to begin engineering.
  4. Milestone 4: Review final product, QA status, launch plans, and community impact assessments, and issue go/no-go decision to launch.
  5. Post launch assessment: It can be useful for the product council to review the business performance of the products that have launched. The product council may request a presentation on the business results of the product launch, typically 3-6 months post-launch. This sort of accountability will help the council better understand which investments and decisions they made were good ones, and why.


  • No labels