Working with the GO Product Roadmap

By Roman Pichler, 14th January 2014

The GO product roadmap is a new, goal-oriented product planning tool developed to fit into a Lean Startup, Business Model Generation and Scrum context. By focusing on goals, the roadmap shifts the conversation from debating features to establishing shared objectives. This post explains how you can use the GO product roadmap effectively. It discusses its relationship with the Vision Board and Business Model Canvas; it describes how the roadmap is created; it shows how it relates to the Product Canvas/backlog; and it explains how pivoting works with the roadmap.


Step 1: Do the Prep Work

Before you create your GO product roadmap, you should carry out the necessary problem validation work. Investigate the target group, the problem to be solved, the business goals, and the technical feasibility of your product. The Vision Board, the Business Model Canvas, and the Lean Canvas are great tools to capture and validate your ideas.

VisionBoardGOProductRoadmap

To see how this can work in practice, take a look at the Vision Board below. The board captures the idea of creating a digital dance game together with the intended audience, the benefits, the key features, and some aspects of the business model:

DanceGameVisionBoard


Step 2: Build the Roadmap

The Vision Board, Business Model and Lean Canvas are helpful tools to describe the market, the value proposition, and the business model. But they not tell us how the strategy will be executed. Will the first product version deliver the entire value proposition and generate the desired business benefits, for instance, or will this take longer? Say we focus the first version of the dance game on user acquisition. While this is a necessary step towards the vision, it does not answer the question when revenue will be generated. This is where the GO roadmap comes in.

I used the Vision Board above to create the roadmap shown below. You can download a PDF and Excel template by clicking on the picture.

DanceGameGORoadmap

The roadmap above takes the Vision Board contents, and shows how the strategy is executed over the next 12 months. It states the planned major releases with their goals, key features, and metrics. Version 1, for instance, is focussed on user acquisition, version 2 on activation and revenue generation. Version 3 is about retaining existing users, and version 4 targets a new segment and tries to acquire new users. (I discuss in more detail in my post “The GO Product Roadmap”.)

Your roadmap should tell a coherent story about how the product is likely grow: Choose the goals carefully and consider their relationships.

Which timeframe your roadmap should cover and how often you want to create a major release / new product version depends on your product. You should be reasonably confident about your roadmap and avoid speculation. You can regard the roadmap goals as hypotheses, but they should be informed assumptions, and not wild guesses.

If you cannot look further than the next release, then do not employ a roadmap!


Step 3: Derive your Product Canvas/Backlog

With your GO roadmap in place, you can now take the next step and use the product roadmap to stock your Product Canvas or product backlog. The GO roadmap provides you with the goal for the next major release, the two to three key features, and the metrics, which are a great starting point for discovering the product details including the user journeys, epics, the visual design, and the nonfunctional requirements.

GOProductRoadmapProductCanvas

The GO roadmap connects the Vision Board / Business Model Canvas to the Product Canvas/backlog; it links market insights and business model with the product. What’s more, the roadmap allows you to focus your Product Canvas/backlog on the next major release, which results in a smaller and more manageable canvas/backlog that is easier to change and update.


Step 4: Pivot or Persevere?

The process I have suggested so far sounds rather sequential: Do some problem validation work, then build the roadmap, and derive the Product Canvas to develop the product. This may give the impression that the GO product roadmap is a fixed plan that simply has to be executed. But the opposite is true.

Whenever we create something new – be it a brand-new product or new features – the one thing we can be sure of is that our initial ideas don’t work out as planned. As you collect feedback from users and customers on your prototypes, product increments, and MVPs, you should always ask yourself if your product strategy is still valid.

Say we expose an early prototype of the dance game to a test group. But unfortunately, we have to recognise that the kids are less excited by the game and playing it much shorter than anticipated. This data should make us rethink our strategy by asking ourselves if our market assumptions (segment and problems/needs) are wrong or if the user experience provided by the product is adequate. In both cases we have to pivot and change the strategy together with the product roadmap, as the following picture shows.

GORoadmapPivot

Note that the picture above assumes that the Vision Board / Business Model has to be changed in addition to the roadmap. That’s not necessarily true if the UX or features of the product are inappropriate but the market and business model-related assumptions are valid.

Be prepared to throwaway your existing GO product roadmap and to create a new one.

To minimise any rework, do the necessary problem validation work recommended in step one, and keep your product roadmap focussed and concise. The more details you add the more attached you become to your roadmap, and the harder it is to let go.

Once you have reached product-market fit and are confident that you are building the right product for the right people, I recommend you review and adjust your roadmaps on a regular basis, for instance every two months, as part of your portfolio management process.


Learn more

You can learn more about working with the GO product roadmap by attending my Agile Product Planning training course.

Please contact me for product roadmap workshops and webinars.

Source: http://www.romanpichler.com/blog/working-go-product-roadmap/

RSS Feed

Tags related to this post:


5 comments on “Working with the GO Product Roadmap

  1. Tom Jackson

    FYI the link on “Business Model Canvas” in Step 1 is broken

    • Roman Pichler

      Thanks for letting me know. It’s now fixed.

  2. Eduardo

    Hi,
    How can you forcast what kind of features you will have in the quarters without estimation ?
    How the delivery team will feel about that ? You are telling what to deliver and when !
    Could you help me to understand it ?

    Regards,

    Eduardo

    • Roman Pichler

      Hi Eduardo,

      Great question! There are two things I’d like to point out before I share my answer: First, the features on the GO roadmap serve the goals, and every feature should be derived from a goal. Second, state the features so that they create a shared understanding of what needs to be done, but keep them coarse-grained. Don’t include details, or say to which extend they will be delivered.

      Understanding how much can be achieved in a given timeframe is always particularly tricky when a new product or major product update is developed. In this case, I recommend determining the Window of Opportunity, that is, the latest point in time when you have to have a first product (the Minimal Marketable Product) ready for launch. (I have described this planning approach in more detail in my book “Agile Product Management with Scrum”.) Then consider the people necessary to create the product and derive the initial budget.

      Once you have started the first iteration, measure how fast the team can go, and how much your Product Canvas/backlog changes. In Scrum, you can use the release burndown chart assuming that the team has estimated the items on your canvas/backlog; in Kanban, you can calculate the average lead time. Then compare the data to your target launch date.

      Does this help?

Leave a Reply

Your email address will not be published. Required fields are marked *