Is product X worth building? Lock everyone in the same room for two days and let’s find out!
Introduction
Working for a software development consulting firm, we often get the question “How much would it cost to build product X?” The customer wants to understand if this is a product idea worth investing in.
If a customer believes the cost of building the product can only be understood by a several week or month long prestudy with stakeholder interviews, requirements catalogues and architectural diagrams it can leave them hesitant to explore product ideas. If you don’t explore product ideas that can optimise your business or be sold to customers, you are hampering your innovation rate.
We know that estimating implementation cost is an impossible question to answer accurately if the product idea has any degree of complexity. There has been plenty of empirical evidence of that on the market! But, usually, the customer would benefit from understanding what order of magnitude of cost we’re talking. Is it 500K, 1 million, 10 million or 100 million?
Something I have had positive results with is a different type of highly collaborative, cross functional and workshop-driven prestudy that is executed over two days. This reduces the money and the calendar time needed to understand the product idea and an estimated cost. Hopefully this means you can evaluate more ideas to find the best ones to invest in, and thus increase your innovation rate.
Will you get as detailed a result from a two-day workshop as you would from a two-month prestudy? To paraphrase Ash Maurya, the creator of the Lean Canvas, you don’t understand the right product to build through rhetorical reasoning but rather through empirical testing using product experiments. I believe that at an early ideation stage it is better to work with “just enough” rather than “just because”.
So, what is this highly collaborative, cross-functional and workshop-driven prestudy?
A collection of commonly used agile tools packaged in a two-day workshop sequence. The first day focuses on defining the product and the second day focuses on understanding technical implications and estimation. The key is to keep the workshop HIGHLY cross-functional and collaborative, especially day 1. The more cross-functional the better.
I got the inspiration for using these tools in the Certified Scrum Product Owner (CSPO) course that I took at crisp.se with Reza and Hans. I highly recommend the course! I’ve since read the books behind the tools and experimented with the them at several different clients and in using them in this sequence.
During day 1 we use a Product Vision Board to define target group, needs, the product and its business value. We then (if it is a product with a graphical interface) collaboratively design a user experience. Next, we break the product into a 2-dimensional backlog using user story mapping. Finally, we slice a minimum viable product from the story map.
Participants day 1 should include intended product owner, someone with a budget that could be used to finance the product, users if the product has an internal interface, sales or marketing if the product has an external interface, IT, and any other stakeholders that will have meaningful input. We’ve usually been 8-12 people during day 1.
Getting that cross-functional skew of people in the same room, that’s where the magic happens!
Surprisingly, I often get the feeling that these people don’t communicate a lot in this type of cross-functional forum. If you’ve managed to get them in the same room at the same time, half the battle is already won! Getting that cross-functional perspective enables you to identify trade-offs, gaps in understanding and risks early. You get everyone on the same page and can gain consensus for tough decisions, or at least an understanding for the complexities that could take months if done through interviews. And last but not least, you generate a lot of energy for this new product idea!
Day 2 focuses on getting the dev team up to speed with the product idea, the experience, the story map and the release slicing. This process can obviously be minimised by having the dev team participate day 1. Once the team has a good understanding of what needs are being solved for whom and what the business value is, we review the story map. This takes a bit of time, because we discuss technical feasibility, dependencies and infrastructure needed. If it is a completely new product, we may need to make some basic design decisions in order for the estimation to be meaningful. Finally, we estimate the size of each story. Voilá! We now have a product idea that is boxed in, has a basic UX-design and an estimated MVP.
Participants of day 2 are hopefully the developers that will be implementing the product should it get it’s business case approved. They have the best perspective on how much effort is needed. If I’m running these workshops with a client where their dev team(s) are going to implement the product, it is the internal dev team that should participate day 2. If it is a product that the client would like R2M to implement, we engage 2-3 developers from R2M. The intended product owner should also be present day 2. Finally, at least one developer from day 2 should have been present day 1, to minimise knowledge loss over the workshop days.
Do you immediately start coding after the Prestudy?
You can do. But in many cases, it may be relevant to start with a “design sprint”. Validate your understanding of the target group’s needs by creating some UX, showing it to your users/customers and getting some feedback. Perhaps also experiment by validating some of the largest technical risks. The design sprint should not take months. It’s a sprint, we’re talking 1-3 weeks tops. By focusing on validating your understanding of the target group’s needs and the technology in your first iteration you can use what you have learned here to adjust your vision, story map, MVP scope or estimates; as you should after every iteration.
What has been the result when you’ve run this two-day workshop set up?
- I’ve run this two-day workshop configuration with five different clients.
- It’s always been fun.
- It’s always generated lots of creative energy.
- It’s always been productive.
- I’ve always received positive feedback.
Day 1 has always been exhausting. I have discussed with clients during retrospectives whether we should split day 1 into two half days. However, you build up a lot of energy and momentum that you want to capitalise on.
We haven’t always built the product. Sometimes we discover that there is no business case. I don’t see that as a failure. I see that as a success. We spent 2 days to find that out rather than a traditional prestudy that could have taken several weeks or months. See how much money have we just saved you?
In summary
During two days of intense workshopping you can go from a product idea to channelling the collective brain power of your stakeholders to decide what problem we are trying to solve, for whom, business value, simple UX design, backlog, technical implications and an estimated MVP. This canbe used as a foundation for deciding whether the product idea is worth your time and investment. The secret to this process is getting that cross-functional team in the same room. That’s where the magic happens. The rest is just facilitation with simple agile thinking tools.
Next post I will start going through my application of the agile tools in detail.
