Why B2B SaaS Teams Keep Building the Wrong Features (And How to Stop)
March 3, 2026
You shipped the feature. You’d been talking about it for months. The design was solid, the engineers were proud of it, and the announcement email got a decent open rate. Then… nothing. Usage data barely moved. The sales team stopped mentioning it. A quarter later, someone in a retro quietly asks whether it was worth it.
This happens constantly in B2B SaaS — not because teams are incompetent, but because the system they’re working in is optimised for building, not for solving. Here’s what’s actually going on, and how to break the pattern.
Most teams treat prioritisation as the hard part. They introduce RICE scoring, run stack-ranking workshops, and debate urgency versus impact in lengthy planning sessions. But prioritisation frameworks only work when the problems feeding into them are real. If the inputs are wrong, a well-run prioritisation process just helps you build the wrong things faster.
The real issue sits upstream — in how teams gather, interpret, and act on information about what users actually need.
Enterprise SaaS teams are particularly vulnerable to this. One churned account, one angry email from a high-value customer, one sales call where a prospect asked for a specific feature — and suddenly it’s on the roadmap. The feedback isn’t wrong exactly, but it’s from a tiny, unrepresentative slice of your user base. The silent majority, the users quietly getting value from your product every day, never make it into the planning meeting.
The result is a roadmap that looks responsive but is actually just reactive. You’re building for the exception, not the rule.
Running a lot of customer calls isn’t the same as doing good discovery. If you go into those calls with a feature already in mind, you’ll find the evidence you’re looking for. Users are polite. They’ll engage with your prototype, tell you it looks great, and still not use it when it ships.
Real discovery means sitting with the problem before you’ve touched the solution. It means asking users to walk you through what they’re doing today, where they get frustrated, what they’ve tried, what they’ve given up on. That’s a different conversation to “here’s what we’re thinking of building — what do you reckon?”
Velocity, story points, features shipped per quarter — these are comforting numbers because they’re easy to track and they go up. But shipping features isn’t the same as creating value. A team can be highly productive and still spend six months building things that don’t materially improve retention, activation, or revenue.
This isn’t a failure of work ethic. It’s a failure of definition. If success is measured by what ships rather than what changes, the incentive structure will keep producing the wrong results regardless of how talented the team is.
In many organisations, discovery is what happens before development starts. The team talks to users, writes up some notes, hands them to a designer, and by the time the feature reaches engineering, the original problem statement has been through three rounds of telephone. The insight that mattered gets diluted or lost entirely.
Continuous discovery — where the team maintains an ongoing relationship with users throughout the build process — is still the exception rather than the norm. As a result, teams build based on a snapshot of user needs that was already outdated before the sprint even started.
Post-launch reviews are the most consistently skipped part of the product process. Teams celebrate shipping, declare victory, and move straight to the next thing. But without asking whether the feature actually solved the problem, you lose the most valuable learning in the whole cycle. You also lose the honest signal that would help you build better the next time.
Jobs-to-Be-Done is one of the most useful frameworks in product development precisely because it shifts the focus away from what users ask for and toward what they’re actually trying to accomplish. People don’t want a calendar integration — they want to stop switching between tabs during a sales call. People don’t want a bulk export feature — they want their manager to stop chasing them for reports.
When you frame user needs as jobs — functional, social, and emotional goals they’re trying to achieve — you open up a much wider solution space. The feature they asked for might be one answer to the job. But it’s rarely the only one, and often not the best one.
Make it a deliberate rule: in discovery conversations, you don’t show prototypes, you don’t describe features, you don’t ask for feedback on what you’re planning to build. You observe, you ask, you listen. The goal is to deeply understand the current experience — frustrations, workarounds, moments of friction — before you’ve formed an opinion about the solution.
This sounds simple but it requires real discipline. Most teams default to showing something as soon as they have it. Holding back until you’ve genuinely understood the problem first is a habit that has to be built intentionally.
Opportunity scoring — popularised by Tony Ulwick’s Outcome-Driven Innovation — asks users to rate how important a particular outcome is to them, and how satisfied they currently are with how well existing solutions achieve it. The sweet spot is outcomes that are highly important but poorly served: these are the genuine gaps where a new feature can create real value.
This moves prioritisation from opinion and instinct to evidence. Not perfectly — no framework eliminates uncertainty — but significantly. The decisions you’re ranking are grounded in actual user priorities rather than internal gut feel.
A feature isn’t finished when it ships. It’s finished when you’ve reviewed whether it did what you set out to do. Set a review date at the time of launch — four to six weeks out — and hold the team to it. Look at the usage data, collect qualitative feedback, and compare what happened to what you expected. Then document the findings somewhere the whole team can see them.
This creates an institutional memory that gets better over time. Teams that do this consistently get progressively sharper at estimating impact and identifying real problems. Teams that skip it keep repeating the same mistakes with slightly different feature names.
Not every insight comes from a customer interview. In-product surveys, session recordings, support ticket analysis, and churn interviews are all underused sources of signal that reflect the broader user base rather than just the loudest voices. Building a habit of triangulating across these different sources — rather than relying solely on whoever emailed in last week — gives you a much more reliable picture of what’s actually happening out there.
All of these fixes point in the same direction: slowing down enough to understand the problem before you race to the solution. That’s genuinely hard in an environment where stakeholders want to see progress, sales teams want features to sell, and the instinct is always to build something tangible.
But the teams that get this right — that invest in real discovery, maintain honest feedback loops, and measure success by outcomes rather than output — consistently build products that users actually value. And that’s what makes everything else downstream easier: sales, retention, growth, and the next roadmap conversation.
Justin Roberts is the founder of Reloop Digital, a B2B SaaS consulting practice specialising in product strategy, UX design, and digital delivery. If your team is wrestling with prioritisation or discovery, get in touch.