Summary
Scrum is a popular agile framework for developing a product with the right features and the right technologies. Unfortunately, it does not state the prerequisites for kicking off a Scrum project and for starting the first sprint. As a consequence, I find it not uncommon that product managers and product owners are unsure about the work they should do prior to the first sprint. This post offers a checklist to help you do the right upfront product management work.
The Essential Upfront Product Management Work
Scrum is agnostic about the work that has to be done before you can create an initial product backlog and run the first sprint, be it for a brand-new product or for an existing one that you have just taken on. In fact, it doesn’t make any recommendations. But this does not mean, of course, that you don’t have to or should not do any work before you move into Scrum and kickoff the first sprint. As the product owner, you should do just enough work to have the following artefacts in place and be able to answer the following questions:
| Artefacts | Questions to Address |
| Shared Vision |
|
| Valid Product Strategy |
|
| Valid Business Model |
|
| Realistic Product Roadmap |
|
| Personas |
|
The items in the table above form a checklist to help you assess if you are ready to apply Scrum. You may have to tailor the checklist to you specific needs. For an in-house product, a valid business model is typically less applicable than for a commercial one, for instance. Similarly, if you build a product for a client then the strategy should address the client’s business goals rather than yours.
You can use choose from a range of tools to capture the answers to the questions above. For instance, my Product Vision Board describes the vision and the strategy, Alexander Osterwalder’s Business Model Canvas defines the business model, my GO Roadmap captures the product roadmap, and my persona template helps you describe the personas. The point is not to use a specific tool but to ask the right questions and to answer them effectively. To put it differently, if you struggle with the questions then a tool alone is unlikely to help you.
Vision and Strategy Take Priority
Of the four artefacts listed above, the vision and the product strategy are particularly crucial. You should hence pay particular attention to them and create them first. Here is why:
If you don’t have a shared vision, then you lack an overarching goal and a reason for creating the product. You will consequently struggle to motivate, guide, and align the stakeholders.
If you don’t know who the customers and the users are and why they would buy and use your product, then you cannot make informed decisions about the user experience and the product features. Imagine writing a user story without knowing who the user is. You would have to speculate and dream up the story.
What’s more, collecting meaningful feedback becomes virtually impossible, as you are likely to ask the wrong people and receive unhelpful feedback. This would cause you to draw the wrong conclusions and make the wrong changes to your product; or you would conclude that the users don’t have a clue, that you should ignore their input, and that you know what’s best for them anyway. Neither approach maximises the chances of creating a successful product.
Finally, if you don’t know what the business goals are and why your company should invest in your product, you don’t understand the value that the product should create for your business. This will make it difficult to attract funding and to get the right people.
Business Model, Product Roadmap, and Personas Come Second
Having a vision and product strategy is great but not always enough to start the first sprint effectively. For commercial software products it is also important to understand how you can meet the business goals and how you can monetise your product. Otherwise you won’t be able to create a financial forecast, and your company is unlikely to be in a position to make an informed investment decision.
Similarly, a product roadmap details the product strategy and states how it will be implemented. Without a roadmap, you haven’t made explicit when major releases will happen, what benefits they should provide, and how you are going to determine their success. This will make it difficult to align the stakeholders including marketing, sales, and support, to staff the development team, and to show that you have done a great job and deserve a pay rise or a bonus.
Without personas I find it difficult to discover the right user interaction, the right user interface design, and the right functionality. Who do the user stories serve and why do they add value for the users? And without a primary persona, I find it hard to prioritise and decide, for instance, if a story or scenario should make it into the release or not and if it can be postponed or only partially provided. This makes managing the product backlog very challenging.
Do Just Enough Upfront Work
While you don’t want to rush into the first sprint, you don’t want to spend more time and effort then absolutely necessary to answer the questions in my checklist above. A great way to carry out the upfront work is to employ a Lean Startup-based approach, as the picture below illustrates.
The diagram above shows two key steps, problem validation and product development. The first step iteratively creates a shared vision, a valid product strategy and business model, a realistic product roadmap, and helpful personas. This is likely to require some research and validation work, for instance, direct observation, problem interviews, and developing minimum viable products (MVPs). The second step leverages Scrum and builds the actual product, a product with the right features and the right technologies. It starts with creating an initial product backlog and finishes with the launch of the new release. I describe the two steps in more detail in my post “New Product Development with Lean Startup and Scrum”.
How much upfront work is needed depends on how many risks your strategy and your business model contain. The more risks there are, the more time and effort you typically have to invest. The risks in turn are related to your growth strategy and to the technologies used to build the product. Developing a new product for a new market carries significantly more risk than updating an existing product for an existing market and therefore tends to require more upfront work, for instance. The amount of tike you may have to spend therefore varies. It can range from a few days for a straight-forward product update to a few months for a diversification effort.
As the product owner, you should lead the problem validation effort and you should shape the vision, the strategy, the business model, the roadmap, and the personas. If that’s not the case then make sure that the necessary prep work has been carried out, that you know the answers to the questions stated in the checklist above, and that the appropriate artefacts are available. If that’s not the case you should consider delaying the start of the first sprint and carrying out more research and validation work.
| Reference: | The Product Owner’s Checklist for the First Sprint from our JCG partner Roman Pichler at the Pichler’s blog blog. |
