Posted on

Using the product roadmap to keep an organization in sync

When organizations are relatively small, it is possible to keep all parts of the company – execs, PM, sales, engineering, QA, operations, etc – in sync with the direction and with the vision of the company. Communication across the company can be seamless and everyone can remain aligned to what they are working on and understand how their work maps to the broader vision.

However, as companies scale up, it is very easy for this chain to be broken and for a hitherto finely tuned company to get out of sync. Examples of this happening:

  • Deal-driven features: Sales promises a feature to a customer to close a deal and it gets added to a plan. After a few months, everyone forgets about it and it gets dropped. Eventually it blows up as an escalation when the customer is now upset that promises were not kept.
  • Vision changes: The exec team makes changes to the vision as the markets changes. This requires a replan with new features coming in and some features in plan being dropped based on shifting needs. This does not get communicated down the chain and development remains marching to an older beat.
  • “All Features Accepted”: Every few days a new feature request comes in and gets added to the plan. Nobody says “No” early enough, a commit gets communicated externally and in the end the product becomes a mish mash of features, with no clear vision and becomes impossible to use. Without a consistent plan that resonates to the vision, the product manager risks putting out a product that makes noone happy. The PM is the gatekeeper to avoid this from happening.

These are all examples of breakdowns in communication. It is the product manager’s responsibility that this does not happen. A product manager can use their product roadmap as a central part of a simple process to make sure that all parts of the company remain in sync. Changes will happen – that is a part of startup life – but the important thing is to make sure that the changes as they happen are clearly rationalized, communicated across all teams and all teams are kept in sync with where things are.

The best product roadmaps define the themes of the market that are relevant, the long term vision of the product (about 2-3 years out)  as well as the shorter-term term features (quarterly breakdown over the next one year). While this is maintained by the product manager, this should be communicated regularly to the sales, dev and engineering teams. The product roadmap should be shareable externally to prospects, customers and other external stakeholders. Done right, the product roadmap becomes the central part of the process of keeping the various teams in sync.

Product Alignment Process

The process involves creating:

A vision document : Simple 1-2 pager describing where the company will be in the next 12-24 months. This is done in concert with the execs and aligns with the company’s overall strategy. This is shared with everyone in the company and externally as well. Normally this is part of the lead-in to a detailed roadmap but sometimes this can live separately (especially in multi-product companies where the vision is broader and maintained by execs). This is versioned and is available to everyone.  I prefer the use of Google slides with read-only link shared across the organization.  A well defined and strong vision ensures that any feature request that does not align with the long term vision can be dropped early. The product manager meets regularly with the execs and keeps this in sync.

An external “one-slide” roadmap : This is the product roadmap as it is traditionally defined. The deliverable here is a simple one-slide roadmap showing the quarterly deliverables of the marketable features for the next year. This can be shared externally. As above, Google slides with a shareable read-only link works great here. It is versioned to be consistent with the vision document.

XYZ Car service Road mapFigure 1 : Example external roadmap for a fictional car ride share company. One Google Slide with the next 4 quarters of marketable features.

An internal / detailed roadmap: This builds on (2) and adds internal deliverables – like performance improvements, UX changes, engineering focused tasks, etc. This is the detailed, internal-facing roadmap. This version allows the team to make sure that the engineering focused improvements are not lost in the shuffle. This allows the team to make progress on reducing technical debt while continuing to execute to the market.

XYZ Internal Roadmap
Figure 2 : Internal roadmap shareable with dev and QA managers. One google slide that builds on external roadmap.

The details from the internal roadmap are then mapped to a tool that allows for backlog tracking and planning. I prefer Trello for a Kanban-like tracking system but there are various other tools that work very well. 

Trello schedule

Figure 3: Using Trello to schedule the work outlined in the internal roadmap as a set of cards

Sprint planning: With the details from (3), PM works with dev management to build out the detailed plans for each sprint and map it to a tool to track this (I prefer Atlassian Jira) for this. At this level, this is really a detailed work plan that’s aimed at PM, dev and engineering teams

 

Xira screenshotFigure 4: Using JIRA for sprint planning. See blog for more.

And thats it.

What we have done above is create a predictable system where all product planning deliverables are kept in sync with one another. There are three critical attributes to making this process work:

  1. Versioning: All the documents above should be synchronized. The latest versions of each should all relate to one another. Where a change is made, the older version should be versioned and there should be a clear indication for the reason for change. It should be possible for any stakeholder to review past documents to understand the reasons and the velocity of changes.
  2. Relevant Access: To avoid irrelevant information being communicated to the wrong audience, appropriate access should be given to the right stakeholders for the vision (everyone), external roadmap (sales, execs, PM), internal roadmap (PM, execs, support leads, dev leads, QA leads) and detailed sprint plans (all dev and QA)
  3. Single Owner: One owner should be responsible to make sure that they are in sync. The PM should own 1-3 above and work with engineering management to align it with (4)

Summary

Plans can and do change. The product alignment process defined above allows for the different planning documents across the product organization to remain in sync at all times so that as these changes happen, they can be rapidly and consistently communicated. This allows every employee to be confident that the work they are focused on is in sync with the vision of the company. And that will help the company move quicker and more efficiently as a result.

Posted on

Your Product Roadmap is your Product

After building, marketing and selling lots of software, I’m convinced that the single most underutilized component to driving growth is your roadmap.

In SaaS or consumer products monetized via an enterprise budget, you make your numbers because of your current feature set. But you blow out your quarter because your product and sales teams present a roadmap that explains the customer’s future state, if they have you as a partner.

When done correctly, the roadmap expands the number of tentacles to grab more customers and dramatically raises the value of every deal.

In the formative stages of building and selling your product, your current feature set is absolutely vital. At growth stage however, your in-market product is not really your product but it’s your proof point. It’s your cheapest and most effective form of marketing. At growth stage it’s your product roadmap that’s really the product that’s going to attract senior executives making 3–4–5 year bets. Because with continuous deployment or daily / weekly releases, the in-market version your positioning is obsolete by the time the customer gets value from it.

Here’s what it’s not.

A roadmap used during the sales cycle is not the same deliverable you share with engineers. That’s necessarily tactical and solution driven. It isn’t a litany of features broken out by quarter for the next 18 months. That would likely break forward-looking rules anyway.

Here’s what it is.

  1. Its the ethos of your business that guides the choices you will make when enriching the offering. In our case, we have a track record (21M+ subscribers) of finding white spaces left behind by traditional transaction software. The design ethos that guides and motivates us is to continue to employ collaborative models to go after these white spaces to deliver big efficiency breakthroughs for our customer’s employees, customers, and partners.
  2. Its a thematic, executive-ready, sales consumable illustration of what problems you will keep solving for. A commitment to solving thematic problems that your target customer base struggles with to consistently drive revenue, reduce cost or mitigate business risk. Or you will have missed the mark. Jared Spool and Bruce McCarthy astutely describe themes “a promise to solve problems, not build features”. And that these themes must remain consistent.
  3. Yes, a healthy dose of tactical capabilities. In practical terms, you are always 5–10 features away from completeness, in the program owners mind. The program owner needs to know you are on it (or be clear the you don’t plan to) to be comfortable that she can get quick wins with the purchase. So by all means, include this. But know that whilst its one of the needed components, it isn’t the one that expresses the strategic thrust behind your offering.

Elon Musk epitomizes this. He presents what problems he will keep solving for, in the coming 24 months. Take speed: He markets the Ludicrous Button. Because a stated top speed is a feature. And that’s finite, and therefore limiting. Tesla’s Ludicrous Button is a design ethos that will keep drawing customers. Because they know exactly what future state of the art they are buying into.

It’s amazing how much time a product and sales team will focus on tactical capabilities or agonize around pricing options of current products to make its past as attractive and available as possible. Yet they will guard their future plans by restricting access to the roadmap like it’s the secret sauce.

Well the customer facing roadmap is the secret sauce in your sale.

Executives know that they, nor you, can predict the needed solutions of the future. All they want to be convinced of is that both they and you will be aligned on the same problems that need solving. That’s the only constant.

Expressing your roadmap is the basis for competing effectively. And this needs to be ingrained in your key product management, product marketing, sales enablement and sales execution processes.

It’s a hard slog to make your number based on your current features. So consider selling your roadmap. I’m convinced that it’s like wearing flippers to a swim meet.

Guest Blog Post by Sameer Patel, SVP, Product Management and Go-to-Market, SAP Cloud / Successfactors. the original article can be accessed here.