The Rudder Fallacy – Adopting Lean Startup Principles

Running a lean team is a lot like getting in a crew boat. (Not a rowboat. A crew boat.)

lean startup principles - 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.

lean startup principles - metrics dashboardThe 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.

In a startup, team velocity precedes measurable product progress. Click To Tweet


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.

You have to start rowing before you can worry about which direction you're headed, even if you're headed into the rocks. Click To Tweet


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.

If your definition of success is product progress then 90% of your experiments will end in failure. Click To Tweet

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.

If your definition of success is doing 'stuff,' you'll be winning right up until the moment of bankruptcy. Click To Tweet 90% of adopting lean is changing the measure of progress from 'doing' to 'learning.' Click To Tweet

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…

If the team starts arguing about whether the test is valid, you've won. Click To Tweet

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.

lean startup principles - Fail fast, try again

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.

Discussion (10 comments)

  1. Stephen GOO says:

    There’s one critical thing about the Rudder on a Boat:

    It doesn’t work unless you’re Moving

    Fully Agree …

    Never impede the Momentum of the Business…

    To address the dynamics of everyday business, Push Decision Making Capability ( with guidance / parameters from above ) as forward in the Org as possible.

    Keep moving and adjust Rudder as Needed.

    Its Spring Allergy Season for You & your Dog.
    If your Itchy Dog is [Allergy] Sad …
    We can Doggy GOO Help.

  2. Rich Mironov says:

    Agree completely, once the boat is crewed and launched.
    As a sometimes-founder and early-on-the-scene product guy, though, I feel a strong obligation to provide some initial direction to the team (boat) *BEFORE* we start spending precious money/blood/time/love rowing.
    IMHO, a week (or four) spent talking at length with potential users/targets – and confirming some general need for our intended thing – needs to happen before we put the shell in the water. I see so many young teams with entirely unvalidated ideas staffing up and rowing.
    It seems tremendously wasteful to start steering only after assembling a full boat, esp. since very early input might influence skills/talents that we want among the crew.

    1. Tristan says:

      Ah interesting. I was not thinking of the boat as the product. The boat is your company.

      Talking with customers is part of velocity to me. So that’s already moving.

  3. Magne says:

    Thans, that was a good one Tristran!

    Reminds me of something I learned:

    “You have to have a process before trying to manage process”.
    I was trying to manage and set up a SCRUM process with a team before we actually had some steam and were developing stuff. They didn’t buy into it, because it seemed to them as overhead at the time, instead of just starting to work on something, and coordinating by email, and take it from there. Too much process in the beginning can kill steam.

    1. Tristan says:

      Great point. All process provides a certain value, but if you haven’t encountered the problem, then you can’t recognize the value! So better to let problems kick up first sometimes.

  4. Morten Lundsby says:

    Great point on team velocity. I wrote a post and some pointers on decent vs. excellent vs. no experiments over the weekend for a team I’m working with.

    I tried boiling it down to having no process (or, no 37 page experiment process document actually) and instead focusing on just a few things to help get going and to have some level of success fast:

    1. Pick the question to be answered
    2. Define the decision to be made
    3. Decide when to evaluate and make that decision AND schedule it on people’s calendar right away

    Nothing new, just less. The first two help get to a decent (not excellent) experiment setup. The last helps get stuff done and followed up on, which is where the wheels tend to come off I find.

    1. Tristan says:

      That’s great. Retros and next step meetings seem very critical for everyone.

  5. David says:

    Great post Tristan.

    There is often too many people in the boat, especially at first when your are in search of problem/solution fit.

    Start with a smaller boat 🙂

    1. Tristan says:

      Cross functional boat? 🙂

  6. Adam Williams says:

    Great article! This is exactly what I need to read today! It’s important to validate your assumptions, A/B test product versions etc. but if you have no forward motion it’s very difficult (impossible) to adjust your direction.

  7. Pingback: Adopting the Lean Hype Cycle by @TriKro

  8. Pingback: The Rudder Fallacy – Adopting Lean Startup Principles | Digital Marketing Blog

  9. Pingback: The Rudder Fallacy – Adopting Lean Startup Principles | Cornel Lazar

  10. Pingback: The Rudder Fallacy – Adopting Lean Startup Principles – Cornel Lazar

  11. Pingback: S.I.M.P.L.E. before S.M.A.R.T. – Thoughts from a Lean Startup Coach & Innovation Ecosystem Designer

  12. Pingback: S.I.M.P.L.E. nên trước S.M.A.R.T. – TBI | Technology Business Incubator Center

  13. Pingback: In Defense of Experiment Velocity – Thoughts from an Innovation Coach & Ecosystem Designer

  14. Pingback: S.I.M.P.L.E. nên trước S.M.A.R.T. – FINNO

  15. Pingback: S.I.M.P.L.E. nên trước S.M.A.R.T. – ZeFro

Got something to say?

This site uses Akismet to reduce spam. Learn how your comment data is processed.