A cheap yes that leads to an expensive no

For most of my career I batted somewhere around .300 on product bets. One in three landed, and in baseball that's considered pretty good.

I should be clear that I've never played baseball. Hand me a bat and I'd hit maybe .050, and that's if the pitcher felt sorry for me. But metaphorically, one in three was my rate for a long time, and if you'd asked me about it I'd have told you that was just the job.

Over the last couple of years, across the clients I'm working with, my own count puts me somewhere north of .900. I want to be careful with that number – it's my tally of my own bets, not an audited figure, and small samples flatter everybody. But the shift is big enough that I've stopped explaining it away, and nothing about my judgment got sharper. What changed was the price of knowing things.

Fail fast made sense when research was expensive

I think the phrase came out of Facebook originally – try things, get them out there, see how the user base responds. There's real wisdom in it, and I've used it in my own business. Run an experiment, learn from it, pivot, try something a little different.

Dave Parker's Trajectory: Startup is where I first sat with the problem underneath it. Your telemetry tells you what happened. It doesn't tell you why. And while you're gathering that incomplete answer, you're burning capital to do it.

The metaphor that gets used here, which comes from Jim Collins and Morten Hansen in Great by Choice, is bullets and cannonballs. You fire small bullets while you're figuring out your alignment. Once you've got the trajectory right, you load the cannonball and take the big swing. That's a better model than shipping a series of full-sized guesses and calling the wreckage data.

My version has drifted somewhere else, and it's the tooling of the last two years that moved it.

The old loop went: do some research, do some thinking, make an educated guess, build the feature, monitor it, make another educated guess, build that, launch, monitor. There was always some hoping-for-the-best in there. You can't get away from that entirely, because people are chaotic and don't do what the model says they'll do.

But the research I can do now, in depth and in breadth, is not comparable to what I could do then. Research at that level used to mean hiring an outside firm and paying six figures for a report. I can get to a similar place in a couple of hours for about forty-five dollars. So I do it, repeatedly, and then I come to the feature idea. And the bets keep landing.

You already refuse to accept a guess

Here's the part I'd like you to sit with, because I don't think this asks anything new of you.

You already know the difference between a hypothesis and a guess. You enforce it constantly – in discovery, in user interviews, when someone brings you an A/B test with no stated prediction and you send them back to write one down. You'd never let a team run an experiment where the answer couldn't be wrong.

Fail fast is the one place we let ourselves skip that. We take a guess, ship it, watch the graph, and call the whole thing an experiment because it had telemetry attached. Apply the standard you already hold your team's research to, and point it at your own roadmap bets. That's the entire move.

The modern version of the trap is subtler and I see it constantly. Someone wants a fast, cheap experiment, so they open Claude or ChatGPT and ask a couple of questions about the idea. And the model says yes. It says yes confidently, and it says yes far more often than the idea deserves, and it tells you this is a great idea and you should absolutely build it. I use these tools all day, including to help me write this. They are not built to talk you out of things.

That's a cheap yes that leads to an expensive no. Which is what fail fast has always been – an expensive no, over and over, until the money runs out.

Slower thinking, same shipping

My process isn't actually faster now. The time I spend writing epics and stories and acceptance criteria – the artifact that tells engineers what we need and who needs it and why, without specifying exactly what gets built, since that's theirs to figure out – is about what it always was.

What changed is the depth underneath it. I'm not spending my hours extracting findings out of research anymore, so those hours go into thinking instead. Questioning the thing. Poking at it. Being skeptical of my own conclusion and refining it again.

And there's a quieter argument for slowing down that has nothing to do with cost: your users cannot absorb features as fast as you can ship them. There's a ceiling on how much change a person will take in. We feel this constant pressure to build, ship, get it out, get the feedback, test it – and some of that urgency is real, and a lot of it is just fear of standing still.

None of which means holding a thing forever. I don't chase perfection and I don't shoot for 100%. I shoot for 70 or 80. If something's about 80% good, I want it out the door, because people are happier with something real they can react to than with a promise. Perfection is the enemy of good.

But do the work first. Do the thinking, especially as a product leader, because thinking deeply about this is the job and not a preamble to it. Then put it together, get it out, get your feedback. And when something doesn't work, figure out why before you reach for the next educated guess. Make the education deeper, so what you're testing next is an actual hypothesis.

Fail fast is throwing spaghetti at the wall and watching what sticks. It works, in the sense that some of it sticks. It also runs out your capital while it teaches you very little about why.

You can still get things out the door at a good rate. You can just be far more likely to be right when you do.