“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.
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.
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.
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!
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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“.)
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.
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.
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!
Getting lost in the product details and struggling to decide if a feature should be implemented is a common challenge for product owners and product managers. It’s something that happens to me all the time, even while I was writing this post. But as product owners, we should focus on what really counts: creating value for the people using the product and the organisation developing it.
Some product owners I work with worry too much about how to write a certain user story or what the detailed design of a screen should look like. Whenever this happens, I find it helpful to step back and ask the following questions: Why would anybody want to use the functionality? Why would a certain design be helpful?
I know the image above looks pretty trivial. But it took me a few iterations to create it. I started out with a more elaborate design, which I dropped after I reflected on the desired user benefit: Glancing at the images should allow the reader to understand the gist of the blog post. Selecting a simpler design hopefully achieves this goal better.
Exploring how a story or design idea benefits the users means viewing the product as a means to an end: to serve the users as well as the organisation creating it. As marketing guru Theodore Levitt famously put it, “People don’t want a quarter-inch drill, they want a quarter-inch hole.” What really matters are the benefits the product provides.
I find that personas and scenarios are great to hypothesize about the users and their needs. A persona allows us to capture assumptions and ideas about what a typical user might be. The scenarios describe the user’s problem, how our product should benefit the user together with the desired user experience.
While serving the user should be the primary purpose of your product, you shouldn’t forget about the value the product has to create for your organisation. To do so, reflect on the business model that will help you achieve your business goals. This includes identifying the revenue streams, the sales channels, and the cost structure. A great tool to analyse and improve your business model is the Business Model Canvas created by Alexander Osterwalder and Yves Pigneur.
Be aware that your business model can have an impact on the product functionality: For instance, if you plan to generate revenue through online ads, then this requires the capability to place ads. As a consequence, an ad epic will appear in your product backlog.
To capture your ideas about user needs, the product, and the value created for the company, you may want to try my Product Vision Board. The board captures assumptions about the target group, the user needs, the top three features, and the key business model elements.
If you find it difficult to balance meeting the user needs and creating value for your organisation, then focus on the user. If your product is desirable, you are likely to find a way to make money. Users should come first, money second.
Next time when you get stuck in the product details, zoom out. Ask yourself how a feature adds value for the users and your organisation. Then implement it, gather the relevant data, and check if the benefit has been realised. Happy developing!
If you grew up as a teenager in the 1980ies like me, you are probably familiar with the quote “There can only be one” from the first Highlander movie. Interestingly, this statement is also true for product owners: There should only be one product owner per product. But don’t worry: You don’t have to become an immortal warrior to understand the Highlander principle. Reading this blog post will do the trick.
Traditionally, product ownership tends to be distributed across several individuals: A product marketer, for instance, writes a product concept or market requirements specification, and a product manager turns it into a product requirements specification. A project manger is then tasked with executing the project, and works with a business analyst, requirements engineer, or architect to analyse and refine the requirements.
While distributing product management responsibilities supports a linear, phase-and-gate-based process, it is not well suited for an agile environment characterised by rapid delivery and fast learning. Additionally, the handoffs between the different individuals can cause defects, delays, loss of information, and other waste; decision-making can be slow and may result in weak compromises; and if the product fails, a blaming game is likely to start.
The alternative is to put one person in charge of the product; the individual leads the product development and owns the product on behalf of the company. This integrates strategic and tactical product management aspects. It unites authority and responsibility, and speeds up decision-making.
Meeting the user needs, creating a desirable user experience, and designing a sustainable business model receives the attention and leadership it requires. It increases the likelihood of realising the vision by delivering an attractive, well-rounded product.
Just like Connor, the main character in the Highlander movies, needs friends and allies, so does the product owner. To mitigate the risk of a single product owner being overworked or making suboptimal decisions, the Highlander principle must be complemented by collaboration: Leveraging the ideas of users and customers by gathering feedback on working software; and using the knowledge and creativity of the development team by jointly grooming the product backlog.
Working with a single product owner role can be particularly challenging on complex products or large projects. But you certainly don’t have to be an immortal or in the movie business to apply the role effectively. On complex products or large projects, you have two options: You can either employ a product owner hierarchy with a chief product owner in charge of the entire product and product owners responsible for features.
The alternative I prefer is to break up complex, feature-rich products into several lean, vertically aligned sub products, each owned by a single product owner.
A benefit of working with a product suite is that the sub products can be developed and released largely independently. Additionally, scaling issues can be avoided or at least reduced.
Learning from user feedback quickly requires effective decision-making. By putting one person in charge of the product, rapid experimentation, learning, and delivery are facilitated. Combining strong product leadership with collaboration and teamwork increases the chances of creating a great product.
No immortal warriors required. Promise.
When I teach product owners, one of the questions I ask is: “What qualities should the product backlog fulfil?” More often than not, a key property is missed: emergence. This corresponds to my experience of how backlogs are commonly used: as a requirements list that doesn’t change much. Instead of being rigid and fixed, the product backlog should be dynamic. It should evolve based on customer and user feedback thereby facilitating the discovery of the right product features, as this blog posts explains.
At the beginning of a new product development project, there are many unknowns, and we often do not understand what the product should look like and do in detail. Our initial thoughts about the product resemble more ideas than hard-and-fast requirements. We should therefore treat the items of an initial product backlog as assumptions that have to be validated and refined using the feedback from customers and users. This allows us to better understand how we can best solve the customers’ problem, and what the product should really look like and do.
To turn your backlog into a learning tool, expose product increments early and regularly to customers and users, for instance by demoing the increment or by releasing it. Then evaluate the feedback you receive, and decide which changes are required, as the following diagram illustrates:
When evaluating feedback, avoid two common mistakes: clinging on to your ideas and ignoring what your customers and users tell you, and saying yes to every piece of feedback, any new idea, or feature request.
Analyse the feedback carefully with your product vision in mind. Ask yourself if the feedback is helpful turn the vision into a great product – assuming that your vision is valid. If the answer is yes, incorporate the insights gained. Remove or change existing product backlog items, and add new ones. Your product will consequently evolve through on-going dialogue with customers and users.
Adjusting a large, detailed product backlog usually takes too much time and is error-prone. Focussing your backlog and keeping the majority of its items coarse-grained helps you achieve the necessary conciseness.
If you are developing a brand new product, you may want to restrict the backlog scope to creating a first product increment that allows you to gather customer feedback (aka minimal viable product or MVP). Then use the feedback to decide if and how to proceed.
Keep the majority of your backlog items sketchy and coarse-grained. A great way to do this is to employ my product backlog board and to capture ideas as epics. Identify the epics that exhibit risk and uncertainty, and select the ones you want to test with the next product increment. Then derive small stories from the epics and make them high priority.
Viewing the product backlog as a learning tool facilitates the development of successful products. But it requires overcoming the misconception that the requirements of a new product can be correctly determined upfront. We stand a better chance of success by using early and frequent feedback from customers and users to validate our ideas. As Ken Blanchard says: “Feedback is the breakfast of champions.”
With the term startup we usually associate starting a new company and pursuing a new idea with a small, creative team. While Scrum has been used for many years in startup companies – companies with a limited operating history – I have found that setting up a Scrum team as a “startup” or incubator within an established enterprise is a powerful approach to create a new product, and to pilot a new way of working.
A Scrum Startup consists of the product owner, the ScrumMaster and the development team. Together, they form is a self-contained unit that is loosely coupled to the rest of the organisation and in charge of developing and releasing the product. The product owner acts as an intrapreneur, an entrepreneur within the larger organisation.
The Scrum Startup
The first Scrum project I helped run in 2004 had ambitious plans: It was tasked with creating a new enterprise telecommunications software product. The company had high hopes for the product: It was considered vital to the business group’s future. To create an environment that encouraged innovation and creativity, we opened up a new development site, and assembled a new team.
We also made sure that the product owner was able to act as an intrapreneur and received the backing from senior management. The individual had a vision for the new product and a budget to turn the vision into reality. The Scrum Startup controlled the product under development including the development and test environment, and it experienced few changes to the team composition. The individuals had a personal stake in the outcome: Everybody desperately wanted the new product to succeed knowing that it would shape future of the group.
We didn’t quite realise it, but we had created a startup within a well-established, large enterprise: Siemens, a company which has more than 420 000 employees and which is over one hundred years old. The resulting product became part of OpenScape Unified Communications. It has won a number of awards, and is still selling well.
Setting up a Scrum team as an incubator is so powerful as it disentangles the team tasked with innovating from the rest of the organisation. Think of a Scrum Startup as a new house in the enterprise village, or a new tree in the corporate garden.
The Scrum Startup and the Enterprise
The members of the Siemens telecommunications project were free to literally think outside the box, to try out new things, and to be creative. Most importantly, it created a safe environment for experimentation: for testing new ideas and for failing. Our first minimal viable product (MVP), the product increment of the second sprint, turned out to be a failure: We had chosen the wrong component technology, and the product did not live up to the users’ performance expectations.
Our first process experiment ended in failure too: We had started using a heavily tailored, lightweight version of the Rational Unified Process (RUP) that included development practices from Extreme Programming. After a few iterations, we decided to switch to Scrum. The RUP iteration management and collaboration practices simply did not work for us.
Without those early failures and the learning that they enabled, we probably would have not been able to deliver a successful product.
As important as autonomy is, it needs to be balanced with collaboration: working together within the Scrum Startup and with the stakeholders. A healthy, trustful relationship between the product owner and the team, the product owner and the ScrumMaster, and the ScrumMaster and the team is a prerequisite for applying Scrum successfully and for creating a great product. But it’s no less important to invite internal stakeholders to participate in the development process, and to use the feedback from target customers and users to create a product with the right features for the right people.
Scrum Startup and Collaboration
When we created the telco product, we invited representatives from marketing, sales and service to the sprint review meetings, and we demoed MVPs to other development groups destined to build on the product. Releasing early product increments to employees in other parts of the enterprise is another great way to benefit from the ideas of the rest of the organisation, and to keep people informed about the progress. Exposing product increments early and frequently to target customers and users in form of demos or releases helps to achieve a great product market fit.
To help your enterprise Scrum Startup succeed, make sure it fulfils the following four properties: It should be loosely-coupled to the enterprise and in control of the product; the people working on the product should have a personal stake, and the incubator should be stable. The following image depicts the four qualities:
Desirable Qualities of a Scrum Startup
Reflecting on more than ten years of experience using agile techniques to create products and helping organisations establish Agile, I am convinced that combing the introduction of Scrum with a new product development effort and setting up the Scrum team as an incubator can facilitate product and process success. Give it a go, and let me know how it’s working for you.
I find the Lean Startup concept of a minimal viable product (MVP) rather exciting: It entails creating a first product version to test our ideas as quickly and cheaply as possible. This could be a throwaway prototype such as a mock-up or a product increment, working software that is tested and documented. The MVP works together with a build-measure-learn cycle: developing software, gathering customer feedback, and learning from it.
Build, Measure, Learn
With roots in the Scrum tradition, this sounds rather familiar to me: Validating assumptions by gathering customer feedback using product increments is called empirical management or inspect-and-adapt in Scrum.
But Scrum advocates the use of a product backlog containing the outstanding work necessary to create a successful product. How does the backlog fit into the picture? And can the product backlog be helpful to create a minimal viable product?
This blog posts answers this question and investigates how Lean Startup and Scrum concepts can be combined successfully.
“If I had asked people what they wanted, they would have said faster horses,” said Henry Ford famously. A vision, an idea of the future product, is the start of any successful innovation. Without a vision, we lack a shared goal, a common direction.
To reach our goal, we have to decide on an approach or strategy. This includes making assumptions about the target group, the needs the product should address, the key product features, and the value it should create for the organisation developing. I use my vision board to capture and visualise the product strategy.
The strategy’s assumptions must be validated. A great way to do this is to create the minimal viable product and to release it to the target customers and users.
Unfortunately, the product strategy is often too coarse-grained and partial to be used as a direct input for writing software. It can therefore be helpful to take an intermediate step, and to identify the work that is required to validate the strategy.
The corresponding items are placed in a sketchy, lightweight product backlog. To put it differently, the backlog is derived from the product strategy; it makes the strategy implementable.
Vision, Product Strategy, Product Backlog
Once we have a strategy and initial product backlog available, we create the minimum amount of functionality necessary to test our assumptions. This may take a day or two, or one or more sprints with a preference for the shorter timescales. Our goal is to find out quickly if the product generates a positive response amongst the target users and customers, and if the target group members use the product in the intended way. Once we’ve created the MVP, we release it and gather the relevant data.
Strategy, Backlog, and MVP
Note that releasing the MVP can be limited to a small group of users if the respondents are representative for the target group. Google, for instance, released early versions of its Chrome browser internally and asked its employees to test the software and to provide feedback before a first public beta was released in October 2008. A counter example is Google Buzz: The software was apparently loved by Google engineers, but unfortunately not by the rest of the world.
Once we’ve gathered and evaluated the feedback, we need to decide if and how to act upon it. If the feedback invalidates any assumptions in the product strategy – which is likely to be the case when a new product is developed – we should adjust it together with the product backlog. Making changes to the strategy is also called pivot.
We may decide to change the target group or the needs selected, for instance; maybe the features or the look and feel envisioned is not right; or the business model does not work as expected, for instance, users never click on the ads displayed. Changing the product strategy can require restocking the backlog. With the backlog updated, we continue with the next cycle, develop a new MVP, and gather new feedback.
Pivot
If the data confirms our strategy, we preserve and adapt the product backlog by incorporating the insights gained. Depending on the quality of the MVP, we may have to throw away any mock-ups and prototypes created so far, and start afresh developing tested and documented software using agile development practices. If the MVP is a product increment, we can progressively transform it into a shippable product using a series of sprints.
Persevere
Using a minimal viable product is a powerful concept to validate the product backlog that be used in harmony with Scrum’s approach of creating working software, exposing it to customers and users, investigating their feedback, and making the necessary adaptations. Many thanks to @stefanroock for feedback on the first MVP of this post.
If you’ve found this blog post interesting, you are likely to benefit from my Agile Product Management training. The course teaches a combination of Lean Startup, Scrum, Kanban, and Design Thinking techniques. Check it out!
Applying the product owner role can be challenging, as no two products are the same. While products and projects vary, I have found two common ways to employ the role: Asking the customer or a customer proxy such as a product manager to take on the product owner role. This post discusses when the two alternatives are appropriate together with their advantages and challenges.
One way to apply the product owner role is to ask the customer to play the role. This option is particularly useful for the development of bespoke (custom) software. For instance, if a web application is developed for a company’s marketing group – either by an in-house team or by an external software provider – a member of the marketing group should take on the product owner role. This approach is illustrated by figure 1:
Figure 1
Advantages: The customer steers and controls the development of the software directly. This allows the customer to own the product, speeds up decision-making, and increases the likelihood of creating a product that serves the customer needs.
Challenges: The customer must be available, qualified, and empowered to create a successful product. The customer and the team must value transparency and develop a healthy, trustful relationship. The latter tends to be particularly challenging when the customer and the team have different interests, for instance, getting the essential features shipped as soon as possible vs. maximising revenue, or if they have had difficulties to collaborate in the past (“IT never delivers”).
Alternatively, we can decide to separate the customer and the product owner role. This option is applicable when software is developed for several customers, for instance, when a commercial software product is created or when different departments of the same company use software developed in-house. In both scenarios, the product owner acts as a customer proxy who listens to the ideas and requirements of the customers and users but decides when which features are released. Figure 2 summarises this option:
Figure 2
For comercial software, a product managers typically takes on the product owner role. For software developed in-house, a project manager or business analyst may play the role. Note that figure 2 illustrates the main communication paths. Team members talk to customers and users directly of course, for instance, in the sprint review meeting when discussing improvements to the product. (But ultimately the product owner decides which improvements are implemented.)
Advantages: Separating the customer and the product owner role helps create a product that addresses all the needs selected. It also provides the opportunity to employ professional full-time product owners with the right skills: Product managers, project managers, and business analysts can focus on playing the role effectively.
Challenges: Empowerment of the product owner can be difficult to achieve: Product owners often require the trust and support of senior management to be able to make the necessary decisions, to have the clout to say no, and to create stakeholder alignment. Companies that regard IT largely as a commodity can find it difficult to value product ownership and to invest in developing product owners.
I recommend that you apply one of the patterns described above to each of your products. To put it differently, a product should either be managed by a customer or by a customer proxy. But there is no reason why you cannot mix and match the two patterns across your portfolio: Choose customer product owners for bespoke products and customer proxies for products that serve several customers.
To create a new product, we have to peek into the future and anticipate what the product will roughly look like and do. For anyone not blessed with perfect foresight, predicting the future correctly is notoriously difficult. After all, the only thing certain about the future is that it is uncertain! No market research technique can deliver a forecast that is 100% accurate. And in the case of disruptive innovations, it’s not possible at all to make a sound prediction, as Clayton Christensen observes in his book The Innovator’s Dilemma: “Markets that do not exist cannot be analysed.” Investing in a new product hence always involves risk. We may have targeted the wrong market segment, envisioned the wrong product or the wrong features, or the market may have changed by the time the product is launched.
A great strategy to minimise the investment risk is to envision a lean, minimal product with the smallest possible feature set. I refer to such a product as the minimal marketable product. It contains just enough functionality to be viable – to launch, market and sell the product successfully. Developing a minimal product is quicker and cheaper than a more ambitious, feature-rich one. If the product bombs less time and money is lost. If it is a success, the product starts earning money sooner. Additionally, a minimal product allows us to receive feedback earlier so we adapt the product quicker to the market response. Rather than trying to create the perfect product, we follow the motto “get it out, then get it right.” Note that the product’s quality must be right from the start. Otherwise it will be difficult to adapt the product; bugs may hinder its adoption, or even damage the brand.
An example of a minimal marketable product is the original iPhone, which launched in 2007. One of the secrets behind its success is the narrow set of customer needs Apple selected. The company avoided the trap of trying to please too many people at once, of trying to copy all the features competitors offered. Instead, Apple took a fresh look at what smartphones should look like and do, and deliberately left out some functionality. The original iPhone shipped without many features standard on existing phones: copy and paste, the ability to send text messages to multiple recipients, and a software development kit, for instance. These limitations, though, did not hinder its success. Paring down the functionality allowed Apple to develop and ship the product within a competitive timeframe and gave the company a significant lead over its competitors. Building on the success of the first iPhone version, Apple started to extend the capabilities of the phone both in terms of hardware and software with the launch of the 3G model in 2008. This version also allowed the company to enter a new market segment by targeting business users.
Developing a minimal marketable product may sound like a no-brainer. But my experience suggests that many start-ups and established companies alike find it hard to restrict the features of a new product. It’s often too tempting to opt for a big-bang release trying to satisfy as many users and customers at once in order to maximise revenue. Contrast the iPhone with another Apple product: the Apple Newton, first launched in 1993 after five long years of development. Remember those Apple ads that promised a PDA that could do all sorts of wonderful things, including recognising your handwriting? When it was finally shipped, the Newton proved to be too bulky and heavy. Worse, its most important feature, the handwriting recognition, did not work properly. The product underperformed and was finally withdrawn from the market in 1998. In hindsight, Apple was overly ambitious with its Newton plans. The company launched a product that tried to do too much at once, and failed.
To create a lean, minimal product, limit the target group and “build a product for the few, not the many,” as Steve Blank recommends in his book The Four Steps to the Epiphany. For instance, if you use personas to describe members of your target group, consider the impact of removing a persona. Would the product still sell? If yes, reduce the target group by dropping the persona. Once you have done a great job for your early customers, you’re in a position to build on the initial success with a new, incremental release that attracts new customers.
Second, understand your product’s value proposition and only select the features that are essential to address the needs of the target group. Have the courage and discipline to discard all others for now. Selecting the minimal set of features does not mean creating a bland, boring or simplistic product. It means focusing on those properties that are essential for the product success. If you work with user stories, for instance, review each story or epic, and ask yourself if the product can be shipped with out it. If yes, exclude the story. As the French writer and poet Antoine de Saint-Exupery put it:
“Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away.”
“Words are but sound and fury,” says Macbeth, and there are several similar but confusing terms to denote minimal products. My termminimal marketable product is a reference to Mark Denne and Jane Cleland-Huang’s work. In their book Software by Numbers they coin the term minimal marketable feature set to denote the smallest amount of functionality creating value for a customer. As I view a product as more than a set of individual features, I prefer to talk about products rather than feature sets. The idea of quickly delivering a small set of features and enhancing the software incrementally dates back to Tom Gilb’s evolutionary delivery method developed in the 1980ies by the way.
Eric Ries has more recently popularised the term minimal viable product, which he defines as “the product that allows a team to collect the maximum amount of validated learning about customers with the least effort.” Based on this definition, the minimal marketable product may or may not be the minimal viable one. Independent of the differences, all terms share the idea to quickly launch an initial product to learn from the market response, and to adapt the product accordingly. And that’s what matters.
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.
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.
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.
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.
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.
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.
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.
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.
User stories are great at capturing product functionality from the perspective of a user or customer: Each user story describes a piece of product functionality, for instance, “As an application provider, I want to register with the application centre so that I can use its services.” By focusing on a distinct area of functionality, the story allows the team to understand, implement, and test the requirement. This strength is also a weakness: User stories are not well suited to express the relationships between different features and to describe workflows.
To show how different stories fit together, I have found it useful to complement user stories with lightweight models, originally invented for use cases: context and activity diagrams. I also add important diagrams to the product backlog, as I explain in my post The Product Backlog Board.
A context diagram that depicts user roles and epics, large and coarse-grained stories, is great to provide an overview of the product’s functionality. Let’s have a look at an example, a diagram that sketches an online application store called “Application Centre”:
The diagram above depicts three user roles: provider, user and administrator. It shows how the roles interact with epics that describe Application Centre functionality. It tells us, for instance, that the user and the administrator both review applications – to enable end user and staff ratings.
Note that the diagram does not list all epics contained in the product backlog, and it does not state all user roles. It rather focuses on the product backlog items relevant for a conversation between the product owner and the team, or the Scrum team and the stakeholders. This results in a diagram that is simple and easy to understand rather than complex and overwhelming.
To get a job done, users often carry out several steps and interact with different pieces of functionality. Activity diagrams are great at capturing sequences and workflows by connecting individual user stories. They also support the creation of complex test scenarios that go beyond a single story.
Let’s have a look at an example, a diagram that elaborates the epic “Register” on the context diagram above. It shows the key steps required for a user to register with the Application Centre:
The diagram above visualises the steps of the registration workflow by connecting three individual stories. It starts with stating the details of the provider company, continues with entering a user name and password, and if successful, accepting the usage terms and conditions.
User stories modelling is a handy tool in the product owner’s toolbox. But like any tool, it wants to be applied properly. The following tips help you create great diagrams:
Collaborative, lightweight and focussed user story modelling can help you create a shared understanding of the desired product functionality. Context and activity diagrams complement user stories, put them in a context and connect individual epics and stories. Any model related to user stories and epics should be the outcome of a conversation – and never replace it.
The product vision plays an important role in bringing a new product to life: It acts as the shared, overarching goal guiding everyone involved in the development effort. Equally important is the product strategy, the path chosen to attain vision.
As the vision and the strategy are vital, teams need a way to describe their ideas and to capture their assumptions. I’ve named the simple tool that I use the Product Vision Board. The board allows the product owner and the team to map out their product strategy, as the following diagram illustrates:
The Product Vision Board
The vision board states assumptions about the users, their needs and the desired user experience, the key product features, and the value the product should create explicit. Use the questions in the board above to guide your discussion and adapt them according to your needs. If you create an in-house application, for instance, you are likely to be less concerned about revenue sources than expected cost savings and productivity gains.
My preferred way to discover and to express assumptions about the users, their needs, and the user experience is to use personas and scenarios. This outs the focus on the user and explores how representative but hypothetical users may interact with the product. It creates a connection between the product features and the user needs.
The sample board below contains two personas, three scenarios, paper cards with the product’s top three features, an user interface sketch, and a business model sketch (based on the business model canvas):
A Sample Product Vision Board with Personas
While the “Value” section of the vision board above uses elements from the business model canvas, the vision board’s strength is to facilitate product innovation focussed on one product. The business model canvas is better at facilitating business model innovation. To put it differently, vision board and business model canvas complement each other nicely.
The product vision board is most effective when you put on the office wall where everyone can see it. Simply add the artefacts you create to the board while investigating the four product aspects. If you work on a distributed project, post a picture of the vision board on your wiki or replicate it in an easily accessible electronic spread sheet.
Don’t fall into the trap of specifying all features upfront: Select only those features that you believe are crucial to address the selected customer and user needs and that significantly influence the product success. The same is true for the product and user interface design: Focus only on the most critical aspects, and discard the rest for now. Additional ideas and the detail design will emerge later and are best captured on the product backlog board. And while it is helpful to reflect on the value the product should create for the organisation developing and selling it, providing a detailed business model and a firm business plan for a new product is often not feasible.
Most importantly, test your ideas quickly by creating a prototype or product increment (aka minimal viable product), exposing it to target users, and analysing their feedback. This is likely to result in changes to your vision board, particularly if you create a new, innovative product. See my post “The Vision, Product Backlog, and the Minimal Viable Product” for more details on how the vision board relates to the product backlog and how its assumptions can be validated.
I’d love to hear from your experiences of using the product vision board. Please share them as comments or contact me.
If you want to learn more about the product vision board, then book yourself on my Agile Product Management training course.
RSS