30 questions to help you nail your Products
Build the Right Thing, Build the Thing Right, Build it Fast (1/2)
Some time ago I was asked to prepare a training session on how to write user stories for upcoming Product Owners and for stakeholders dealing with POs at Booking.com.
While there are many online resources available about writing the story itself, it’s harder to find useful and practical advice on the thinking process behind the story; on nailing the objective and on how it fits within the wider context of a product. Not to mention within the context of a team (I explored team dynamics here and here) and all the stakeholders surrounding it. I focused on practical experience, so I took a step back and thought about all the times I wasn’t particularly satisfied with my own user stories (which happens quite a lot!) or those from my peers.
Now, being satisfied with a user story sounds very subjective, however there are ways to collectively objectivize it. I started looking at the questions that unclear stories generated, and quickly noticed the obvious pattern of having the same stakeholders asking the same questions again and again.
Next, with a little inspiration from Henrik Kniberg’s awesome presentation ‘Agile Product Ownership in a Nutshell’, I started classifying the questions in 3 areas of influence, which here I will call the 3 Forces of Product (Build the right thing, Build the thing right, Build it fast).
I started going through the list in multiple scenarios, for example: when writing user-stories, when reviewing the backlog before sprint planning or when I was revising my product roadmap. After some time most of the questions would simply pop-up in my head, becoming an intrinsic part of my day-to-day interaction with stakeholders and of any product discussions. Anticipating certain questions prevented redundant discussions, unnecessary meetings and endless email threads.
This set of questions can help you to ensure you focus on the right piece of work at a time, and to ensure you do it efficiently. As Peter F. Drucker puts it:
“Efficiency is doing the thing right. Effectiveness is doing the right thing.”
Note: you will notice that I mention ‘Product’ several times throughout the questions. I will use the term ‘Product’ for the sake of simplicity and consistency, however it could be replaced by ‘feature’ or ‘piece of work’. While these questions were initially compiled to help at the granular level that is a user story, most of them can also be applied at the wider area of a Product.
Build the Right thing, or Value for customer:
This is most important. First you have to figure out what is the person’s job to be done, what is the customer pain that you can heal by means of your product. Once you nail that, you can focus on how to do it better and faster.
1. What is the customer problem you are trying to solve?
2. Who is the customer? Can other customers or segments benefit from the product? Will other customers or segments want the product?
3. How big and valuable is the customer segment you will be targeting?
4. How important is the problem for the customer? How will his life change with your product?
5. How can you validate the need for the product before shipping it?
6. What is the worst that can happen if you don’t do it at all?
7. Is there any substitute product?
8. Is there any alternative product?
9. Is there any similar existing solution that you can adapt instead of building something from scratch?
10. What things are you leaving aside in order to work on this particular product?
11. Is there organizational buy-in or support for this product?
12. How aligned is the product with the company strategy and current priorities?
Build the thing Right, or Quality:
This, together with velocity, will determine how efficient you are. Because your products are something you want to be proud of even though you have to deliver quick. This is the craftsmanship component.
13. What is the minimum meaningful step into which you can divide the product creation process?
14. Who needs to build the product?
15. Has this been tried before? What happened with it?
16. Once shipped, how long can the product stay “as is”? How long this product could last?
17. How many users can we support with this product? How much can it scale?
18. How long will the customers need or want this product?
19. What is the next step after this product is shipped?
20. Will users understand the product without explanation?
21. Is the code self-explanatory to engineers?
Build it Fast, or Velocity:
This is how fast you can deliver. We do not have indefinite time to get things done, and despite most product people tend to avoid strict timelines, it is very likely that you will have stakeholder pressure to give estimates and to commit to them.
22. What happens if you do it next week / month / year?
23. When does the customer expect it?
24. When do internal stakeholders expect it?
25. Are there any dependencies on other Products?
26. When is the earliest you can deliver the product if everything goes right?
27. When is the earliest you can deliver the product if everything goes wrong? (worst case scenario)
28. Can you discard anything to make it faster?
29. Is there anything that could be done in parallel?
30. What piece of work requires most time? Is that piece necessary? Can somebody else do it?
Summing up, this set of questions can help you to challenge your user stories before getting your team or stakeholders involved with them. Knowing the answers to those questions will help you making bulletproof products and roadmaps, saving you precious time. It is also key to know who your stakeholders are, what are their needs and interests. Knowing that, you can properly balance your efforts in one direction or another, ensuring that you find the sweet spot where the 3 forces converge.
I hope this article will be useful and encourage readers to push towards the optimal balance between meeting customer needs, quality and velocity. In the following part I will elaborate further on how different stakeholders exercise their influence to, often unconsciously, push towards one side or the other, and how you can leverage that when needed.
Thanks for your time, and as always, feel free to share thoughts, ideas or suggestions if you have encountered any similar situations.