When the Problem Is Sales, More Product Will Not Fix It
Companies route every problem to product and engineering because those teams always say yes. That is not evidence the problem lives there.

A company came to me certain they needed product strategy. Growth had flattened, the roadmap felt directionless, and the obvious read was that they were building the wrong things. That's a real problem and I'm the person you call for it.
It wasn't the problem. Their product was fine. What was broken was how they talked about it – the story their sales team told didn't match what the thing actually did for people, so good-fit buyers bounced and poor-fit buyers churned. No feature I could have put on that roadmap would have moved the number.
That's the most common expensive mistake I see, and it has a shape: solutions in search of problems.
Product and engineering are where problems go to be agreed with
Here's the mechanism, and it's not a failure of intelligence.
When something is wrong, leadership looks to product and engineering, because product and engineering always want to build something new. "Sure thing, boss, we'll build it." It's the easy sell, it feels like momentum, and for the teams involved it even feels like job security. Nobody in that conversation has to say anything uncomfortable.
Meanwhile the actual problem is frequently somewhere else. No real alignment of vision, mission, and strategy. A failure to think about the whole organization at once. A sales motion that doesn't fit the buyer. A pricing model that punishes the customers you most want. Those live in rooms where the answer to "can you fix this" is not an enthusiastic yes.
So the request routes to the function that will take it. That's the path of least resistance, and it is not evidence about where the problem is.
AI lowered the resistance further
This was true before AI and it's worse now, because the friction that used to slow the reflex has mostly gone.
You can build more, faster, at higher quality than you could three years ago. Which makes "we'll just build our way out of this" an even easier sentence to say, and the gap between saying it and having something shipped has collapsed from quarters to weeks. If the problem is your storytelling in sales and marketing, more product will not fix it – it'll just get you to the same place sooner, with more surface area to maintain.
The delivery-failure literature makes a version of this point: AI changed how fast teams reach the failure, not its shape. A gap in the requirements now becomes shipped, confident, wrong software faster than anyone can review it. Speed is neutral. It amplifies whatever judgment preceded it.
The oldest data on this says the same thing
The landmark study here is old enough to have a beard, and it holds up.
The 2011 Startup Genome analysis looked at more than 3,200 high-growth technology startups and found the primary cause of failure was premature scaling – advancing one dimension of the business past the stage the company had actually validated. It was present in 70% of the dataset.
The detail I find most useful is about where attention goes during discovery. In that phase, 80% of consistently-staged startups focused on discovering a problem space, while 60% of the inconsistent ones focused on validating a product they had already decided to build. Same phase, same calendar, completely different question – and the second group had skipped straight to confirming a solution.
The consequences were not subtle: according to the same analysis, 93% of prematurely-scaled startups never broke $100k in monthly revenue, and properly-staged ones grew roughly twenty times faster.
That research is from 2011 and describes startups, so don't over-extend it. But the behaviour it names is the same one I walk into at established companies, where it presents as a roadmap that's busy and a business that isn't moving.
How to tell a product problem from a story problem
A few questions that separate them faster than a quarter of building will.
Where do deals actually die? If prospects understand what you do and pick someone else, that's a product or positioning problem. If they don't understand what you do, or they buy and then discover it wasn't what they expected, that's a story problem and building more won't touch it.
Who churns? Churn concentrated in a segment that was never a good fit is an acquisition and messaging problem. You sold to the wrong people. A better product for the wrong people is still the wrong people.
Can your own team explain the value in one sentence, without a demo? Ask three people separately. If you get three answers, your buyers are getting worse than three, and no feature closes that.
What changed before the number moved? If growth flattened and nothing shipped differently, the cause is probably not in the product.
None of these are hard to run. What's hard is that the honest answer frequently points at a function whose leader is in the room, which is why the question tends not to get asked.
Why this is so hard to see from inside
The reason smart teams keep making this mistake is that the wrong diagnosis produces a completely believable work plan.
If you decide the problem is product, there is always a roadmap to write. There are always features customers have asked for, always a competitor with something you lack, always a backlog with candidates in it. The plan looks rigorous, it fills a quarter, and every person executing it is doing real work well. Nothing about the experience of running it feels like a mistake, which is why it can run for two or three quarters before anyone asks whether the premise held.
Compare that to the alternative. Deciding the problem is in sales storytelling means someone has to tell a sales leader their positioning isn't landing, then rebuild the messaging, then retrain a team, then wait for a sales cycle to find out whether it worked. That plan is shorter, cheaper, more likely to be right, and dramatically less pleasant to start. Organizations route around it the same way water routes around a rock.
The discipline this actually demands
Be discerning about what you need, and then be willing to have the hard conversations – to point at the parts of the organization that are failing, rather than taking the comfortable route to product and engineering.
That's an uncomfortable sentence for me to write as someone who sells product strategy work, because it means a meaningful share of the people who want to hire me shouldn't. I'd rather say it. The engagement where I build a roadmap for a company whose problem is in sales is one where everyone is busy, the deliverable is good, and the number doesn't move – and I'd rather lose that engagement than run it.
Eric Brown's framing of the buyer-side test applies here as well as anywhere: ask where they'd tell you not to use it. Anyone selling capacity will keep selling. If the person you're about to hire has no conditions under which they'd tell you the problem isn't theirs to solve, you've learned something useful about what you're buying.
The company I opened with didn't need a roadmap. They needed to be able to say what they did, to the right people, in a way that was true. That took a fraction of the time and none of the engineering, and it worked.
More from Consulting Operations

35% Understand the Problem but Not What Done Looks Like. I'd Have Bet the Opposite.
My day-one test on a struggling team is whether anyone can say why. New survey data says the bigger gap sits at the other end of the ticket.

Say Yes to the Two-Week Idea. It's How You Buy the Right to Say No.
Fighting every executive request loses, because leadership escalation is the dominant force on real roadmaps. Here is what to spend instead.

What a Product Strategy Consultant Costs (and Why the Day Rate Is the Wrong Number)
Published market rates for product strategy help, what each option actually buys, and the question that separates judgment from capacity.
Want help running a sharper practice?
The reading and synthesis behind your client work, handled – a living deliverable kept current, so more of your time goes where your name is actually on the line.
See how this works for advisors