We’ve all been there.

You greenlight a new feature, maybe even a whole product, confident it’s going to delight users. You rally your team: developers work late nights, designers pour themselves into the UI, and QAs go into overdrive testing every edge case. Launch day comes with excitement. You push the feature live.

And then… crickets.

Nobody uses it. Or worse, they do use it, and it doesn’t solve their problem.

If that sounds familiar, know this: you’re not alone. I’ve been there, too, while managing a large product team at an Inc. 500 company with a massive development budget. Despite our resources, we fell into the trap of building first, validating later. And the consequences weren’t just a bruised ego; they were long-term: bloated codebases, wasted sprints, and growing technical debt that haunted future work.

Why Do We Keep Doing This?

One of my biggest mistakes was rushing to conclusions. I thought I knew our customers. I’d seen the data. I’d been in the meetings. But I hadn’t talked to enough of them. I hadn’t truly understood them.

And worse, I hadn’t asked “why” enough.

Ask Why. Then Ask It Four More Times.

If you’re not familiar with the Five Whys technique, it’s simple and powerful: when faced with a problem, ask “why?” to the right person five times to get to the root cause. It’s not just for debugging systems, it’s for understanding people, too.

For example:

  • Why did customers abandon the new feature?
    • Because it didn’t solve their immediate need.
  • Why didn’t it solve their need?
    • Because it was based on internal assumptions rather than real user problems.
  • Why did we make those assumptions?
    • Because we didn’t validate them with actual users.
  • Why didn’t we validate?
    • Because we skipped research to “move fast.”

And there it is - the uncomfortable truth. We wasted time not because the team wasn’t talented, but because we weren’t aligned with reality.

What I Learned, and What You Can Do to Stop Wasting Time

1. Customer Learning Isn’t a One-Off

We treat research like a checkbox before launch. But real insight comes from continuous engagement. Customers evolve. Needs change. If you’re not talking to users every sprint, you’re making decisions in the dark.

Takeaway: Bake research into every sprint. Whether you’re validating what you just built or exploring what’s next, never stop learning.

2. Identify Your Customers First

Before testing ideas, clarify who your customer is. Not everyone using your app is your ideal user. Tools like empathy mapping help bring customer personas to life and avoid vague generalizations.

Takeaway: Define clear segmentation criteria up front. It’s far more effective than wading through messy analytics after the fact.

3. Keep Research Simple and Actionable

You don’t need a full-time researcher or expensive platforms. Customer interviews and observations are surprisingly easy to organize and often yield the richest insights.

Takeaway: Start small. A 30-minute customer call might save 3 months of wasted dev work.

4. Define What You Want to Learn First

It’s tempting to schedule interviews and figure things out on the fly. But if you’re not clear on your learning outcomes, you’ll come away with noise instead of insight.

Takeaway: Tailor your research method to your learning goals. Want to test usability? Run a task-based interview. Want to understand customer pain points? Observe them using (or avoiding) your product.

5. Start Small

Every significant feature can be broken down into smaller features. You should be doing this anyway, if you’re following Scrum and agile development methodologies. However, the good news is that you can deploy more minor updates to your SaaS and test those features with customers, with the primary goal of gathering feedback.

6. Use Feature Flagging

Feature flagging is a method for turning on or off features for specific users of your app. It’s a great way to get feedback when you’re still unsure about how it will be used or its effectiveness.

For example, you can enable a specific feature for only 10% of users first, validate it, and then move on to the remaining 90% of users.

The downside of this is that you’ll need at least some traction for this to be worth it. But it's a good strategy, especially for those high-risk features where the payoff isn’t so sure.

7. Kill Bad Features Fast

Not only should you be deploying new features and improvements, but you should also be removing the old ones. Just like a marketing campaign, you stop spending dollars on marketing that isn’t producing a payoff. You also need to do the same with your SaaS.

Even if just a small number of users use it, you should always be thinking of killing features and stripping them out. Feature bloat can have detrimental impacts on the user experience; nothing is more scary to a user who logs in for the first time than seeing a million bells and whistles.

Killing bad features also allows your development team to be lean and mean, with less technical debt accumulation.

Trust me on this one - part of your consciousness should be devoted to thinking about which features to cull.

8. Focus on Customer Outcomes, Not Features Deployed

Every new feature you deploy should be tied to some kind of key performance indicator or success metric, and those metrics should be watched closely. They should be a measure of customer success at solving a specific problem.

For example, if you’re fixing your onboarding process, a very simple metric could be number of completions, and those who do complete it, what is their curn likelihood?

If you reframe your development process to around delivery tangible outcomes for your customers, this will really set you apart from the development teams that are continuously stuck in a deployment trap.

Conclusion - Learn Before You Build

Even with a great team, big budget, and high ambition, you can still fall short, because building the wrong thing beautifully is still building the wrong thing.

What I’ve learned (the hard way) is this: success isn’t about how fast you ship. It’s about how right you ship. And getting it right starts by deeply understanding your customers, before a single line of code is written.

This matters when you’re first starting, getting traction, but in my experience this also matters when you have a big development budgets, it’s just too easy to fall into the trap of shipping features.

So pause. Ask why, five times. Talk to your users. Then build what matters. And measure with KPIs that ensure you deliver the outcomes your customers want.