Originally published onΒ GrasshopperherderΒ byΒ Tristan Kromer.
Running a lean team is a lot like getting in a crew boat. (Not a row boat. 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 adotping 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 moving it left or right, shake it around, curse at itβ¦it doesnβt do anything by itself. The rudder changes the overall shape 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 Lean Startup, team velocity precedes measurable product progress.
Velocity
Many teams trying to adopt lean focusing 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.
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.
If your definition of success is product progress then 90% of your experiments will end in failure.
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 designing wireframes (if youβre a designer.) Itβs not writing business 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, then youβll be winning right up until the moment of bankruptcy. 90% of adopting lean is changing the measure of progress from doing to learning.
Thatβs very 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 great statistically significant experiment. Just do something that might vaguely resulting 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.
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 now.
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 built 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.
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.
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 designing wireframes (if youβre a designer.) Itβs not writing business 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, then youβll be winning right up until the moment of bankruptcy. 90% of adopting lean is changing the measure of progress from doing to learning.
Thatβs very 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 great statistically significant experiment. Just do something that might vaguely resulting 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.
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 now.
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 built 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.