The Guide for Perfect Customer Development: How to Create Knowledge as Efficiently as Possible With Available Resources

I communicate with other Product owners in the team mainly in writing

Written communication:

1. Working Backwards: Designing a product hypothesis against a formal checklist, starting with the ideal solution to the client’s needs, taking into account the needs of the stakeholders and testing the risky assumptions.
2. Presentation of the hypothesis and collecting feedback not through voice narration, but through sending a textual description of the hypothesis in slack / mail or simultaneously reading printed descriptions during a group meeting.

Written communication is cool, oral communication is bad

Cons of oral communication:

• Oral communication puts people who know how to persuade in an advantageous position
  • One of the coveted skills of product owners is the ability to “sell your ideas.” When your ideas are not accepted, or when there is a colleague nearby who is good at selling their ideas, there is a natural desire “Cool! I want to be able to do the same! “
  • The desirability of this skill is rather a crutch, which is needed for the system “everyone pitches in a voice, I don’t know how beautifully, I want to learn”.
• Behind a beautiful / emotional pitch, it is easier to consciously / unconsciously hide holes in logic
  • Oral communication discounts the participation of people who need to think in order to form their point of view on the incoming information
    • There are people [me, Alex Borisov, one of them] who, during the discussion, find it difficult to digest all the information and need time to think over the problem from different angles, google something, talk with colleagues and then give feedback. connection. Written communication

The pros of written communication

• Not one project from the knowledgeable cases is complete without detailed technical documentation, this is important for the development team. This is the only way she can effectively deliver results and understand the product.
• It is difficult to write large documents => hypothesis: something will be written in which there is more logic and which has a high probability of passing the challenge of colleagues => bring money.
  • this hypothesis is supported by the product’s story about internal processes at Amazon. He says that having to write a minimal document changes the mindset from “Let’s get the feature out now” to a more deliberate choice of what will pass the peer and stakeholder filter.
• Written communication forces you to think about the logic better, since obvious mistakes will be easily noticed
• When reading, information is assimilated faster and better remembered

Amazon has a culture of writing product requirements through the Working Backwards process. Presentations are prohibited, meetings begin with everyone sitting and silently reading documents that their colleagues have brought. So we are doing the same thing in ROCKETECH!)

I will definitely challenge each hypothesis with a different Product owner.

Research [1]: if a person makes the same decision for himself and for another person. For himself, the decision is made taking into account fewer factors and minimizing the risk, for another person it takes into account more factors and maximizes the likelihood of success.

This is the reason why we love to give advice, but for ourselves, we cannot come up with the same great advice and it is harder to follow it.

Another study [2]: a person is inclined to irrationally overestimate the result of his work. People who offer their ideas, when choosing among all the ideas on which to spend money, I choose to spend more on their ideas.

Total: if you add the mandatory process of the product hypothesis challenge (it is important to choose a threshold, for example, everything that is more expensive than 16 total hours of all people who will work on this hypothesis), the quality of the decisions will increase for a small fee by the production time for the hypothesis challenge.

Of course, the presence of a partner helps me in ROCKETECH, it evens out and averages all the solutions, which subsequently leads to more correct conclusions and hypotheses. Many of our founders are doing the project in the same way, in tandem together.

The goal is to shoot the hypothesis, and not to smuggle it by hook or by crook into the food

• Since you need to nail down hypotheses, then the process must be built in such a way as to find errors in the logic of the next hypothesis.
• From the book Checklist Manifesto [3]: Introducing checklists in different processes significantly reduces errors. For example, 8 clinics in the United States conducted an experiment and introduced checklists for surgery. As a result, mortality from operations has been halved.
• In my experience, a formal 5-question checklist helps target a myriad of hypotheses even before the design stage.

Make critical changes early on

“Working Backwards, if done right, takes a LOT of work. But at the same time, writing and discussing such a document saves even more work in the future, increases the likelihood that you will do what the clients need ”- Jeff Bezos on Working Backwards [4]

Conclusions

The Amazon Working Backwards process of writing product requirements according to a standard template fits into all of these principles.