The Quarter We Spent on a Maybe

I asked for one customer.

Not a business case. Not a forecast. One current or potential customer willing to work with us while we built the thing, so we would know partway through whether anyone actually wanted it.

That request never got answered. What came back instead was the total market value of the state we were expanding into.

Those are not the same answer. Market value tells you how big this could get if it works. It says nothing about whether it will. Whether anyone would show up was the only part in doubt.

The roadmap that already had pull

The roadmap I owned at the time was built on stakeholder needs and market needs, and it was holding up well. As MVPs shipped, users and stakeholders came back asking for more of them, faster. They wanted the next piece immediately.

That’s about as clean a demand signal as product work produces. People pulling work forward is behavior, not a projection or a survey response.

So I had one set of bets with observable pull behind them, and then a different bet arrived from above with a market number behind it.

The ask, and what came back

Our general manager owned the P&L and wanted a land-and-expand play into a new state. Three to four months of work, disruptive to the main track, and it would give sales something new to sell. That last part is real. Opening territory is a legitimate strategy and I wasn’t arguing against it on principle.

I tried to find a way to validate it. That’s where I got stuck, and the honest version is that I couldn’t find one. We had no operations in a comparable state to benchmark against, so there was no internal history to forecast from. And nothing specific about this state suggested it would behave differently from anywhere else we already worked.

So I narrowed the ask down to the smallest thing I could think of: one customer, current or prospective, who would build alongside us.

That ask is cheap. It costs a few conversations. And it’s self-resolving in a useful way, because if you can’t find a single customer willing to co-build, that difficulty is itself the finding, and you have it in a week instead of a quarter.

The ask went unanswered. We built it.

What happened

Three to four months of engineering and product capacity went into it.

Not one new customer came from that state. Not one user used the thing we built.

I don’t have a more interesting ending than that. The numbers are the whole result.

The argument I did not know how to make

For a long time I framed this as an argument I lost. Someone with more authority put a thumb on the scale, and product and engineering built what we were told to build without it earning its place on the roadmap.

I’ve come around on that framing. A GM who owns the P&L is supposed to be able to make a call over a product manager. That authority isn’t the failure mode. Sometimes you do have to build ahead of demand, and sometimes the person above you is seeing something you’re not.

The failure wasn’t that the bet skipped validation. The failure was that it skipped validation and then got funded as though it had passed it. It got a full quarter on the main development track, with no design partner and no condition under which we would stop.

An unvalidated bet isn’t automatically a bad bet. It’s a bet with a wider range of outcomes, and it should be sized accordingly.

I was asking the wrong question. “How do we validate this” was unanswerable, and I kept asking it anyway. There was a different question available.

What result would tell us to stop?

That’s a question a GM can actually engage with, because it doesn’t require anyone to admit the bet is weak or to produce evidence that doesn’t exist. It just requires naming a number and a date in advance. Six weeks in, if no prospect has agreed to pilot, we pause and reassess. Something along those lines is enough to turn a four-month commitment into a four-month commitment with a checkpoint.

I didn’t ask for that. I asked for proof, got a market size, and built the thing.

What I do differently now

When a bet arrives without a validation path, I stop trying to manufacture one. I go after two things instead.

The first is the smallest slice that would produce a real signal. Not the full build, and not a prototype for its own sake, but the version that puts something in front of an actual customer soon enough to change the plan.

The second is an exit condition, written down and agreed to before work starts, tied to a date.

Neither of those requires winning an argument about whether the bet is good. That’s what makes them workable. You can hold a strong opinion that something won’t work and still be useful to the person who decided to do it anyway, as long as you’re arguing about size and checkpoints rather than about who is right.

Three to four months bought us a number I could have gotten in two weeks. That’s the part I would take back.