They say the hardest thing about flying is landing. That made me think about the language we use in product development, in particular the product launch metaphor. Can a term like that in itself drive us to do things we don’t want to do?
There flies your better judgement
To recap, a Product Launch is supposed to encompass a number of coordinated efforts, including things like:
- Optimising the technology for heavy loads
- Going big on marketing
- Omnipresence in press and social media, roadshows, exhibitions, etc
- Community building, content curation, customer service
- (and much more)
Ideally, we are well prepared before the product launch. We may have iterated under the radar with “early adopter” customers, but now it’s finally time to create a big bang and become as instantaneously successful as Pokemon Go, with its more than 10 million downloads within the first week of release. Awesome!
Who needs to iterate when we can Pokemon Go for it
It doesn’t have to be this way. In fact, most experienced entrepreneurs would do anything to avoid it. Aiming for a product launch is a beginners mistake, but in the world of entrepreneurship there are a lot of beginners. Why has the all or nothing approach to product release become an ideal so strong that we continue doing it, or pretend to be doing it, despite overwhelming experiences telling us to work differently?
You’d be surprised how much The Martian and Einstein have in common. Except from the fate of Einstein’s brain, which was stolen from his body after he died (it’s a bit macabre, I know). Still preserved, the brain surfaced decades later in a hospital lab, and a brain specialist was asked to analyse it, not knowing who it had belonged to. He was able to deduct two things about the person: 1. He had played the violin. 2. He had an extraordinary capacity for processing terrain and other three-dimensional space. Both turned out to be true: Einstein did play the violin, and his theory of relativity is largely based on multi-dimensional thinking.
Brain plasticity is fascinating. Our brain physically changes based on what we do. Einstein played the violin to relax, and it helped him solve fundamental puzzles of physics. It sounds impressive, but instead of seeing it as two distinct accomplishments (how could he have time to learn the violin?), you should see it as synergy between seemingly disparate activities.
An astronaut doesn’t tell Houston “you have problem”:
The idea behind the Oslo Opera House came after a role switch. When first opened eight years ago, visitors were presented with a fairy tale, allowing everybody to literally walk on top of the glacier-like surface of the building before being lured inside, into an adventurous quest for the “Hall of the Mountain King” (According to Norwegian folklore, The Mountain King normaly resides inside the Dovrefjell mountain range, who’s highest peak – Snøhetta – incidentally has the same name as the architect company that drew the Opera House). It was an iconic building that soon became a part of the identity of Oslo, and the web site still melts down twice a year, when next season’s tickets are out.
It’s a glacier. You’re supposed to walk on top of it
So how did they come up with this idea?
Can 6 tech students help a telecom giant innovate in 6 weeks? Telenor Norway wants to solve real problems for real people. As summer interns in Iterate – the lean startup consultancy in Norway – we’ve been hired to build, measure and learn how to unleash the power of future telco technology. Every week we blog about what we’ve learned.
Here’s week 6.
Our Lean summer has come to an end.
Six weeks ago we were given a task; to help Telenor innovate in different areas. With the rise in popularity and functionality of webRTC, Telenor wanted to know whether or not this technology could help.
Six nervous students preparing for their first day
We didn’t expect this project to be easy, and didn’t expect it to go without issues or problems. We expected guidance, but we also hoped for some freedom to try and fail for ourselves. Mistakes are a great opportunity to learn, but only if we can make and solve them on our own..
Six great friends enjoying a last party together before going their separate ways
They say groups make bad decisions. That’s why we need leadership.
The solution might be a team leader, who makes decisions on behalf of the group: Limit decision power, and decisions will become consistent, on target and effective.
This works great in a number of circumstances. In a restaurant kitchen, for instance, nobody wants chefs who disagree on how long to cook the aspargus. People are hungry – we need a ruler.
Conversely, a ruler is a disaster in innovation. To creative minds, pursuing “the next big thing” (whatever it may be), nothing pacifies more than a micromanaging split- and conquer regime.
Give them a clear objective, a business goal, you might say. “Increase market share by 20% over the next 18 months”. If the goal is realistic, they may reach it. But will it be innovation?
A Lean Startup has three possible outcomes:
- We found a winning product (success)
- We learned our idea was a bad one, and did something else (safe failure)
- We messed up and failed to seize opportunities (big failure)
Thinking like a Lean Startup, we value fast failure, because it teaches us important lessons that in turn can be used to find a winning product. Big failure, however, is when we fail to implement the thinking in the first place. Big failure encompasses anything from never getting getting started in the first place to greenfield innovation initiatives that – usually seen in retrospect – never could have made it, because they were built on the wrong premises.
This post is about avoiding big failure.
I meet a lot of corporate people who want to learn Lean Startup these days. They mostly expect training in experimentation: Business modelling, customer dialog, minimal (viable) product design and other means for validated learning. Build, measure, learn.
The truth is that learning basic skills of Lean Startup isn’t really that hard. Effective use of cheap learning material, from books and tutorials (and even board games) to Meetups and conferences, will get you a long way. Getting mentored by someone who’s done it before may get you even further, but you’re still traveling along one axis of a multi-dimensional challenge. Experimentatiton skills are the hiking shoes you need to climb the mountain (and as far as I know, no hiking shoes have ever climbed a mountain).
And the horrible truth is:
I had this idea that I wanted to develop, but as entrepreneur and Lean Startup practitioner I immediately faced an inner conflict:
If I was to do as I preach, I should on the very first hour begin by exploring the world of potential customers. What I felt like doing, was to start programming. Under excuses like “I’m also doing this to learn a new web framework” and “this is just a hobby project”, I chose the latter. If nothing else, I also decided to pay close attention to my development process and how it evolved. I even promised myself I’d write about it, so here we are.
My customer segment is newbie textbook authors and novelists. I assume they have the following problem: Writing a book is a solitary process. I know this to be true for at least one person in the entire universe.
In other words, like the 37signals guys, I’m solving my own problem. I’m well enough into Lean Startup and entrepreneurial thinking to know I shouldn’t be working like an author – in solitude – so I have a few users in play (and they have already given me valuable feedback).
Apart from learning a new web framework, I’m also realizing something about the Lean Startup: I think I may even have found a silver bullet.
Let me explain.