Fostering better collaboration within product teams: An interview with John Cutler

John Cutler didn’t start off his career as the product management thinker that he is today. In fact, his transition into the field has been anything but linear. 

“I spent my 20s playing music in bands and touring around the country.” When not on the road, John was busy adding a laundry list of odd jobs to his resume. At one point, he even created a bartending video game. 

Through a referral from a friend, John began working in the tech industry, ultimately landing in the world of B2B product management. Today, he is Product Evangelist at Amplitude and a prominent product personality in his own right. He is known for his prolific blog posts and Tweets about the inner workings of product teams, product management frameworks and processes, as well as other trends in the PM world.

We sat down to chat more with John about his role at Amplitude, the evolving product management discipline, and the ideas that he is currently obsessing over (which mainly revolve around fostering better collaboration within product teams). 

Read on for a lightly edited version of our conversation. 

So, what exactly is a product evangelist? 

At Amplitude, we know that a lot of puzzle pieces need to fall in place in order for teams to take advantage of our amazing tools. This requires a mix of evangelism and advocacy on our part. So, some folks are focused on spreading the word about our product and its capabilities. Some folks are focused on broader trends in product development and how teams collaborate. I fall somewhere in the middle.

Can you tell me a little bit about product intelligence — the category your team is creating at Amplitude? How does product intelligence help improve your product? 

To improve your product, you must answer many different questions: “How does this behavior relate to this other behavior? What are the cohorts that naturally exist based on the behavior we see in our product? If we run an experiment, what effects will it have across the product?” 

It depends on the nature of the questions you’re asking and the type of actions you might take based on the answers. Product intelligence is what allows product teams to answer these questions, and Amplitude provides the tools that enable product intelligence. 

Product intelligence is about understanding the complex behavioral journeys that people have within your product as well as the questions you have to answer about these journeys to improve your product. 

How can teams balance the use of quantitative and qualitative data when it comes to product decision-making?

The amount of insight you can derive from quantitative data is finite, and qualitative data in itself can be too broad. What I’ve noticed in teams that are using quantitative data really effectively is that they are a lot more laser-focused in how they conduct qualitative research. 

With quantitative data, you can find a representative sample of people who have performed a behavior that you are interested in and zero in on them with qualitative methods. If you go in blind and try to extract qualitative data from a random pool, you’re not going to gather the relevant information that improves product decision-making. 

What I’ve noticed in teams that are using the quantitative data really effectively is that they are a lot more laser-focused in how they conduct qualitative research. 

A lot of your writing is focused on fostering collaboration within product teams. Why is this topic so interesting to you?

Maybe it’s from my music days. There’s a certain magic that happens when you find yourself in a band that is just working. Amazing results are coming from this type of collaboration. And so I’m really passionate about the question “is it working?”

And having things “just work” is a real challenge for product teams. There are varying boundaries, role definitions, and mindsets around product management and experimentation. All this can block teams from innovating and making an impact. I’m fascinated by how I can help teams build trust and reach a point where they feel psychologically safe enough to openly address these issues and build awesome products.

What are the shared characteristics of happy, high-functioning product teams?

This is a question I struggle with because it’s so hard to generalize the traits that good product teams share. It’s much easier to spot the dysfunctions! But, if I have to give an answer, good product teams seem to not bite each other’s heads off. They respect each other. They understand their field and responsibilities and know how to navigate diverse personalities and team dynamics. They trust each other so there’s an environment of safety and openness. 

How can product teams effectively build trust?

My view is that trust is built by small promises kept frequently. 

There’s a concept called fundamental attribution bias where you start to think that all your problems are systemic — like, oh, everyone is giving me a hard time, that’s why I’m dropping the ball on everything. We all fall victim to this mindset sometimes. However, once this environment exists it can be detrimental to team morale. No one thinks anyone else is accountable anymore.

So, product teams must figure out how to regain control over the flywheel of making and keeping promises. It’s easy to talk philosophically about trust and culture, but it is your day-to-day actions that actually build goodwill.

I talk a lot about product teams who have too much work-in-progress. This can make it seem like no one is trustworthy when in fact everyone simply has their plates full and can’t make promises about deadlines that they can keep. In this scenario, I advise teams to move away from hard deadlines. Rather, they can commit to keeping people in the loop and set realistic expectations about the scope they are capable of delivering. 

My view is that trust is built by small promises kept frequently. It’s easy to talk philosophically about trust and culture, but it’s your day-to-day actions that build goodwill.

I think one of the original ideas with agile methodologies was actually to create a system where trust could be built.  For example, a team could try keeping a common board with experiments they want to run that are safe to fail. This is a specific practice where you make a commitment as a team to reflect, adapt, and learn in a safe space.

One thing you’ve written about is the “messy middle” between company-level objectives and product team priorities. Do you have any recent insights on how to best bridge that divide?

In the book Sapiens, it says that humans create robust stories so they can interact and collaborate with one another. When done right, they can function without a lot of contractual back and forth. But, to get there, they first need shared mental models and shared language. 

Based on this philosophy, my interpretation of product management tools is that they are catalysts for conversations and help product teams develop a shared language. Essentially, these tools help create a coherent story about what teams are doing and why they’re doing it. This bridges the “messy middle” because it enables open communication and helps teams understand both their short and long-term work. This understanding can then be tied to high-level objectives and communicated across the company. 

My interpretation of product management tools is that they are catalysts for conversations and help product teams develop a shared language. Essentially, these tools help create a coherent story about what they’re doing and why they’re doing it. 

What is the best way for PMs to answer the question ‘Why are we building this feature? Where are we going?’

In my mind, if you wait until a feature is on the roadmap to explain why it’s there, you’re doing it wrong. Diverse stakeholders should have been involved with coming up with the idea in the first place; you should be able to explain why the feature is a good idea based on all the other ideas you discussed and rejected; you should also have some indicators from data. 

A good way to get to this point is to establish a framework or mental model that all relevant stakeholders are familiar with. 

Here’s a highly simplified example of what I’m talking about: On the Amplitude content team, we ensure that everyone is always working on the best idea possible by using a series of questions that act as a criteria of what we consider valuable content for our company.If at any point a project that is being worked on doesn’t meet our criteria, it gets scrapped.

Applying a working model or framework like this to product management, when a feature goes into delivery it means that it has already passed the test, which in itself is a great explanation for why it’s valuable. 

What do you think makes products excellent?

I think about products as a team of people committing to meet a set of human needs for an extended (but temporary) period of time. So, excellent products are those that meet human needs in a differentiated way at specific points-in-time. To adapt to changing expectations, a product can change drastically or even become something else entirely. 

Based on this interpretation, Product Excellence requires teams to have a viable strategy and approach to make that excellent product happen. Because if you don’t have a sustainable way of working, you won’t be able to deliver any products, and you will let your customers down.

Excellent products are those that meet human needs in a differentiated way at specific points-in-time. To adapt to changing expectations, a product can change drastically or even become something else entirely.

. . .

Don’t forget to follow John Cutler on Twitter!

productboard is a product management system that enables teams to get the right products to market faster.  Access a 15-day free trial of productboard today.