“Launch and learn” is a great way to tune innovative, digital products to customer needs. But at worst, I’ve seen “launch and learn” used as an excuse for lazy, dysfunctional teams to launch ill-thought-out products that don’t provide customer value. And then listen in all the wrong ways.
Digital teams can behave in strange ways. Designing software can do that to you. To highlight how launch and learn can go wrong, let’s try a thought experiment…
If the Johannesburg’s rail link had been launched by a digital team
Johannesburg’s airport rail link, the Gautrain, was launched in 2010 before it was finished. But they did a pretty good job. I was happy to put up with the unfinished stations because they provided something essentially valuable to me from the start: fast transport with no traffic jams.
But if the Gautrain had been rolled out in the style of many a digital innovation, the process might have looked something more like this:
Version 1.0 Beta
Open the tracks between Rhodesfield and Marlborough, two small stations. Don’t run any trains. Let customers walk between the two stations.
User opinion: This could be a good way to get fit. People might like this. (Which actually means – “I don’t really see the point.”)
Version 1.1
Open the tracks from the airport to Sandton.
User opinion: This could be useful, but can we have rollerskate rental at each station? Walking is too slow. Also, can we have 25 extra stations, since I have to skate right past my office, get off at Sandton station, and then skate back?
Version 1.2
Provide a rickshaw service to Sandton.
User opinion: I preferred walking. Can we give rollerskates to the rickshaw men? They go too slow. And can we add more rickshaws? And where are those extra stations?
Version 1.3
Give rollerskates to the rickshaw drivers and open 15 new stations.
User opinion: We’re getting a lot of rickshaw snarlups at the stations. It’s slowing traffic to a crawl. The station you opened still isn’t near to my office. It’s also not good when it rains because the rain blows in under the rickshaw canopies. I’m going to go back to using my car.
At this point, further investment seems unlikely.
Unless you can get a visionary investor to buy into…
Version 2.0
Replace the whole rickshaw system with frequent, fast trains and reduce stops to just a few, high-traffic stations. Spend on a major marketing campaign to get people to come and try the service again: “No More Rickshaws TM”
User opinion: I preferred the rickshaws. And I resent having to pay.
User opinion three weeks later: I can’t live without it.
How it goes off the rails
That (fictional) project failed because the team didn’t deliver visible customer value at launch, and then made knee-jerk reactions to customer whims.
They launched the easiest thing. Because software development is hard, this is understandable. But it’s not great for business. Customers come to you for value. If the value were easy to deliver, it wouldn’t be value — and they wouldn’t pay for it. As Jeff Bezos famously said, “You earn reputation by doing hard things well.” If you launch something that doesn’t prove customer value, you’re just teaching the market that your product is pointless and should be ignored. You’re alsdo demonstrating that as a team, you can’t deliver the goods.
They built what people said they wanted. Your users are not designers – you are. People can’t imagine the future and are bad at predicting what will make them happy. Remember Henry Ford and his “faster horse?" Your job is to observe and understand what they need, then design and develop innovative ways to give it to them.
So they blew thier big chance by losing investor/executive confidence from the start. Even though executives will demand early launch, they’ll also be the first ones to wield the axe when a rushed idea doesn’t fly.
The Right Way
Rather than going for a throw-it-at-the-wall-and-see-what-sticks approach, use a more scientific method.
Don’t launch the minimum product. Launch the minimum desirable product.
- Observe and interview users in contextual research or competitor usability testing sessions.
- Work through a concept design phase: personas, scenarios, storyboards, and iterative feedback.
- The design will get more and more complex, but stick with it and it will collapse into something simple. Then you’ve got a product vision and a version 1.0 that’s worth building.
It’s a few weeks of work, but it will stop you from wasting your big chance on building the wrong thing.
Learn by observation, rather than listening to opinions.
- Look at web analytics to find out what people are doing. Use usability testing to observe and uncover why they are doing it.
- Try out new ideas with A/B testing or paper prototype tests.
- Don’t wait for the feedback to come to you. Go get it with usability testing.
- If customers say they want feature X, understand what underlying need has driven that request.
- And don’t ask “would you like the service to do this?” because people have a terrible tendency to answer “yes”.
So let’s re-write the classic dot.com advice with a bit more precision: Launch valuable, easily-understood websites and apps as quickly as possible, so that you can start gathering reliable observations and feedback from real customers.