Quick Answer: In a lean transformation, team velocity matters more than steering. Many teams stall by obsessing over perfect experiments, metrics dashboards, and decision frameworks before they’ve built any momentum — what we call the “Rudder Fallacy.” Just like a boat’s rudder is useless without forward motion, as product managers, we can’t steer toward meaningful outcomes unless our team is actively running experiments first. Start imperfectly, complete Build-Measure-Learn loops, and refine technique later.

Running a lean team is a lot like getting in a crew boat. (Not a rowboat. A crew boat.) I know I know, it takes teamwork and coordination to go anywhere…you have to row together…etc. It’s an overused analogy so let’s skip the obvious parts… I’d like to talk about the rudder. And I’d like to talk to you, the team leader.

The Rudder

Whether you are adopting lean principles as a startup or as an innovation team in a larger company, it doesn’t matter. You’ll run into the same issue. You’re adopting lean because you’ve agreed to let experimentation be your true north. You set up a metrics dashboard to measure your progress, you debate and outline the company vision, and as the team leader, you make it your mission to steer the team in the right direction with…the rudder. The rudder steers the boat, and because you’re steering the boat on the basis of real metrics you expect to make progress very quickly towards your goal. (If you’re in a large company, you confidently make your dashboard accessible and send out reports to your business angel as to which needle you’re focusing on moving this month.) But it doesn’t happen. You’re steering and steering and you’re not making any seeming progress towards your goal. The dashboard won’t budge. In fact, sometimes it seems you’re drifting away. In a startup, the effect can be team strife. In an innovation team of a larger company, you’re probably about to be fired by the CEO who expects to see that metric dashboard start twitching and jumping around. You jam the rudder to the left. Nothing. You slam it to the right. Nada. Those of you who have ever been in a boat will know the issue. There’s one critical thing about the rudder: It doesn’t work unless you’re moving. You can move it left or right, shake it around, curse at it…It doesn’t do anything by itself. The rudder changes the overall direction of the boat and allows you to steer, but without any velocity relative to the ocean around you, the rudder is a useless appendage. This anti-pattern is the Rudder Fallacy.

Velocity

Many teams trying to adopt lean focus on the wrong thing. They focus on which direction they are going. They focus on improving their decision making apparatus. They talk about how much statistical significance they need in order to validate a smoke test or spend hours pondering their Business Model Canvas to make sure they’re testing the right risky assumption. None of that matters when you’re just starting out and trying to lean your team. The only thing that matters is velocity.

Progress

Your team can’t just sit around twiddling their thumbs while you decide which direction to go. They want to feel like they are making progress. What type of progress? Not product progress. If you try to measure product progress right away, you are bound for disappointment. How many teams out there can survive through failure after failure after failure without losing all hope? Measuring product progress at first is almost certainly going to kill your morale (and probably your startup). Progress is also not building stuff (if you’re an engineer). It’s not creating wireframes (if you’re a designer). It’s not writing strategic plans and pitching to VCs (if you’re a business person). It’s not just doing stuff. Doing random stuff doesn’t move your business forward and doesn’t complete the Build-Measure-Learn loop. That’s very hard. So don’t fight it. The best way to start, is just to start. Run an experiment, talk to customers, put up a smoke test. It doesn’t matter if it’s a statistically significant experiment. Just do something that might vaguely result in learning. It doesn’t matter if it doesn’t. If the test doesn’t result in learning and… I used to focus a lot on trying to get teams to run great experiments, do great customer interviews, and so forth. Perfecting that technique was my passion and that stuff is great. Having amazing discovery interview technique is worth learning… just not right at the start. Every team that focuses on running perfect experiments inevitably starts going slower and slower. They spend more time designing experiments and trying to get an A/B testing infrastructure in place. Velocity gets slower and slower and sooner or later the team starts complaining that lean startup isn’t helping them learn anything. They spend all their time building stuff. It’s not even stuff they want to be building like cool features! It’s just stuff that they’ll use to test cool features, if they ever build cool features, which they won’t because they’re busy building tests for cool features. That’s just not cool. If your team is arguing about whether the test was valid, congrats! You’ve already got everyone focused on the goal… to learn. You’ve won. First get the boat moving, then you can worry about whether the oars are perfectly synchronized.

Frequently Asked Questions

What is the Rudder Fallacy in lean startup?

The Rudder Fallacy is the anti-pattern where teams focus on steering — perfecting their metrics dashboards, decision-making frameworks, and experiment design — before they have any velocity. Just like a boat’s rudder is useless without forward motion, as product managers, we can’t steer toward meaningful outcomes if our team isn’t actively running experiments and generating learning first.

Why does focusing on perfect experiments slow down lean transformation?

When teams obsess over statistical significance, A/B testing infrastructure, and flawless experiment design too early, velocity drops. They end up spending all their time building testing tools instead of actually testing assumptions. The Build-Measure-Learn loop stalls, and teams start complaining that lean startup isn’t helping them learn — because they never complete the loop in the first place.

What should a lean startup team measure first instead of product progress?

Don’t measure product progress right away — it will almost certainly kill morale as your team faces repeated failures early on. Instead, we should focus on team velocity: how quickly we’re running experiments, talking to customers, and completing learning cycles. The quality of experiments can improve over time, but only if the team is actually moving first.

How do you start a lean transformation when the team feels stuck?

Just start. Run an experiment, talk to customers, put up a smoke test — even if it’s not perfect or statistically significant. Do something that might vaguely result in learning. If your team is already arguing about whether a test was valid, that’s actually a win because everyone is focused on learning. First get the boat moving, then worry about synchronizing the oars.

Why do innovation teams inside large companies struggle with lean startup principles?

Innovation teams face the same Rudder Fallacy as startups, but with added pressure: leadership expects metrics dashboards to show results quickly. When the dashboard won’t budge despite careful steering, teams panic and leaders lose patience. The core issue is the same — without velocity from rapid experimentation, no amount of strategic direction-setting will produce the measurable progress stakeholders demand.

Comments

Loading comments…

Leave a comment

Name *

Email * (not published)

Website (optional)

Comment *

Leave this blank

Post Comment