Iterate on WHO, not what
You build for one audience. Nobody cares. So you add features. Still nobody cares. Most founders get this backwards: they keep rebuilding the product when the thing that needs to change is who they built it for.
Here's the loop I watch founders run.
You build for an audience. Nobody bites. So you assume the product is missing something, and you add features. Still nobody bites. You add more. Six months later the product is heavier, the team is tired, and the number that matters hasn't moved.
The whole time, one possibility never got tested: the product might be fine. The audience might be wrong.
Changing the product is the expensive experiment
There's a reason teams default to building. Building feels like progress you can point at. Changing who you sell to feels like admitting the last year was aimed at the wrong people, and nobody enjoys that meeting.
But look at the cost of each experiment. Adding a feature is weeks of engineering, and it tests one narrow guess about what a user wants. Pointing the same product at a different segment costs you a week of conversations, and it tests something far bigger: whether anyone is actually desperate for what you already built.
Andy Rachleff put it about as plainly as it can be put: change your audience, not your product, until you find who is desperate for what you do.
What this looked like with FOUND
FOUND is a Swiss recruitment startup we took from a blank page to Product-Market Fit. The thing that got them there wasn't a feature. It was ruthless narrowing: picking a tiny beachhead segment and proving demand inside it before building more.
That's the same move in a different coat. Instead of asking "what else should this do," you ask "who has this problem so badly they'd take it in its current state." Then you go find more of those people.
How to tell which problem you actually have
Product problem or audience problem. They look identical from the inside, so here's how I separate them.
Talk to the people who did stick around. If you have any retention at all, the users who stayed are your signal. What do they have in common that your churned users don't? Job title, company size, trigger event, budget owner. If a pattern falls out, you have an audience problem and the pattern is your answer.
Ask what they'd use instead. If a churned user shrugs and says "nothing, we just went back to a spreadsheet," they were never desperate. That's audience. If they name a real competitor they switched to, that's product.
Count the desperate ones. Not the polite ones. In five customer conversations you can usually tell who is genuinely in pain and who is being nice to you. If nobody in your target segment is in real pain, more features won't manufacture it.
The uncomfortable version
Sometimes the answer is that your product is good and you have been showing it to the wrong room for a year. That is a much better problem than it feels like, because it is fixable in weeks rather than quarters.
What it requires is treating your audience as a variable you're allowed to change, which is exactly the discipline behind writing PMF as a hypothesis you can test. Segment is part of the hypothesis. If you never wrote it down, you can't notice when it's the thing that's wrong.
So before the next feature sprint, run the cheaper experiment. Take what you have, point it at a different group, and see if anyone grabs it out of your hands. That's the signal you're looking for, and it's a week of work rather than a quarter.
Finding that group, and proving they're real before you build for them, is the whole job of the PMF Program.