At our last sprint retro, someone asked a question that landed harder than expected: "We shipped 14 features last quarter. Can anyone name one that meaningfully moved a user metric?" The room went quiet. We could name the features. We could describe what each one did. But connecting any of them to a change in user behavior? That was harder.
We're not unique in this. Product teams in 2022 are faster than they've ever been. Better tooling, shorter cycles, more deploys per week. The infrastructure for shipping has never been more efficient. And yet, when I talk to PMs at other companies, I hear the same thing: we're shipping constantly, but we're not sure we're innovating.
The velocity trap
Speed is seductive. When the team is moving fast, it feels like progress. Standups are crisp. Tickets close. Releases go out. But speed without direction is just motion. And motion without learning is just waste.
Most product teams I know spend the vast majority of their time on delivery: building, testing, deploying, fixing. The smaller slice, the part where you figure out what's actually worth building, gets squeezed into the margins. A quick brainstorm before the sprint starts. A few user interviews if there's time. A gut check from the PM who's closest to the customer.
The bottleneck has shifted. It's no longer "can we build it fast enough?" For most teams, the answer is yes. The bottleneck is "are we building the right thing?" And that question doesn't get answered by shipping faster.
What innovation actually requires
Innovation requires learning, not just launching. The difference is subtle but important. Launching tests whether you can build something. Learning tests whether you should have.
A colleague told me recently about a feature her team spent six weeks building. Solid research going in. Clean execution. Good adoption in the first week. But by week three, usage flatlined. "We built exactly what users said they wanted," she said. "Turns out what they said they wanted and what actually changed their behavior were two different things." The feature shipped. The learning came after. And it was expensive.
The teams that consistently innovate don't just move fast. They invest in understanding the problem before committing to a solution. They test assumptions early, before the full engineering investment. They treat every launch not as a finish line but as a data point.
The uncomfortable question
Shipping is the easy part. It's visible, measurable, and satisfying. The hard part is slowing down just enough to make sure what you ship was worth building. Not every team is willing to ask that question. But the ones that do are the ones that actually innovate.
Next in this series: the one habit that changes how teams learn.