profile pic

Precise Asteroid

Welcome to Amir's Blog 👋

Book Insights, Continuous Product Discovery


Book Summary: Product Discovery

This book is now on my top 3 recommendation for PMs side by side with Good Statragy Bad Startagey and the LeSS workshop.

It is so good that I intend to keep it on my desk as a quick reference book.

After a first read here are the main points that cought my attention:

The Trio

The PM does not operate alone. Instead she should form a non hierarchical trio together with the designer and the EM. That trio owns together the entire problem-solution space.

In most orgs today the PM is taking a leading role, espcially on the product side, but I feel that a more balanced appraoch is indeed the right way to go.

I was for a while advocating for the PM not to take part in the solution process (aka solutionizing). It felt artifical but I still kept that common wisdon position that the PM should focus on the problem while the team should focus on the solution.

Tbh, focusing on the just the problem (some even call it fall in love with the problem) was not fun. After all we are all problem-solvers and that's what we love doing. If the trio is more balanced I do see a way in which the PM could take part in the solutionizing step, as he will not be able to push his ideas just b/c they are his. It will for sure lead to a higher sense of ownership from the trio memebers and the team.

Product Discovery Cadance

Product discovery should happen on a weekly basis by the team working on the product, conducting small research activities in pursuit of desired outcome

Instead of squeezing all work in the 2 weeks before the quarterly or yearly planning, such cadance will make sure the team is always ready to present its plans. Even more important, that process should include weekly talks with users. My guess is that 99% of all teams are not close to that.

Oppotunity Solution Trees (OST)


I was not surporised with the OST approach as I was following that mental model intuitively even if I did know it has a formal name. However there are still some aspects I did not adhere to and are important:

  • One should maintain more than one solution at a time in order to avoid selection biass
  • One should run experiements very very fast (20! a week). Now this is important. An experiment does not mean an A/B test (which we all know could drap for a few weeks). There are other ways to validate assumptions (surverys, cheap mockups, etc)

Don't brainstorm in groups

For years I was trying to make groups work together in a room. It never really worked. Some people are shy, some are mentally busy. More often that not, I got frustrated and dissappointed. The books suggest that every team memeber should make the thinking alone and come to a sync meetings to share his thoughts and hear other views. Definitely something I need to try more.

Show, don't tell

Many orgs are not ready for such change. instead of trying to change the org, just change the way you work with your trio. Make small iterations. The compound effect with time will make an impact.

Made by Amir 💚