“How do I create a product roadmap in an agile context?” is a common question I am asked. After answering, “it depends” for quite some time, I’ve finally sat down to share my thoughts. In this post, I explore what a product roadmap is, the benefits it can provide in an agile context, when it makes sense to employ a roadmap, how the product roadmap and the product backlog relate, and who should own the product roadmap.

What is a Product Roadmap?

A product roadmap is a high-level plan that describes how the product is likely to grow. It allows you to express where you want to take your product. Here is a sample product roadmap that shows the anticipated development of a virtual shopping assistant:

The roadmap above states the product version, the launch date, and a summary of the new functionality.

What Benefits does a Product Roadmap Provide?

A product roadmap can provide the following five benefits: First, it helps you communicate how you see the product develop.

Second, it helps align the product and the company strategy. By anticipating how the product is likely to grow you can show how the product helps the organisation reach its goals. This makes it easier to secure a budget for the next fiscal year.

Third, a product roadmap helps manage the stakeholders and coordinate the development, marketing, and sales activities.

Fourth, a product roadmap facilitates effective portfolio management, as it helps synchronise the development efforts of different products.

Last but not least, using a roadmap supports and complements the product backlog. This allows the backlog to focus on the tactical product development aspects, as I explain in more detail below.

When should I Use a Product Roadmap?

I usually create a product roadmap once I can realistically anticipate how the product is likely to develop in the next 12 months. This typically implies two things: First, the assumptions about the target group, the needs to be addressed, the key features, and the business model contained in the product vision board have been validated. Second, the first version of the product has launched successfully. In other words, the product has stabilised and is now being updated, as the picture below illustrates:

While the product vision board is great to develop and launch the first product version, a roadmap allows you to peek further into the future and to capture how the product strategy is likely to be implemented over time. This, of course, only makes sense if you can look ahead with some confidence!

How do the Product Roadmap and the Product Backlog Relate?

As I’ve mentioned above, using a product roadmap can benefit your product backlog. Here is why: As the roadmap takes care of the strategic product planning aspects, it frees the backlog to focus on the tactical work, as the picture below illustrates.

Say you release a new product version every three months. I would then suggest that your product roadmap should capture the next four major releases, while your product backlog focuses on creating the next product version.

What’s more, the product roadmap provides the context to re-stock and manage the product backlog in a meaningful way, for instance, to decide if a new epic should be added, or if it should be addressed by a future release and therefore be included in the roadmap. Consequently, the product backlog becomes more concise and contains fewer items. A concise backlog creates transparency, and is easier to manage.

The following table summaries the differences between the product roadmap and the product backlog:

Who Owns the Product Roadmap?

As the product roadmap captures decisions about the product’s futures, the individual responsible for the product success should own the roadmap. In an agile context, the product owner should hence manage the product roadmap. The team members and stakeholders contribute, as the following picture suggests.

Having one person in charge of the product roadmap and the backlog joins up the strategic and the tactical product aspects, and establishes clear authority and responsibility.

Summary

A product roadmap allows you to communicate where you want to take your product. If applied correctly, the product roadmap and the product backlog complement each other nicely. But before you create your roadmap, make sure that you are able to forecast how your product is likely to develop in the future.

Learn more about working with product roadmaps by attending my Agile Product Management training course.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

I love using personas for my own products and in my client-facing work. But for quite some time, I was looking for a good template that allows me to effectively capture the relevant information. After experimenting with different approaches, I believe I have come up with a helpful format, which this blog post introduces.

Personas in a Nutshell

I was recently helping a client with a new product to be developed for an existing market. When the team began sharing all their ideas about features and functionality, my head started to hurt. So I stood up, grabbed a pen, went to the flip chart, and asked: Who do you think are the users of the new product? And what are their main characteristics and their needs? In no time had we come up with preliminary personas: fictional users and customers.

The great thing about personas is that they invite us to view the product from the user’s perspective. This helps us design a product that truly benefits its users. It avoids getting stuck in longwinded discussions about features, features, and more features. It allows us to explore if a feature would actually benefit one of the personas. Think about all the products you have come across where you asked yourself why the product is so difficult to use. Chances are that the people responsible for creating it did not carefully walk in the user’s shoes. Take the struggle I had this morning with our dishwasher: One of the clips that attaches to the tray had come lose. Clipping it back in turned to be fiddly and difficult. The design must have been optimised for production, and not for the user.

Working with personas implies a user-centric approach: We have to put the user first, and build a product that wants to do a great job for the user. As a consequence, the product becomes a means to an end. It exists to serve its users.

A Persona Template

There are three pieces of information I have found particularly important when working with personas: First, the persona’s picture and name; second, the relevant characteristics such as demographics, lifestyle, and job-related information: third, the need that the persona has or the problem that the product should solve. I therefore use the following structure to describe a persona:

The first two sections in the template above describe who the persona is. The last one is particularly important, as it makes us ask why the persona would want to purchase or use our product: The needs are often more important to develop a great product than the demographics.

Here is an example of how the template can be applied. It features a persona of a new book I have recently started to work on:

Notice that I have tried to make the persona description as relevant as possible. I have left out information that is not essential to understand who the character is and why the person would want to read the book. For instance, I decided not to include Peter’s marital status. At the same time, I have tried to be as specific as I can right now about the persona, so I can validate my assumptions. As I find out more about the target readers of the book, I will undoubtedly iterate over Peter’s description, and update it. While refining your persona, ensure that the character is believable and that its description allows you to develop empathy for it. You can do this, for instance, by adding pictures, likes and dislikes to the characteristics.

Visualising Personas

I prefer to capture personas on paper, so I can easily visualise them by pinning them on the wall or the product vision board, as the picture below illustrates. An A4 or A3 sized paper sheet usually does the job.

Another big advantage of using paper-based personas is the limited space available. This helps to focus on the relevant information rather than writing everything down we believe to know about the user.

Summary

Personas are a great technique to capture information about users and customers. They help create a product that serves its user. Employing the persona template introduced in this post helps us capture the relevant information and focuses our effort. With preliminary personas in place, we can start to explore how the needs can be best addressed, create a first prototype, and test our assumptions. I will write more about using personas in an agile context in one of my next posts. So stay tuned ☺

If you get a chance to experiment with my persona template, then I’d love to hear from you! Write a comment, tweet or email me.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

A well-groomed product backlog facilitates the development of a successful product: It incorporates the team’s learning, and provides items that are ready to be implemented. But when should grooming take place? Before the new development work starts or at a later point in time? And how can you decide which option is appropriate for your product? Continue reading to find out the answer.

Option 1: Grooming Takes Place before New Development Starts

Your first option is to groom the product backlog before any new development work starts, as the picture below illustrates. This includes obtaining feedback from users and customers, analysing it, integrating the learning into the backlog, and getting the product backlog ready. (Please see my post “The Product Backlog Grooming Steps” for a more detailed discussion of the grooming activities.)

Grooming takes place before more development occurs

Choose this option if you require feedback from customers and users to decide if and how to take your product forward. Let’s say you develop a new product and you are trying to understand if the solution addresses the user needs selected. It would then be advisable to collect the relevant data, for instance, by demoing the latest product increment or releasing it to the users, to analyse the data, and to integrate your insights into the backlog before you continue developing the software.

Employing this option may mean stopping coding for a few days before the relevant data is obtained and analysed. But this can be preferable over rushing on, only to find out later that the direction taken is wrong, and all the hard work has to be undone.

Option 2: Grooming Takes Place after New Development has Started

Your second option is to continue the development work while you are collecting and analysing the user feedback. The grooming is hence delayed, as the image below shows.

Grooming takes place after more development has started

Choose this option if you do not require the user data to continue developing your product. To put it differently, doing more coding without having first analysed the user feedback does not imply a significant risk of taking your product in the wrong direction.

There are two scenarios when delayed grooming may makes sense: Imagine you develop a new product and you are waiting for user feedback on the latest product increment. Now you want to validate a new, independent assumption, for instance, that you have selected a viable revenue source. So you decide to continue the development before you have analysed the feedback. Similarly, delaying the grooming work may be acceptable if you develop a mature product where swiftly reacting to user feedback is often not as critical.

Summary

Choosing the right point in time to groom your product backlog minimises the risk of developing the wrong product. It may be tempting to delay the grooming work, as it can be easier to write code than talking to target users and customers. But you should only employ this option if you do not require user input to decide how to take your product forward. Have the courage to stop and reflect on the feedback obtained rather than ploughing through your backlog items. To learn more about product backlog grooming, book a place on my Mastering the Product Backlog training course, or get in touch.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

Grooming the product backlog means managing the backlog. This is necessary, as the product backlog changes and evolves: The team gains knowledge from exposing a product increment to the users, and the latest insights lead to a backlog update, as the picture below shows.

Much of the existing advice on product backlog grooming focuses on getting the backlog in shape to supply the development team with concise stories. Unfortunately, evaluating user feedback and integrating it into the backlog has been underemphasised. This blog posts tries to set the record straight by offering a holistic, five-step grooming process – from analysing user feedback to getting the backlog “ready”. Please note that I focus on new or innovative products rather than incremental updates of mature products.

Step 1: Analyse the Feedback

Grooming the product backlog starts with analysing the feedback collected from exposing a product increment to target users and customers. The increment may be working software, or in the case of a brand-new product, a paper prototype. The data obtained may be quantitative, qualitative, or both depending on what’s feasible and beneficial. I prefer to work with both, qualitative and quantitative data.

When evaluating the feedback, focus on the data that is relevant to test your ideas and answering your questions. Have the courage to say no to new ideas and requests if these are not helpful to move you closer to your vision. Otherwise, your product is in danger of becoming a feature soup, a loose collection of features with little or no connection, which usually results in a poor user experience.

Be aware of the cognitive bias we all have, your hidden assumptions and wishes, as these can lead to ignoring or misinterpreting data. To mitigate the risk, analyse the feedback together with the team members. Remember that negative feedback is good feedback: If all you ever hear is positive, you are not learning anything new.

Step 2: Integrate the Learning

Once you have analysed the feedback, incorporate your insights into the product backlog. This results in removing, adjusting, and adding content: epics, operational constraints, design and workflow sketches. If the feedback invalidates you assumptions regarding the target group, the user needs, and the business model, you may have to adjust your vision board, remove the product backlog content, and restock your backlog.

Note that in the image above, the product backlog board’s top section is empty, as the high-priority items have been consumed, and new ready stories still have to be created. (This is done in step 4.)

Step 3: Decide what to do Next

After incorporating the learning into your backlog, decide what to do next. Ask yourself why you want to carry out the next cycle. What do you want to learn? Which ideas and assumptions do you want to validate? Which functionality do you want to provide? For new products or innovative features, your goal should be a testable hypothesis, for instance, by using the following format: If we do x, we will achieve y.

My goal for writing this blog post, for instance, is twofold: Consolidate my knowledge about the grooming process and understand if my recommendations resonate with my readers. The first sub goal is met by making time to write the post. The second one is attained if the post gets a comparatively high number of hits, generates a certain amount of Twitter traffic, and attracts meaningful comments.

Step 4: Create Small Stories

Next, carve stories out of the epics in order to reach your goal. Then make the stories high-priority, and order the stories according to their importance for reaching the goal, as the image below shows.

You may also want to ask the team to estimate any epics that have been added or adjusted as well as the newly formed stories. This allows you to understand how much effort is roughly contained in the backlog.

Step 5: Get the Stories Ready

With small, ordered user stories in place, you are close to starting the next cycle. But before you do so, ensure that the stories are “ready”: clear, feasible, and testable. This may entail creating a user interface design sketch and one or more operational quality constraints for the stories, as the image below illustrates.

Getting the stories ready may also require resolving dependencies between teams if several teams work on the same product. The stories should now be ready to be pulled onto the sprint backlog or the Kanban board.

Leverage Teamwork

When I talk to product owners about grooming their backlog, I often discover that the individual carries out the work largely alone. This wastes a massive opportunity: to mitigate the product owner’s cognitive bias, to create shared ownership of the backlog, and to leveraging the team’s collective wisdom and creativity.

As the product owner, involve the team members in the grooming steps. This reduces your workload, and it is likely to result in a better product. Don’t be afraid, however, to facilitate the discussions and to make a decision if no consensus can be reached. You don’t want to get stuck in analysis-paralysis but move on, and test your new ideas and assumptions.

Summary

When grooming your product backlog, don’t forget to collect and to analyse the user feedback. Integrate your insights, select your next goal, write small, detailed stories, and get them ready for implementation. Rely on your intuition as well as the data analysis, and involve the team in the grooming steps.

If you want to learn more about the product backlog, book a place on my Mastering the Product Backlog course in May in London or in September in Cambridge, or contact me.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

The role of design still puzzles many Scrum and Kanban teams I work with. When should the design activities take place? Who should carries them out? How are design decisions best captured? This blog tries to answer the questions by introducing my preferred design approach.

User-centric, iterative, and collaborative

The image above depicts the design process I employ. It’s user-centric, iterative, and collaborative. The process starts with capturing the design concept in form of a rough mock-up. Then the detailed design for one or more user stories is created and implemented as a throwaway prototype or as shippable software. The result is exposed to the users to understand if the design contributes to a great user experience. If it does, the design is refined, and the design for the next stories is created; if it does not, the design concept is reworked.

High-level Design

To get started, develop your design concept. The concept should sketch your key design ideas and communicate the essence of what you believe the product should look like. This includes the shapes and the colours you intend to use. Keep the overall product vision in mind together with the desired user experience: the kind of product being developed and the reason why people might want to use it. Focus on the critical aspects and don’t worry about the details right now.

For instance, the high-level design below shows how the structure, shapes and colours of our new homepage together with a photo of a bald guy with a beard and sticky notes.

High-level website design

Capture your design concept as a mock-up. Consider using a paper sketch similar to the one shown above. Paper sketches require less effort than wire-frames or other mock-ups; they are usually good enough to communicate the design idea. Make your sketch visible and put it on the product backlog board as shown below.

High-level design on the product backlog board

You may also want to explore the anticipated interaction of a user with the product, and to capture it as an interaction diagram or workflow. Put the resulting artefact on the board’s model area. (You can find out more about the backlog board in my blog post “The Product Backlog Board“.)

Detailed Design

With your design concept in place, create the design for each user stories you want to implement. This is best done as part of the product backlog grooming work. Developing the detailed design should hence be a collaborative exercise that involves the developers and testers. This allows you to leverage the team’s collective creativity and to quickly discover which design options are difficult and expensive to implement.

Sketch the user story-specific design on a paper card and attach it to the story card, as the image below illustrates. The design depicts the details of one of the boxes on the homepage:

Detailed design for a story

Then implement the design either as a throwaway prototype or as shippable software, and expose the result to the users. Note that paper prototypes are often sufficient to test your initial design ideas. Resist the temptation to create a perfect design straight away: An unpolished implementation tends to generate more valuable user feedback than a super slick design.

Learning

Leveraging the user feedback to validate your design ideas does not mean that you don’t require a vision of what the product should look like. The opposite is true. You have to innovate for your users and cannot expect to be told what the product should look like.

Take the redesign of our website for example: Our customers, the organisations that pay for our training or consulting services, are important users of our website. Most of our customers are mid-sized to large enterprises. Having worked for large companies myself, I know that bigger organisations often prefer a more conservative look. But we wanted to create a website that that looks cool and that we like, not a boring corporate design. The challenge is hence to synthesise the wants and needs of the users and your own vision and ideas into a great design.

Synthesising needs and vision

Use the feedback to experiment and discover which design ideas don’t work and which do. Don’t be a slave to the feedback, but don’t cling to your ideas either. Analyse the feedback with an open mind and decide what to do: take it on board or discard it. Then either rework your design concept or adjust it, and create the detailed design for the next story.

Summary

Creating the design iteratively, taking advantage of the team’s collective creativity, and leveraging user feedback to validate design ideas maximises our chances of developing a product that with a great user experience, a product that users love. Happy designing and please let me know if my thoughts are helpful. I look forward to your comments!

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler