Launch & learn: What web businesses can learn from the Gautrain

If you’ve been in Johannesburg recently, you’ll know about the new high-speed, high-tech rail link, called the Gautrain. For now, it speeds at 160km/h between the airport and Sandton, a key business district. But what’s interesting about it is that they launched it before it was done.

Many organisations launch digital products and services before completion too. It’s the “launch and learn” approach — get something out there and see what customers say. Gautrain did it (mostly) right, by providing real value from the start, so I was happy to forgive glitches. But many digital businesses don’t do so well. At worst, I’ve seen “launch and learn” used as an excuse for launching lazy, ill-thought-out products that don’t provide customer value, and then not really listening or learning at all.

The Gautrain launched by a digital team?

A version of the Gautrain rollout masterminded by many a digital team might look something more like this:

Version 1.0 Beta

Open the tracks between Rhodesfield and Marlborough. Don’t run any trains. Let customers walk between the two stations.

User feedback: 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 feedback: 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 feedback: I preferred walking. Can we give rollerskates to the rickshaw men? They go too slow. And can we add more rickshaws? It’s hard to get one when you need one. And where are those extra stations?

Version 1.3

Give rollerskates to the rickshaw drivers and open 15 new stations.

User feedback: We’re getting a lot of queues and snarlups of rickshaws at the station exits as people get on and off. 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 VC 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 feedback: I preferred the rickshaws. And I resent having to pay. But 3 weeks later: It’s quite good actually.

The Traps

• Launching something that doesn’t provide customer value. The desire to just ship something is strong. Investors and executives are watching, time and budget are tight, and none of the stakeholders can agree on what to launch anyway. Launching stops your head from hurting (briefly) and gives you the impression of progress. But by doing this you’re abdicating control of your product’s destiny. It’s the product team’s job, not the users’, to get a clear vision and to make the difficult design decisions. So take the time to research real customer needs and to foster stakeholder agreement around good design rationale.
• Launching 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.”
• Building what people say they want. 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 innovative ways to give it to them.
• Blowing your chance to get to the good thing, by launching a mangled version and losing investor/executive confidence. 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

So rather than going for a throw it at the wall and see what sticks approach, use a more scientific method.

• Launch the minimum desirable product. It’s hard to find out what that is. But that’s your job. Best to observe and interview users in contextual research or competitor usability testing sessions. Then take the time to do a concept design phase: personas, scenarios, storyboards, and iterative feedback. The design will get more and more complex before, if you stick with it, it will collapse into something simple. Then you’ve got a version 1.0 that’s worth building.
• 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. If people say they want feature X, understand what underlying need has driven that request. But 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.