Product Hits: May 11, 2026

Every week, I share three great product resources from a variety of perspectives. Let's dive in!

​Why Intelligent Conflict is the Skill Leaders Need by Kate Leto

Kate Leto, Head of Product at Moo, argues that the biggest source of dysfunction on teams usually isn’t open fighting, but fake alignment. She explores how avoided conversations, vague feedback, and “nice” team cultures quietly slow decisions and erode trust. Leto shows why strong product leaders learn to surface tension early, before it compounds into organizational drag.

​When PMs Build Tools for Designers by Elaine Chao

Elaine Chao, Director of Product at Adobe, reflects on the challenge of building a product for one of the most demanding user groups in tech: designers themselves. She shares how deep designer-engineer collaboration, constant iteration, and obsessive attention to workflow details shaped Adobe XD from the ground up. Building tools for experts, she argues, requires a very different product mindset because expert users notice every friction point immediately.

​Writing Is Thinking by Noa Ganot

Noa Ganot, Founder of Infinify, argues that writing is not what happens after thinking, but the mechanism that sharpens thinking in the first place. She explains how writing exposes weak logic, surfaces unanswered questions, and preserves the reasoning behind difficult decisions. For PMs, writing becomes a way to think through ambiguity before teams mistake unfinished thinking for strategy.

Behind the Scenes

Hey there, it’s Clement!

I was reviewing some past projects recently, and it reminded me of a subtle trap that’s easy to fall into.

When you look at a polished product, the features often feel obvious in hindsight. Everything fits together cleanly. It feels like, “of course this is how it should work.”

But getting there usually requires separating two things that get mixed together all the time: ideas and assumptions.

An idea is the thing you want to build.

An assumption is the belief that this idea actually solves something meaningful for the customer.

In practice, those two blur quickly.

You have a promising idea, it feels right, and before you know it, you’re building forward as if the value is already proven.

I’ve seen this play out where teams end up optimizing a solution that customers never really asked for, not because the team was careless, but because no one paused to question what had to be true for the idea to work.

One habit that’s helped me is writing down a few “must-be-true” statements before committing to a direction.

Mind you, we’re not aiming for a huge list! Just a few key things like:

• What has to be true about the customer’s workflow for this to fit?
• What has to be true about how painful the current problem is?
• What has to be true about their willingness to change behavior?

Seeing those assumptions written out makes it much easier to spot where you’re guessing.

And once you see the guesses, it becomes clearer what you actually need to validate.

Sometimes that’s data. Often, it’s just talking to a few customers and hearing how they describe the problem in their own words.

The goal isn’t to eliminate risk entirely. It’s to make sure you’re not quietly building on top of unexamined beliefs.

If you’re working on something new right now, it might be worth pausing for a few minutes and asking: what has to be true for this to succeed?

You might find that the answer changes what you build next.

With love,
Clement

Let's do more together!

• ​Searching for your next chapter? I crafted a guide for navigating the modern PM jobs market.
  ​
• ​Want to learn product at your own pace? My courses have helped 3,000+ others boost their PM careers.
  ​
• ​Just secured a new PM role​? I've pulled together onboarding materials to help you spin up a 30-60-90 day plan and impress your manager.
  ​