I've heard this too many times now. "We cycled through a few different Heads of Product... they never work out." The pattern looks like this... 1. Founders notice they aren't shipping product. 2. They think a Head of Product will fix it. 3. Head of Product comes in, and spends time/energy at the "strategy" level of framing. 4. The strategy from the Head of Product misses the mark. 5. Founders realize they probably have better ideas about strategy. 6. Founders explain what's important to the Head of Product. 7. Head of Product doesn't have the right skills to translate "this is what we want to solve" to a blueprint of what to specifically build. In the end, it's a mix of wrong output and no output. What went wrong here? The #1 mismatch I see is that founders don't know what to expect from the Head of Product, and vice versa. Founders think they should delegate strategy, which is often not the case. Heads of Product think they should contribute strategy, which is often not the case. What's missing is this ... very often Founders have a good nose for what needs to get solved. What they need is someone who can NARROW DOWN and TRANSLATE that into a specific concept with good UX that's technically legible. But instead what happens is both compete for the "set the strategy" role. And nobody is problems into frames into shapes to go build. My #1 advice to founders thinking they need a head of product. Ask yourself: do you actually NOT know what you want, strategically? Are you really looking to outsource strategy? If it's not actually about bringing in someone from outside to set the direction for your whole product ... then you need someone who is skilled ONE LEVEL DOWN in concreteness. Meaning someone who can listen to you about what matters, whiteboard the solution that pulls it all together, and work with technical people to make it happen. There is a HUGE gap in the market today. We need product people who can work ABOVE the level of Figma-visuals and BELOW the level of "company strategy". So much work of getting to what we actually ship — the blueprint — is in-between. And let me tell you ... if you EVER go to a product conference, prepare to be deeply misled. There are WAY TOO MANY talks about "strategy" when nobody in the room is truly responsible for strategy. Product is ultimately about understanding the purpose and translating that into a specific design. A Head of Product who can't whiteboard a UI flow or make technical trade-offs with engineers isn't heading product. They're trying to play CEO.

Same problems exist in software, except it’s all in everyones’ heads.

We got GitHub for electronics before GTA6

Can taste be learned? If you can *see* taste, you can learn it. Both sides have to be there. Someone who can demonstrate *and* someone who can appreciate. Then learning happens.

If the codebase is the elephant we can't see, asking Claude tells us it's a tree, now a rope, now a snake... We've got to have a macro picture of the thing in order to work on it. Then we have *context* for all the individual things that Claude very helpfully spells out.

What any design ultimately "is" from the POV of the people who build/maintain it is a web of decisions with interdependencies. Any representation we use to remember / collaborate on / evaluate it that doesn't *show* those things assumes they're (a) obvious or (b) in our heads.

This is classic Kent Beck. FWIW I don't say "YAGNI" because it's misleading. In many cases we will "need it" (or something like it) later. The two reasons he spelled out (optionality and NPV) are captured by saying "not yet." "Not yet" is powerful. newsletter.kentbeck.com/p/th…