Communicating Product Learnings

Sharing what we learn in a startup typically happens naturally because the product team and the company are pretty much the same thing.  However, as companies scale, this becomes substantially more difficult, yet it also becomes increasingly important to do.

A technique I love for helping with this is for the head of product, at a company all-hands or similar meeting every week or two, to take 15-30 minutes to highlight what has been learned in product discovery across the various product teams. 

Note that this is meant to cover the bigger learnings, and not the minor things; what worked, and what didn’t work, and what the teams are planning to try the following week.

This update needs to move fast and be kept at the big learnings level, which is why I prefer the VP product to do this.  This is not where every product manager parades in front of everyone for a detailed update; taking 1-2 hours of time, and at more detail than most people want to see, and it’s not meant to be a repeat of sprint reviews either.

Instead, this is meant to address several purposes, some tactical and some cultural:

• The big learnings are important to share broadly, especially when things don’t go as hoped.  As a side benefit, sometimes there is someone in the audience that has an insight as to what might explain the results.
• This is a useful and easy way even for the various product teams to keep apprised of what other teams are learning, as well as ensuring that useful learnings make it to the leaders.
• This technique encourages the product teams to keep their focus on big learnings, and not minor experimentation that doesn’t have a real customer or business impact one way or the other.
  
• Culturally, it’s critical that the organization understand that discovery and innovation is about continuously running these rapid experiments and learning from the results.
• It is also important culturally that the product organization be transparent and generous in what they learn and how they work.  It helps the broader organization to understand that the product organization is not there “to serve the business,” but rather is there to solve problems for our customers, in ways that work for our business.