Shipping Velocity vs Being Right: My Two Years Shipping Zero

The short version

Microsoft Research paid me to ship nothing for nearly two years on .NET-era work, and it was the best product training I ever got. The reason is counterintuitive: with no ship date to hide behind, the only thing I could be judged on was whether my thinking was correct. That taught me to separate being right from being shipped, which is the hardest and most undervalued discipline in product. The industry worships shipping velocity, and velocity is a real skill, but it is not the same skill as being right, and we constantly confuse the two. In the AI era this matters more than ever. When an agent ships a working prototype in an afternoon, raw velocity stops being a moat, because everyone has it. The scarce skill becomes knowing what deserves to ship. Cheap building turns "ship nothing until it's right" from a luxury into a discipline.

Early in my career, Microsoft Research paid me to ship nothing for almost two years. No launches. No release notes. No demo day. From the outside it looks like the least productive period of my professional life. It was the most formative. I have spent twenty years since trying to keep one thing it taught me, and I think it is about to become the most important skill in product.

The discipline of having no ship date

When you have a ship date, the ship date does your thinking for you. The deadline becomes the goal, the launch becomes the proof, and "we shipped" becomes the answer to "was it good." This is comfortable. It is also a way to avoid the hardest question in product, which is not "can we ship this" but "should this exist at all."

At Microsoft Research there was no ship date to hide behind. The work was foundational, .NET-era systems thinking, and the only thing anyone could evaluate me on was whether I was right. Not whether I shipped, not whether I hit a deadline, not whether the demo got applause. Was the thinking correct. Would it hold up. Could I defend the claim when someone smarter than me attacked it.

That is a brutal and clarifying way to work. Strip away the launch, and you cannot launder weak thinking through a successful release. There is no dopamine hit of "it's live" to paper over the fact that you were not sure it should be live. All you have is the claim and whether it survives scrutiny. I have never been more rigorous, before or since, than in the period when I was shipping nothing.

“

A ship date does your thinking for you. Remove it, and the only thing left to judge is whether you were right. Almost nothing is more uncomfortable, or more useful.

”

Being right and being shipped are different skills

Here is the distinction the industry refuses to make cleanly. Being right and being shipped are not the same skill, and most product culture treats them as if they were.

Shipping velocity is the ability to get something in front of users fast. It is real, it is valuable, and I am not knocking it. But it answers a narrow question: how fast can you go. Being right answers a different and harder one: should you go at all, and in which direction. You can be extremely fast and extremely wrong, and ship-velocity culture has no good way to notice, because the scoreboard only counts launches. The team that shipped ten things and the team that shipped the one thing that mattered look similar on a velocity dashboard, and one of them was right.

I have watched careers built entirely on velocity. People who shipped constantly, were celebrated constantly, and were wrong about the direction the whole time, just very fast about it. The launches piled up and the company went nowhere, because nobody on the team had the separate skill of being right. Velocity without judgment is just a faster way to arrive at the wrong place. The two years I shipped nothing inoculated me against mistaking motion for progress, because I had spent two years being judged purely on direction with the motion removed.

Why ship-velocity worship took over

It is worth asking why the industry tilted so hard toward velocity. The honest answer is that velocity is legible and being right is not. You can measure deploys per day, cycle time, story points, time-to-launch. You cannot easily measure whether the thing deserved to exist until much later, and by then the person who shipped it has moved on.

So we optimized the thing we could see. A whole generation of product orgs learned to celebrate the visible act of shipping and to quietly ignore the invisible question of whether the shipment should have happened. "Bias for action" became a value, which is fine, until "action" quietly replaced "correct action" as the thing being rewarded. The result is an enormous amount of confidently shipped, confidently wrong product, built by talented people who were never given the separate reps of being right with nothing to ship.

To be fair to the other side, being right has its own failure mode, and Microsoft Research is the cautionary tale as much as the lesson. You can be so committed to being right that you never ship anything, and pure research detached from shipping can produce beautiful, correct, useless work. The goal is not to worship being right instead of shipping. It is to hold both, and to know which one you are practicing at any given moment. I needed the velocity years at Adobe, Salesforce, and Smartcat just as much as the research years. The point is that I would have been a worse product leader if I had only ever had the velocity years.

Why this is the scarce skill now

Here is why a story about shipping nothing in the .NET era is actually a story about 2026.

For most of my career, velocity was a real moat. Shipping fast was hard, so the teams that could do it had an edge worth having. That moat is draining fast. When an agent can produce a working prototype in an afternoon, raw shipping velocity stops being a differentiator, because everyone has it. The thing that used to be scarce and valuable is becoming abundant and cheap. And when speed becomes free, the only thing left to compete on is direction: knowing what deserves to ship.

This is the constraint shift I keep returning to, and here it lands on the oldest lesson I have. Cheap building turns "ship nothing until it's right" from a luxury into a discipline, because the dominant risk is no longer being slow, it is shipping the wrong thing fast and often. The team that ships ten confidently-wrong prototypes a week is not winning, it is generating expensive noise at high velocity. This is exactly the failure mode I describe in Cagan versus the product builder, where prototype-first curdles into thinking-never because the demo replaces the falsifiable claim.

The antidote is the thing Microsoft Research drilled into me, and it has a modern name. State the claim before you build. Define how you would know you were wrong. Treat the question as the deliverable, not the artifact. That is the spirit of the eval is the spec: the test of whether you were right matters more than the thing you shipped. At Falkster.AI the entire loop is built on this. The listening agents extract a real customer outcome, the prototype answers a specific claim about that outcome, and the speed of building is in service of being right faster, not in place of it. Same-day prototypes are only valuable if the day started with a claim worth testing.

“

When speed is free, shipping the wrong thing fast and often is the dominant risk. "Ship nothing until it's right" stops being a luxury and becomes the discipline.

”

Pick one thing to try

This week, before you build or ship anything, write down the claim you are actually making. One sentence: "I believe X about this customer, and I will know I am wrong if Y." Then build. Then check the claim against what happened, separately from whether you shipped. The act of writing the claim before you start, and judging yourself on the claim rather than the launch, is the entire lesson of two years of shipping nothing, compressed into a habit you can run on a normal Tuesday. You do not need a research lab to separate being right from being shipped. You just need to decide, on purpose, that the claim is the deliverable and the ship is the consequence. In an era where anyone can ship anything in an afternoon, that is the last skill that is still scarce.

Sources: Marty Cagan / Silicon Valley Product Group, on outcomes over output · Simon Willison, on evaluating AI-built software and what deserves to ship · Harvard Business Review, on bias for action and decision quality