By Priya Narula

The product is live. Users are in. The team is shipping. And somehow the numbers you actually care about are not moving.

Then someone asks the one question that stops everything cold: how do you know it is actually working?

Not “the product is live.” Is the product doing what you built it to do? Are people coming back, paying, telling others? Is the thing you built actually doing the job you built it for?

Most founders I talk to cannot answer that clearly. Not because they are not smart. Because they never set up the structure to know. And that silence, that pause when the question lands, is usually the first sign.

That is the gap I keep seeing between innovation and adoption. It is not an idea problem. It is not even a product problem. It is a clarity problem that shows up as a measurement problem, which eventually shows up as a stall.

I am working with a pre-seed startup right now. Sharp founders, a differentiated product, real users. But when I asked what metrics the team reviews together consistently, the conversation scattered. Activation numbers here. User feedback there. Investor conversations somewhere else. No shared view of what early momentum actually looks like. No agreed signal for when to push harder or when to change direction.

They knew exactly what they were building toward. What they did not have was a consistent way to track whether they were getting closer, clear timelines to hold decisions against, or a discipline of validating a use case before shipping the next feature. The vision was sharp. The operating system around it was not.

This is more common than founders want to admit. And it is fixable, but only if you treat it as a structural problem, not a motivation problem. The team is not the issue. The system is.

Here is what actually changes things.

1. Stop tracking everything. Pick two numbers and own them.

Most early-stage teams either track too many things or nothing consistently. Both land in the same place: no clear signal on whether the product is gaining traction.

You need one leading indicator, an early signal that tells you momentum is building before revenue confirms it. And one lagging indicator, the real outcome your business ultimately runs on.

Here is what that looks like in practice. Say you are building an HR tech product. Your leading indicator might be the percentage of new users who complete their first skill assessment within 7 days of signup. That one number tells you whether people are actually engaging with the product or just logging in once and dropping off. Your lagging indicator is the outcome you are selling: the number of internal mobility decisions made using the platform each quarter. You will not see that move for months. But the leading indicator tells you every single week whether you are on track.

One signal reviewed weekly. One outcome reviewed monthly. Everyone on the team reading from the same dashboard.

When you have this, decisions stop being political. You are not debating whether something is working. You are asking why the metric moved or did not. That is the shift from gut-driven roadmap decisions to a feedback loop grounded in real data. You do not need a data team for this. You need agreement.

2. Define the outcome before the build starts.

An experiment is any new bet you are about to place. A feature you are shipping, a channel you are testing, a partnership you are piloting, a pricing change you are rolling out to a segment. The size does not matter. What matters is that you are about to spend sprint capacity and runway finding out if something works.

The most expensive thing a startup can do is kick off a build with no success criteria. No defined end state. No explicit moment to ship, kill, or iterate. Just a slow fade where the feature sits in staging, everyone quietly stops mentioning it, and two quarters go by with nothing shipped and nothing learned.

Before any new build, document two things: what outcome in what timeframe tells you this worked, and what tells you it did not. Not vague targets. Specific enough that a new engineer joining the team could read it six weeks from now and make the call without pinging you.

Here is a real example. A founder was testing a new onboarding flow. Before a single line of code was written, the team aligned on this: if 60% of new users complete setup in under 10 minutes within the first week of launch, we scale it. If we are below 50%, we go back to the drawing board. Six weeks later, completion sat at 43%. The decision to rebuild was not a hard conversation. They had already made it before the sprint started. No debates. No sunk-cost spiral. Just the call, and the team moved on.

This does two things. It forces honesty about what you actually believe before you are emotionally invested in the build. And it creates permission to deprecate, which most founding teams are genuinely terrible at because killing a feature feels like failure instead of what it actually is: a faster path to product-market fit.

The startups that ship fast are not the ones with the most ideas. They are the ones who close feedback loops quickly. Build, kill, or scale. Those are the only three options. Anything else is scope creep dressed up as progress.

The gap between innovation and adoption is almost never about the quality of the idea. It is about whether the team has the instrumentation to know when it is working and the discipline to act on what the data shows.

Set the metric first. Define the outcome before the build. Review both without exception.

That is not overhead. That is how you stop shipping in the dark.

This article was originally published on Priya Narula’s Substack, Strategy Unfiltered.