Why we don't have product managers
A conscious trade-off between structure and customer proximity.
👋 to the 9 new founders who subscribed last week. If you were forwarded this, join 235 other founders getting their free dose of Founder Therapy every week.
I posted on LinkedIn that we don’t have any product managers at Clarify. 150 people had thoughts about it.
Some folks loved it. Some thought it was nonsense. A few PMs read it as me criticizing the role, which isn’t what I meant.
So I want to go deeper on what I was actually trying to say — and address some of the pushback head-on.
We’ve intentionally not hired PMs yet. Not because PMs don’t add value. Because early on, I care most about making sure the people building are hearing directly from customers and making decisions based on firsthand information.
Some might oversimplify that as cutting out the middle person. I think it’s more about optimizing for customer proximity.
Why we’re doing it this way
What I’ve seen at a lot of startups is that customer feedback gets passed through too many people before it reaches the people building the actual product.
A customer says something, someone summarizes it, then it turns into a spec or a ticket.
By the time it gets built, the team has usually made a bunch of reasonable assumptions along the way, and the result might not solve the actual problem.
When you’re early, that’s dangerous. You don’t have time to be “almost right” for six months.
Think about it this way: Ford has thousands of people touching each car from start to finish. That’s assembly line thinking. Hermès has one craftsperson responsible for an entire Birkin bag. That’s craftsmanship thinking.
At Clarify, we care deeply about craftsmanship. We design with care. The fewer people between your customer’s problem and your engineer’s code, the better your product becomes.
So we try to keep the loop tight: the people building should also be the people who understand the problem.
What “no PMs” looks like day to day
This doesn’t mean we’re improvising or ignoring the important work a product manager would traditionally do. The responsibilities just sit in different places.
Designers and engineers pair closely, own a problem area, and do the full loop: talk to customers, decide what to build, ship it, and follow up on whether it worked.
I’m still doing the parts people normally expect a PM to cover at an early-stage startup: setting direction, making tradeoffs, and deciding what’s important right now. We’re just not adding an extra layer between the team and customer feedback.
What this helps with
The main benefit is speed of learning. If a customer is confused or something isn’t working, the people who can fix it are already close to the context.
It also improves accountability. When an engineer owns a customer problem end-to-end, you get fewer “I built to the spec” moments and more “Did we actually solve the customer’s problem?” thinking.
What people got wrong — and what they got right
The sharpest pushback on the LinkedIn post came from product and engineering leaders, who raised two concerns. Both are fair, and I want to address them directly.
“Engineers have biases too — toward overengineering, toward chasing shiny tech.”
They do. But I’ve never met a human who doesn’t have their own bias. Even AI has its own bias. The question isn’t whether bias exists — it’s whether your system accounts for it. We design incentives, comp plans, and feedback loops that look at way more than just the decisions people make. No org is a pure meritocracy. The goal is to keep improving the system, not pretend any single role eliminates bias.
“You’re burning your engineers out by asking them to do two jobs.”
This one I take seriously because it’s a real risk. We’re asking more from designers and engineers than a traditional setup would. It works best when you have people who are comfortable talking to customers, handling ambiguity, and making calls without waiting for someone else to write the perfect PRD.
We’re not building at huge scale (yet). We’re building for quality. And quality requires a direct connection between the person with the problem and the person who can solve it. That changes as you grow. I’m not pretending it won’t change for us.
Tradeoffs we’re accepting
One real downside of the no-PM setup is that it’s easier for decisions to get made in silos.
Two people on the team can make two reasonable calls that don’t line up, and you don’t notice until something breaks or confusion spreads.
When that happens, it’s almost never because someone did a bad job. It’s because we weren’t clear on who owned it, who needed to be looped in, and what needed to be a company-level decision. We’ve had moments where that ambiguity cost us a week or two of rework — not because people were wrong, but because they were solving the same problem from different angles without knowing it.
That’s the tax you pay for speed of learning. We think it’s worth it right now. But I’d be kidding myself if I said it’s always smooth.
The question I’d ask before hiring your first PM
If you’re thinking about hiring a PM right now, I’d ask what you’re really trying to fix.
If nobody is setting direction or making tradeoffs, that’s a leadership gap. A PM is unlikely to fill it.
If the team is building without enough customer context, that’s a customer proximity gap, and the fix is usually more direct customer contact, not another layer in between.
No PMs isn’t the right answer for everyone, and it might not be the right answer for us forever.
We’re consciously choosing faster learning now, even if it means a bit more friction on coordination. What we’re watching for is pretty practical: are we repeating the same alignment issues, are decisions getting slower because nobody feels empowered to make the call, and are we spending more time coordinating than learning?
Who knows, maybe we’ll have a PM this time next year, and I’ll be writing about why I was wrong all along.
Watch this space.
–Patrick