Tag Archives: budget

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.

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:

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.

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.

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.

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.

Determining the launch date and the budget before development starts can be tricky in Scrum. Relying solely on Scrum’s empirical approach, a team working on a new product has to carry out at least one sprint to measure the velocity and to understand the rate of change in the product backlog. For many organisations this is difficult to accept, as an investment decision is often required before the development work can start.

Frozen Requirements or No Informed Investment Decision?

Employing a traditional planning approach and trying to capture all requirements in detail upfront in the product backlog is not only error-prone when dealing with innovative products. It is also undesirable in an agile context where the product’s detailed functionality is discovered during the development through early and frequent customer and user feedback.

Does this mean that we cannot make an informed investment decision at an early point in time on an agile project? Luckily, the answer is no. This blog post discusses how we can determine the launch date and the project budget before the first sprint – without turning the product backlog into a disguised requirements specification.

Running the Release Planning Workshop

A collaborative workshop involving the right people is a great way to carry out the initial release planning: The product owner, the ScrumMaster, the team, and stakeholder representatives including a management sponsor or the customer should attend the workshop. A shared product vision and an initial product backlog now have to be in place. The former paints a rough picture of the future product, scopes the project, and acts as the shared overarching goal. The latter sketches the outstanding work necessary to develop the product. Make sure all attendees understand and buy-into the vision.

Step 1: Identify the Window of Opportunity

Based on the product vision and the backlog, we determine the window of opportunity, the time frame in which the product must be launched to achieve the desired benefits. If the date is missed, the opportunity is gone, and launching the product no longer makes sense. The work carried out to create the vision helps us identify the window of opportunity and understand if the product can be developed and launched within the window selected; we leverage the insights gained from the initial market research and technical exploration work. The beauty of this approach is that it does not require having all requirements described in detail in the product backlog. But it assumes is that the vision stays stable for the duration of the development effort.

Step 2: Determine the Budget

Once the window of opportunity and a delivery date have been identified, we can determine the budget. To do so, we ask ourselves who is required to work on the project, which skills are needed and how many teams may be required. We then add additional items such as licensees for tools and third-party software. This provides us with an initial budget.

Step 3: Make a Go/No-go Decision

Understanding the timeframe and the budget and having the sponsor or customer present, should allow us to make a go/no-go decision in the release planning workshop, and in the latter case to discuss if and how the vision and the product backlog should be adapted. Making a decision in the workshop does not only create transparency and leverage the input of the attendees. It also avoids waiting and delays and helps reduce time-to-market.

Reality Check

Once development is underway, we capture the progress at the end of each sprint in form of a release burndown chart and create a forecast for the reminder of the project. This validates the original plan. It allows the product owner to steer the project and to trade off time, budget and functionality. Note that quality is frozen in an agile context and must not be compromised. Quality compromises result in defective product increments, making it impossible to clearly see the progress and to release software early and frequently.

Summary

Using a collaborative release planning workshop and determining the window of opportunity facilitates an early investment decision and the emergence of requirements. It frees agile teams from having to describe most product backlog items in detail at an early stage, and it avoids having to carry out one or more sprints before a date and a budget can be established.

What is the essence of the product owner role? As the name suggests, a product owner should own the product on behalf of the company and be responsible for the product success, for making sure that the product creates value for its customers and users and for the company providing it.

You can think of the product owner as the individual who champions the product, who facilitates the product decisions, and who has the final say about the product, for instance, if and how feedback is actioned, or when which features are released.

The following diagram provides a summary of how I view the role of the product owner for commercial products.

As the picture above shows, a product owner should have strategic product management skills such as product strategy and roadmapping as well as tactical ones including the user experience (UX) and the product backlog. I have circled the areas, which are required by Scrum — the framework in which the role originated — in dark orange. The other areas are necessary in my experience to allow the product owner to do a great job and achieve product success even though they are not mandated by Scrum. You can find out more about the knowledge areas in my product management framework.

If you work as a product owner for in-house applications, you should adjust the picture above. Consider replacing “Marketing” with “Operations” and removing “Sales and Support”. The other areas still apply although your market will consist of the in-house users. Similarly, if you manage a tech product, you may want to promote the “Development/Technologies” area and move it to the inner circle.

I find it a mistake to view the product owner as a product backlog manager and user story writer. Instead, the role should interact with the customers and the users as well as the internal stakeholders.

The product owner of a commercial product should directly interact with customers and users, the development team, the ScrumMaster, marketing and sales and other relevant business group required, and the senior management sponsor. I have circled the Scrum team, the unit consisting of product owner, ScrumMaster and development team, to indicate that product owner should have close and trustful relationship with the other Scrum team members. Great products happen when the product owner takes her market and business knowledge and collaborates with the team members who know what technically possible.