Stop Building the Wrong Features: A Better Approach for B2B SaaS Teams

Enterprise SaaS teams often fall into this mistake. If one customer is lost, a big client sends a frustrated email, or a prospect requests a feature during a sales call, it can quickly add a new item to the roadmap. The feedback isn't always incorrect, but it often comes from a small, unrepresentative group. Meanwhile, the quiet majority—the users who use and appreciate the product daily—rarely influences the planning process.

The result is a roadmap that appears customer-oriented but is, in fact, only reactive; instead of addressing the needs most users share, you end up designing for the exceptions.

Talking to lots of customers isn’t the same as doing real discovery. If you go into a conversation already thinking about a feature, you’ll look for reasons to support it. Users are usually polite—they’ll try your prototype, say it looks good, and still never use it after launch.

Good discovery begins with the problem, not the solution. It’s about learning how people work now, where they struggle, what they’ve already tried, and what they’ve learned to live without. This leads to a much different conversation than just asking, “Here’s what we’re thinking of building—what do you think?”

Figures such as velocity, story points, and the number of features shipped each quarter have a soothing effect since they are easy to monitor and generally show an increase. However, releasing more features does not necessarily mean more value is being created; a team can be highly productive yet still spend months developing things that do not contribute to retention, activation, or revenue.

It has nothing to do with how hard people work or how they carry out their tasks. It's a question of how you understand success. If teams are rewarded based on the products they ship rather than the actual changes they make, the system will keep producing the wrong results, no matter how talented the individuals are.

In many organizations, discovery is just a step before development starts. The team talks to users, writes down what they learn, and passes it to design. By the time it reaches engineering, the original problem may have passed through several layers, losing the most valuable insights along the way.

Continuous discovery is still uncommon, and teams often lose contact with users throughout the building process. Consequently, the teams usually proceed with the development based on a snapshot of user needs that has already become outdated before development even begins.

Post-launch reviews are often overlooked in the product process. Teams celebrate the release, call it a win, and move on to the next thing. But if you never stop to ask whether the feature actually solved the problem, you miss the most valuable learning and the honest feedback that could improve your next product decision.

The Jobs-to-Be-Done approach is valuable in the context of product development since it changes the emphasis from what users ask for to what they are actually trying to achieve. It is not always the case that people want a calendar integration; what they really want is to avoid having to switch tabs during a sales call. They don't want a bulk export facility because they do enjoy exporting data; what they want is to stop their manager from asking them for reports.

By viewing needs in terms of jobs—that is, in relation to the functional, social, and emotional outcomes—you find a great many more possible solutions. The feature a user asks for may address the job, but it is by no means the only way to do so. In fact, it is often not the best way.

Establish a clear rule: discovery conversations are meant to build understanding, not validate proposed solutions. Do not show prototypes, promote specific features, or ask users to respond to your plans; instead, observe, ask questions, and listen. The aim should be to thoroughly understand the existing experience, covering the frustrations, workarounds, and pain points, before deciding on a solution.

It may seem straightforward, but it requires discipline. Most teams want to show their work as soon as they have it; you have to deliberately develop the habit of delaying and concentrating on the problem until you actually understand it.

Opportunity scoring, a concept made well known through Tony Ulwick's book Outcome-Driven Innovation, focuses on the outcomes users care about rather than simply the features they request. Users assess how important an outcome is to them and the level of satisfaction they currently experience with existing solutions. The most promising opportunities lie where importance is high, but satisfaction is low—areas where meeting users' actual needs can generate real value.

This method shifts the emphasis from opinions and instinct to evidence. While no framework can eliminate all uncertainty, it helps you base decisions on what users really value rather than what the team thinks.

You shouldn't consider a feature to be completed just because it has been released; it's only completed when you've verified that it has achieved your objectives. Schedule a review four to six weeks after launch, and make it a permanent part of your process. Examine usage data, gather feedback, and compare actual results with your expectations. Finally, record the lessons you've learned so that the entire team can see them.

Over time, the team accumulates valuable knowledge. Teams that always close the loop become better at forecasting the impact and at identifying actual problems, while those that don't keep making the same mistakes but instead give the mistakes different feature names.

It isn't true that all valuable insights come from customer interviews. You can also gain insights from in-product surveys, session recordings, support tickets, and churn interviews, just as much as from the most outspoken customers. When you examine all of these sources rather than just the most recent email, you end up with a much clearer understanding of what is actually happening in your product.