Building Rafts and Product Research
When I was in high school, we had a physics teacher who loved to share with us his life insights. He was a Russian immigrant with a heavy Russian accent, and he was eager to teach us some lessons for life, not just physics. One of his favorites insights was — “If you are stranded like Robinson Crusoe on a deserted island, and you have one year to build a raft to rescue yourself, spend eleven months on planning the raft, and then one month on building it”. I liked this sentence back then, and I still do after many years in planning and building products. So, if you are currently trapped on an island, whether it is a real one or imagined, this post is for you :)
The first thing about escaping an island with a raft is that you probably have only one shot. The success of this project is a matter of life or death, so you’d better do a good job. The second thing is that there are lots of things you can do before building the actual raft, to reduce the involved risk and improve the chances of doing it right. Here are a few examples of what I would do on the island. I am sure you can come up with a few other ideas:
- Float a wood in the water to see where the ocean currents take it. Is it east or west?
- Record the wind patterns throughout the day. Does it change directions? When is it the strongest? The calmest?
- Take the rope you intend to use to tie the raft parts, and soak it in water for a week, see what happens to it.
- Build a small-scale raft, put it into the water and see that it does not flip on its head.
I would like to call this set of activities — Product Research. The result of this research is a good understanding of what is the product that we need to build, its features, and its launch strategy. As you can see, part of the research is purely theoretical and does not require any resources, and part of it is experimental. Some of the experiments are simple (like throwing a piece of wood into the water), and some are more complex (like building a small-scale raft). They all serve the same purpose, which is gaining more knowledge about the product.
Another great example is the wedding cake task (the credit for which goes to Des Traynor, I highly recommend his talks and writings about product strategy). Imagine your job is to prepare a big wedding cake, and let’s say this is your first wedding cake ever. How would you approach the task?
With the classic approach, you would follow the recipe steps: first prepare the cake base, then make the upper layer, then the filling, then the icing, and finally, assemble everything. Simple, isn’t it? Conceptually it is, but very risky. So many things can go wrong. It is not a matter of life or death like the raft challenge, but you really wouldn’t want to screw up…
The alternative approach will be this: make a cupcake. With the cupcake, you can ensure the oven works fine, you can learn the flavours, and you can also examine the look of the icing. If all is good, you continue to make a cake. And only when the cake is right, you proceed to the big wedding cake.
Let’s go back to our day-to-day products. All too often, product managers leave the research work to other teams. Market research is done by marketing, technical research is done by engineers, and the product guys are expected to be only the middlemen — the guys who write specs. But the spec is merely the result, and it should contain as much knowledge as you can. So, how can you gain knowledge for your future product? Here are some tips:
- Approach whoever you think relevant and ask challenging questions (usually, these questions start with “Why” or “Why not”).
- Break the process into small pieces and examine the risk involved in each element. The risk of failure can come from a lot of factors — wrong market, wrong pricing, lousy design, lagging performance, and more.
- The best knowledge you can get is feedback from real users. In the wedding cake example, let users taste the cupcake, and ask them for their opinion. The value of such feedback is enormous, as it gives you precious information way before the launch, allowing you enough time to adjust and improve the product.
Of course, not all people in your organization will support you on this journey, some of them will press you about the spec, and claim you are wasting time — “Please concentrate on completing the spec, what are you waiting for? We know what we want. Just do it.” Maybe it works for Nike, but not in our case. If you get these kinds of feedback, here is another tip: Communicate the risks to your teammates and bosses. Make sure they are aware of them and let them contribute to the effort of reducing the risks.
Remember, the goal of what you do here is to improve the chances of a successful product launch. Since successful launches don’t come easy, this research you are doing is a big deal.
