There is more than one way to meet your customers' needs. However, in this article, I want to focus entirely on the creative process because most of the attention is on engineering the product.
Roadmaps typically consist of features and dates. As a result, there is 'no place' for customer needs and the impact of our features. However, by grouping features by goal rather than by date, we avoid the largest pitfall of classic road mapping. We call that method rolling wave planning.
With waterfall - traditional project management methodology - you set everything up first but then get stuck. With Agile, you use rolling wave planning, which is planning in waves as the project proceeds and adjusting later when the details become more apparent. The project schedule focuses on iterative work and frequent updates to the project plan. It's a planning technique for projects that don't offer all the data needed to create a plan upfront.
We distinguish short, medium and long-term goals, which gives you a picture of granularity.
- Short-term: Sprint Goals
A relatively short period in which we lock the scope of the work. After each sprint, we are free to pursue and adapt to new insights. The biggest advantage of working with small batches is the ability to quickly identify problems.
- Medium-length Term: Release Goals
Specify your goals in detail for one or two iterations. Define the features or needs you are going to solve on a release level. I recommend not releasing it in big batches. Anyway, you will still need to set signposts strategically and track that your product is progressing in the right direction.
- Long Term: Strategic Goals (all products from 6 to 12 months)
There are groups of features that address a common area of customer needs. You don't know the solution yet; you only plan to address the area at the moment.
If you reach a state of continuous innovation, the release becomes less important than its impact. Users don't see the new version number; they only see the new engaging, funny or disastrous functionalities. Rolling wave planning helps you organize the product's engineering depending on your priorities which evolve and change – especially if you make systematic measurements of your current situation and product.
Market evidence and problem impact
Prioritizing lets you put things in a particular order. Doing one thing first means other things occur later. Of course, two items on your backlog cannot have the same priority – but how to figure out which one should be the first? So, what's a clever way to determine that order? The best approach is to prioritize the contents of each release by ordering the roadmap goals based on two things:
- market evidence;
- problem impact.
Market evidence is a vast topic deserving of a separate or perhaps even several separate posts, so I am just pencilling the issue here. Base your analysis on questions like:
- How many times have we seen it?
- What percentage of users experiences it?
- How bad is it for the market?
- How bad is it if we do not address it?
Turn the answers into a solid score by using numbers - factual evidence is much better than simply following a hunch or personal opinions.
Now, the problem impact. When you have well-defined the problem your customers are facing, you can propose solutions to these problems. The value map provides a way to define your product's features and makes user needs visible and transparent. Value Model Canvas answers the question:
What does the customer feel?
The customer has rational needs that may be unconscious. What we see and hear, say and do, and how we interact with others influence what we think and feel (carrying songs in your pocket became a need when people saw iPod). There are also emotional needs. Rationally, you want to get from point A to B, but emotionally, you would need a Tesla to do it. For most products, there's a secret fear of switching - addressing those anxieties can improve your product.
What does your product do?
Start with the benefits. Why do you think this product benefits people? Always start with "why" and then describe the feature that realizes this goal. The second possibility is to look at this through the lens of pains and gains: What positive gain does the feature bring the customer? What pain does it resolve? How does your product make your customer feel the need to purchase it? What does it feel like to use your products? What behaviour are you replacing?
To sum up, features are all done when they have an impact on the user – when they are shaping the customer's experience, not when they are built. Rolling wave planning and prioritizing doesn't tell you when you have met your true goal - solving the problem - but will definitely make it easier to achieve it. That is why during product creation, a doubtful Product Owner should be asking themselves: Why am I making the product I'm making? Am I sure it fixes the right problem?
If you are interested in this topic, I encourage you to read the book by Chris Lukassen: "The Product Samurai".
