How to Build and Manage a Product Roadmap

SOFTWARE DEVELOPMENT

If I asked you what cur­rency your com­pany trades, how would you re­spond? Australian Dollars? Labour Hours? Product Value? Leaving the lit­eral an­swers aside, every com­pany trades their knowl­edge, ex­per­tise and their abil­ity to ful­fil their cus­tomers’ needs. In this ar­ti­cle, I’ll fo­cus on build­ing your cur­ren­cy’s value through the con­cept of a ‘product roadmap’.

What is a prod­uct roadmap?

To be­gin, we’ll ob­serve Atlassian’s de­f­i­n­i­tion of what a prod­uct roadmap is. “A prod­uct roadmap is a shared source of truth that out­lines the vi­sion, di­rec­tion, pri­or­i­ties, and progress of a prod­uct over time. It’s a plan of ac­tion that aligns the or­gan­i­sa­tion around short- and long-term goals for the prod­uct or pro­ject, and how they will be achieved.”

My ob­ser­va­tion is that this is es­sen­tial to your busi­ness, even if you were to re­place the word prod­uct with ser­vice.

The rea­son a roadmap is es­sen­tial is not the arte­fact it­self. Rather, the im­por­tance is the or­gan­i­sa­tion’s align­ment to the roadmap. A roadmap cre­ated in a vac­uum will be use­less to you, your team and your cus­tomers. The process of cre­at­ing a roadmap forces the lead­er­ship team to ar­tic­u­late your goals and strat­egy clearly, en­sures it’s solv­ing your cus­tomer’s needs and stops stake­hold­ers from mis­align­ing on pri­or­i­ties.

What should the roadmap look like?

No sin­gle for­mat works for every­one. The roadmap should re­flect the ma­tu­rity of your busi­ness. A star­tup’s roadmap could be a white­board with some post-it notes, whereas an en­ter­prise may be doc­u­mented in a re­port and recorded through a pre­sen­ta­tion.

Tip: ‘The for­mat is less im­por­tant than key stake­holder sup­port.’

The typ­i­cal for­mat is prod­uct cat­e­gories on the left and mile­stones on the right, as per the im­age be­low

Product market fitEach mile­stone should con­tain bun­dled func­tion­al­ity that has sig­nif­i­cant value to your cus­tomers. Do not use the prod­uct back­log (what is get­ting de­vel­oped) as a roadmap. The back­log is full of small tasks/​is­sues, and you can’t align stake­hold­ers around it.

You’ll no­tice in the graphic above that the prod­uct roadmap is­n’t cre­ated at day 1. That brings us to our next point.

When should­n’t you build a roadmap?

There’s one crit­i­cal time when you should­n’t build a roadmap. That time is if you don’t have an ac­tive and en­gaged cus­tomer base (ie. you don’t yet have a prod­uct or you don’t have users). In this sce­nario, you should have a set of hy­pothe­ses your pro­ject is try­ing to val­i­date or in­val­i­date. You can still use the roadmap process to cre­ate align­ment on your pre­sent hy­pothe­ses. The dif­fer­ence is that you will be piv­ot­ing your prod­uct too quickly for a main­tain­able roadmap. What’s the point of strate­gis­ing 10 months from now if a learn­ing 1 week from now could sig­nif­i­cantly im­pact the fu­ture of the prod­uct?

Product Stakeholders

So, who are the prod­uct stake­hold­ers? Simply (and broadly) a prod­uct stake­holder is any­one who in­flu­ences the di­rec­tion or value of your roadmap’s el­e­ments. These will be dif­fer­ent for every or­gan­i­sa­tion. The key groups you may wish to con­sider are:

  • Customers
  • Customer-facing groups: sales, mar­ket­ing or cus­tomer sup­port.
  • Investors, board or spon­sors.
  • Architect, en­gi­neers and de­sign­ers.
  • Human re­sourc­ing.
  • Legal.

Creating Alignment With the Roadmap

When peo­ple are in­volved in shap­ing some­thing, they feel own­er­ship. Let’s face it, the best idea is your idea. If you in­clude stake­hold­ers early, ask them for feed­back and keep them up­dated, you will in­crease mo­men­tum. Successful roadmaps have three things in com­mon:

  • They’re based on a sound strat­egy.
  • Realistic.
  • Fully sup­ported.

One of the most com­mon fail­ures is short­cut­ting one of these fac­tors. This of­ten comes back to lead­er­ship. If you are not the leader of the busi­ness but are ac­count­able for the roadmap, a founder or CEO will likely im­pact the process.

The rea­son is that the founder or CEO usu­ally knows a lot about the mar­ket and has an in­nate sense of what has worked in the past and what will work in the fu­ture. It would be best if you chan­neled your lead­er’s pas­sion and en­ergy into the process oth­er­wise you risk changes at the 11th hour, flawed as­sump­tions, a lack of align­ment (some peo­ple will try to un­der­mine) and ul­ti­mately, a roadmap that does­n’t carry any im­por­tance.

Similarly, lack of buy-in at the op­er­a­tional level can be detri­men­tal if lead­ers are dic­tat­ing the prod­uct to their em­ploy­ees.

To mit­i­gate:
  • Spend time with all stake­hold­ers at the be­gin­ning of the process
  • Ask for the CEO’s ideas and the most crit­i­cal de­vel­op­ment pro­jects. Ask for their un­der­ly­ing thoughts.
  • Explain the im­por­tance of in­clud­ing other stake­hold­ers.
  • Run the process quickly - ask the CEO to choose who to be in­volved with the prod­uct de­vel­op­ment.
  • Once you’ve done this, it’s now a plan that has buy in at the top level of the or­gan­i­sa­tion. Be sure to keep stake­hold­ers up­dated through­out the process.

The cur­rency of a roadmap is cus­tomer knowl­edge.

The more cus­tomer knowl­edge you can gather be­fore com­menc­ing the roadmaps process, the eas­ier it will be to align stake­hold­ers.

The best way to arm your­self for the process is with di­rect qual­i­ta­tive re­search di­rectly from the cus­tomer. The dif­fer­ent ways you can do this are:

  • Initiate a re­search group.
  • Ask cus­tomers your­self
  • Participate in sales or cus­tomer ser­vice meet­ings.
  • Reach out to the cus­tomers di­rectly and ask them for a few min­utes of their time.
  • Observe them us­ing the prod­uct.
Good ques­tions to ask:
  • Why did they start us­ing the prod­uct?
  • What were the other mar­ket op­tions they re­viewed?
  • Why do they con­tinue to use the prod­uct?
  • What they wish was dif­fer­ent?

You will know when you’ve com­pleted enough cus­tomer in­ter­views when you can pre­dict the an­swers to their re­sponses. Usually, this is about five times.

For more in­for­ma­tion on how to do user in­ter­views check out: ‘What are user in­ter­views and why are they im­por­tant?’

The Process

Okay, that’s the back­ground in­for­ma­tion com­pleted. You are now at a point where you can start the process. Here’s a quick sum­mary of what to do at each stage.

Product Strategy

You can’t eval­u­ate a roadmap with­out un­der­stand­ing the strat­egy. A prod­uct strat­egy de­scribes how your com­pany will achieve its busi­ness goals. It would be best if you dis­cov­ered the an­swers to these ques­tions:

  • What are the busi­ness goals?
  • How will you mea­sure suc­cess?
  • What ben­e­fit do you pro­vide your cus­tomers?
  • Who are your com­peti­tors?
  • What dif­fer­en­ti­ates you?
  • Who are your cus­tomers?

Write down the an­swers to these in a brief doc­u­ment. The busi­ness leader should feel like they own this in or­der to pro­mote and de­fend it.

  • Discuss your strat­egy with prod­uct stake­hold­ers and doc­u­ment learn­ings.
  • Start with 1on1 meet­ings.
  • Have a group meet­ing.
  • Refresh if you need more align­ment.
  • You are now ready to start build­ing the roadmap.
Identify mile­stones

Now it’s time to iden­tify your mile­stones. You are the best per­son to start this process. Create ver­sion 1 con­sid­er­ing the fol­low­ing:

  • What are the bar­ri­ers?
  • Understand your cus­tomers de­ci­sions.
  • Reread your prod­uct strat­egy.
  • Research the mar­ket and your tar­get cus­tomers.
  • Try to imag­ine the prod­uct evo­lu­tion.

Milestones can be im­pact­ful in dif­fer­ent ways. For ex­am­ple one mile­stone may fo­cus en­tirely on small changes and qual­ity im­prove­ments in or­der to re­duce churn, whereas an­other mile­stone may be en­tirely fo­cused on fea­ture de­vel­op­ment.

Record the strate­gic ob­jec­tive each mile­stone sup­ports and its ra­tio­nale. Now, meet with your prod­uct stake­hold­ers, 1on1.

  • Review the strat­egy and ask for their ideas.
  • Review your ideas.
  • Merge the feed­back.
Estimate Effort

It’s time to seek feed­back from your prod­uct or en­gi­neer team. Clarify that these will only be es­ti­mates and may change as more is dis­cov­ered. If some mile­stones are small, con­sider merg­ing them to­gether.

Table them out: Milestone name, strate­gic ob­jec­tive, sum­mary, source and time.

For dif­fer­ent tech­niques on soft­ware es­ti­ma­tions check out our ar­ti­cle on sci­en­tific soft­ware es­ti­mates.

Build the Strawman

The straw­man is the first se­quence and sched­ule with the mile­stones. Use the es­ti­ma­tions and place them on a time­line as per pri­or­ity de­pend­ing on your prod­uct team’s ca­pac­ity.

Now, san­ity check-it. Does it im­ple­ment prod­uct strat­egy, and is it fea­si­ble?

The prod­uct roadmap meet­ing

Finally, you have your first roadmap. Now, it’s time to check align­ment - get every­one to­gether and re­view. Plan and run the meet­ing with all busi­ness lead­ers.

  • Explain the goals - emerge with a shared prod­uct roadmap that every­one sup­ports.
  • Quickly re­view the prod­uct strat­egy (if there is no align­ment, do not con­tinue).
  • Review the de­vel­op­ment ca­pac­ity and es­ti­ma­tions.
  • Walkthrough your prod­uct roadmap straw­man.
  • Ask the team what they wish was dif­fer­ent.
  • Modify the roadmap di­rectly in the meet­ing (show every­one the trade-offs).
  • Think about fu­ture suc­cess.

The best case is that you have a con­sen­sus. If there is mis­align­ment, the busi­ness leader of­ten de­cides the di­rec­tion, but every­one should pub­licly sup­port it.

Evangelise the roadmap

It’s now your re­spon­si­bil­ity to en­sure the align­ment flows down the or­gan­i­sa­tion. To do this cre­ate a short pre­sen­ta­tion that shows:

  • Top-level ob­jec­tives.
  • Target cus­tomers.
  • Competitive ad­van­tages.
  • Show the di­a­gram.
  • Include ra­tio­nale.

Present di­rectly with peo­ple who are im­pacted by the roadmap. Check for align­ment. Is there some­thing we need to re­visit?

Now, roll it out to an in­clu­sive meet­ing. Ensure it is 10-20 mins max and try for a pub­lic Q&A. Always pre­sent the roadmaps as a team ef­fort. Make sure the com­pany has a way to share the roadmap with cus­tomers.

Maintain the roadmap

Update the roadmap when you’ve learned some­thing new. New info could be:

  • Customers needs/​de­sires have changed.
  • Competitor in­for­ma­tion.
  • Development time and cost of prod­uct de­vel­op­ment.

Try to un­der­stand the rea­sons for the change. What’s the new in­for­ma­tion? The de­ci­sion on when and why you’re up­dat­ing the roadmap is your re­spon­si­bil­ity.

What’s Next

  • Spend time with cus­tomers.
  • Spend time with prod­uct stake­hold­ers.
  • Build your first roadmap.
  • Keep your roadmap rel­e­vant.

The in­for­ma­tion out­lined is this ar­ti­cle was rec­om­mended as part of Project Management Institute’s (PMI)® Product Management: Building a Product Roadmap Head over to Linkedin Learning if you would like to com­plete the course in full.

Discover Software
Secrets

ABOUT THE AUTHOR

David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

What is Agile Software Development: How to Start with a Problem

16 October 2020

The Advantages of Agile Project Management

09 September 2020

What’s the Best Agile Project Management Method For You: Scrum vs Kanban

11 September 2020

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion