The Validation Gap: Why Teams Build Features Nobody Can Use

Welcome back to Gyanesh on Product. This week I'm joined by Sreeram Narayan , Director of Product at Pine Labs. Sreeram has spent years building and scaling products in high-pressure, fast-moving environments where the cost of getting validation wrong is real and immediate. In this discussion, we go beyond frameworks and surface the signals, trade-offs, and leadership decisions that determine whether validation is real or just theater.

We’ll be following a mirrored format across 7 subtopics. Sreeram brings the leadership practitioner's lens forged in high-stakes environments. I bring an emerging lens shaped by curiosity and an understanding of consumer behavior. Together we trace how validation gets lost, how teams confuse speed with progress, and how to build products users can actually use.

1. The validation gap defined

Sreeram's lens:

A quiet crisis is unfolding in modern product teams. It doesn't announce itself with flashing red metrics or angry customer emails. Instead, it arrives as a slow burn: teams shipping feature after feature, hitting roadmap targets, celebrating velocity—while users quietly abandon the product because it's unusable.

The story is familiar. The roadmap appears impressive. Stakeholders are satisfied. Sprints finish on schedule. The team is shipping consistently. Then adoption lags after launch. Support tickets pile up. Rework, workarounds, and urgent usability fixes consume 40–60% of a team's delivery effort.

But here's the twist: this isn't an execution problem—it's a validation problem.

The core issue: Teams have conflated three very different things:

1. Internal alignment ("Everyone on the team agrees this is the direction")

2. Stakeholder sign-off ("The executive sponsor approved the spec")

3. User validation ("Real users with real workflows can actually use this")

Gyanesh's lens:

Consumers today operate in environments defined by fractured attention, low switching costs, and limited patience. Products that fail to meet these realities don’t get second chances. The gap isn’t between intention and execution—it’s between what teams hope users will adopt and what users actually deem valuable. A book that I recommend reading based on my experience is: “The unmanageable consumer”

A pattern I’ve observed across consumer products is that validation becomes a downstream formality rather than an upstream constraint. At Snapdeal, for instance, a loyalty subscription for tier-2 and tier-3 customers was launched without examining whether the underlying behavior—loyalty—existed in the segment at all. The result wasn’t a design failure, it was a validation failure. The market rarely rejects a feature loudly; it simply ignores it.

When teams conflate internal agreement with external truth, the product becomes a projection rather than a response to user behavior.

You can check this case out in more detail here: When VCs dictate product decisions, an ex-employee perspective on Snapdeal VIP

2. From product teams to feature factories

Sreeram's lens

In this void, feature factories flourish. Shipping becomes the PM's responsibility. PMs are increasingly over indexing on getting things shipped on time and in crunched timelines. Building becomes the engineer's job. Pixel-pushing becomes the designer's job. Making sure the product functions for the real user is unfortunately left to post release.

The road map turns into a treadmill. Often there will be scope creeps and spill overs. The scenery doesn't change even though you're running quickly.

Gyanesh's lens

Feature factories don’t emerge because teams dislike discovery—they emerge because discovery has weak institutional incentives. In environments where roadmaps are dense and velocity is celebrated, additional features feel like progress even when they reduce clarity for the user.

From a user-experience standpoint, feature proliferation increases cognitive cost. When every screen carries similar visual weight, users struggle to identify what matters. The core value proposition gets diluted by auxiliary options that exist because they were easy to ship, not because they were needed.

The strategic question then becomes: what is the user paying attention to, and what can safely be removed? Distinguishing between core value drivers and auxiliary capabilities is often the difference between durable adoption and polite indifference.

3. Why discovery gets skipped

Sreeram's lens

Discovery rarely gets skipped because teams don’t believe in it. It gets skipped because it looks slow in environments that reward motion over understanding.

Roadmaps are pre-committed. Stakeholders are optimized for delivery dates. Research feels intangible compared to shipping something that can be demoed. Under pressure, teams compress discovery into a few conversations or replace it entirely with assumptions and internal debates that feel productive but aren’t grounded in real use.

The irony is that validation doesn’t disappear. It just moves downstream. Post Release.

Teams end up “learning” during delivery or worse, after launch. That is the most expensive point in the lifecycle to discover you built the wrong thing. By then, code is written, dependencies are locked, and go-to-market plans are already in motion. What follows is predictable: workaround-heavy adoption, rushed fixes, and silent rework that can consume 40–60% of the original effort.

This is how velocity quietly collapses. Not because teams moved too slowly, but because they mistook speed for progress.

Gyanesh's lens

Discovery is tedious, expensive, and intellectually uncomfortable. Many teams reduce it to interviews or surveys because these methods are easier to schedule and present well in status updates. But real discovery—shadowing, contextual inquiry, grounded research—exposes assumptions that were more convenient left unchallenged.

The “fail fast” slogan has also been misinterpreted. Failing fast makes sense when the cost of failure is low; in complex products, failure post-build is rarely cheap. Teams often cite cost or speed as justification to skip discovery, but the financial and cognitive cost simply gets deferred into rework, support load, and churn.

Skipping discovery is easy in the moment, but expensive in retrospect.

4. The cost of shallow validation

Sreeram's lens

Shallow validation produces expensive surprises. Teams ship features that look correct but fail in real environments. Post-launch support escalates. Sales teams create custom walkthroughs. Adoption stalls. Workarounds accumulate. Rework and usability fixes can consume 40–60 % of delivery capacity in such scenarios. This isn't efficient speed. It's deferred learning.

Teams may look at the cost of building a new feature in the product, but if you factor in opportunity costs, it’s a different ballpark altogether.

Gyanesh's lens

Shallow validation turns the product into a negotiation between intent and reality.

Shallow validation creates a false sense of confidence. Teams treat prototype approval or stakeholder enthusiasm as evidence that users will be able to integrate the feature into real workflows. But validation isn’t about nods—it’s about sustained usage without explanation.

A common anti-pattern arises when MVPs are validated in Figma rather than in context. Prototypes remove friction by design, so users behave differently. Similarly, internal demos use guided paths that smooth over the very frictions that kill adoption in the wild.

The result is a quiet form of usability debt: the product technically works, but only under idealized conditions. Support tickets, training material, and walkthrough videos show up next—not because the feature is complex, but because it was never validated for how humans actually behave.

5. Common failure patterns

Sreeram's lens

The same patterns emerge repeatedly. Internal demos are mistaken for user proof. Edge cases are ignored until they become mainstream. Usability debt compounds with each workaround. Teams assume documentation can compensate for poor design. These patterns indicate that validation was either skipped or misunderstood.

These failures are rarely random. The same patterns surface again and again, regardless of company size or domain.

Internal demos are mistaken for user proof. A feature works in a controlled walkthrough, so teams assume it will work in the messiness of real workflows. Edge cases are dismissed as rare, until usage scales and those “edges” become the default path. By then, fixing them is no longer a design problem. It is a structural one.

Usability debt compounds quietly. Each workaround added to “unblock” adoption increases cognitive load for the user. Instead of simplifying the product, teams add documentation, tooltips, and training in an attempt to explain away poor design. This is usually the clearest signal that validation failed upstream.

When these patterns show up, it is not because teams ignored validation entirely. It is because they misunderstood what validation actually means. Proof is not agreement in a meeting. It is sustained, low-friction usage without explanation.

Gyanesh's lens

Enablement sessions often reveal this failure mode. PMs guide users through the “happy path” with context, priming, and verbal cues. In reality, users operate unguided, under time pressure, and with incomplete information. Their path is rarely linear and almost never optimal.

One of the most revealing analyses I’ve run is a path-flow or CTR Sankey visualization. It shows not what the team expects users to do but what users actually do. When the path of least resistance diverges from the intended path, the product isn’t intuitive—it’s instructional.

Most usability debt starts with this mismatch between intended workflow and observed behavior.

6. Frameworks to close the gap

Sreeram's lens

High-effectiveness teams follow a sequence: discovery precedes validation, validation precedes delivery. During validation, teams expose prototypes to real users in their environment with minimal prompting. Pre-commitment checks ensure solutions are viable before build. Teams measure learning before measuring output.

The best validation experiences I've witnessed felt more like anthropology than UX testing. You watch users struggle. You ask quiet questions. You resist the urge to rescue them. If they can't navigate the workflow unassisted, validation hasn't occurred. This approach also enables originality. Teams are more likely to innovate when they understand where intuition aligns with user behavior rather than relying on familiar templates.

Gyanesh's lens

One framework I’ve found consistently valuable is Amazon’s “Working Backwards” model. By forcing teams to articulate the user benefit, narrative, and adoption mechanism before writing a single line of code, the model puts user comprehension ahead of feature completeness.

This approach doesn’t eliminate validation risk, but it constrains it earlier in the lifecycle. Instead of asking “can we build this?” teams ask “why would anyone care, and how would we know?” That shift alone closes a surprising amount of the validation gap.

7. What high-maturity teams do differently

Sreeram's lens

High-maturity teams look slow at the start and frustratingly calm under pressure. That is usually because they are optimizing for outcomes, not optics.

They ship fewer features by design. Instead of racing to fill roadmaps, they spend disproportionate time in discovery and early validation. Engineering time is treated as an irreversible investment, not a sandbox for learning.

They align incentives around learning and adoption rather than output and velocity.

Velocity is measured by how quickly teams eliminate the wrong options, not how fast they push code.

They start slower because they are reducing risk early. They finish faster because they are not paying for it later.

Gyanesh's lens

The most effective teams I’ve observed treat early ambiguity as a competitive moat. They spend disproportionate time refining the problem space, reducing variance in assumptions, and validating behaviors before interfaces.

Tools like A/B testing and controlled exposure become mechanisms for learning rather than performance measurement. A trained PM navigating a flow and a first-time user navigating the same flow produce very different outcomes, and teams that systematically measure both avoid the trap of internal correctness.

These teams aren’t slow—they are compressing risk upfront so they can scale faster later.

Some of the AB testing use cases that I follow can be found here: https://www.linkedin.com/in/jlinowski/

A small case to ground this discussion

Scenario

Sreeram's approach

Before rushing into feature delivery, I would reframe the problem statement for this use casearound merchant decisions, not dashboards. In fintech, reporting only matters if it reduces uncertainty or drives an immediate action. The goal is not to ship analytics or download a report, but to ensure it is meaningful to perform a business action or act onto somethign based on it.

Here is how to approach this in steps

• Start with discovery in real merchant workflows: settlement checks, reconciliation, disputes, daily closures - by observign how they go about these routines in daily activity

• Sit with them/ Shadow them while at business, conduct interviews across merchant segments (SMB, mid-market, high-volume) to avoid average-user bias

• Form clear hypotheses around the primary decision the dashboard should enable

• Pre-totype using static mocks or manual reports to test comprehension before building. This often gives early feedback and validation

• Run a low-cost pilot with a small merchant cohort before full rollout

Metrics & risk checks

• Pilot: time-to-value, task completion without support, repeat usage

• Post-pilot: adoption depth, reduction in support queries, decision frequency

• Analyze failure risks: misinterpreted metrics, cognitive overload, segment mismatch

Strong product teams will spend effort to validate decisions, not features. Shipping later is cheaper than scaling the wrong abstraction. And also you can scale faster.

Gyanesh's approach

My starting point would be to test the underlying assumption that merchants actively want advanced analytics. Stated preferences (“I want more insights”) often diverge from revealed preferences (what users actually check, how frequently, and for what purpose). Many merchants optimize for speed, clarity, and immediate business actions, not analytical depth.

To validate this, I would:

1. Map current behavior

Observe how different merchant segments monitor performance today—what they check, how often, and which tools or heuristics they rely on. This helps separate critical signals (payout status, settlements, daily closure) from noise.

2. Identify actual jobs-to-be-done

The goal is not “use a dashboard” but to support decisions like reconciliation, inventory decisions, pricing adjustments, or dispute handling. If the dashboard doesn’t accelerate or de-risk these jobs, adoption will be low regardless of feature richness.

3. Validate comprehension before investing in build

Instead of building the dashboard, I’d prototype in low-fidelity. Examples:

• static mocks

• exported manual reports

• WhatsApp-format summaries

These are low-cost ways to test whether merchants understand the information, act on it, or ignore it.

4. Measure behavioral signals, not opinions

If merchants request repeat access to the snapshots, share them with staff, or incorporate them into daily routines, that’s validation. If they surface confusion or skip sections entirely, that informs simplification.

In many cases, discovery reveals that merchants prefer concise operational snapshots over deep analytics. If so, the product direction shifts from “advanced reporting” to “fast decision support,” which changes the information architecture, UI, and metrics tracked.

The objective is to optimize for clarity and business impact, not analytical sophistication.

A closing challenge