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.
If you always write perfect code, know how to predict the future and don’t care how your money is spent, you don’t need to read this. The rest of you need to know this stuff.
What is a feedback loop?
A feedback loop is the path your assumptions travel before they are validated or invalidated. Naturally you will have different feedback loops for different assumptions. In this post we will discuss three levels of feedback loops that should be easily recognizable. They are:
Siste uken her har vært litt hektisk, litt slapp, og veldig moro. Vi har blitt intervjuet av Computer World, hatt medarbeidersamtaler, fortsatt med brukerintervjuer og mye god feedback, i tillegg til et veldig hyggelig Skype-møte med Kent Beck. Computer World-artikkelen kom ut allerede på torsdagen, noe vi syntes var veldig stas.
Etter publiseringen av applikasjonen på Google Play Store begynte vi umiddelbart med bug-fiksing. Når vi lastet opp Strandfunn var vi klar over flere feil og mangler, men vi prøvde å være strenge mot oss selv, og få den publisert så fort som mulig. Vi fulgte de vise ordene “Man skal være litt flau når man gir ut app’en”. Idet applikasjonen var live, og man kunne kjøpe den, fikk vi ekstra motivasjon til å polere applikasjonen og gjøre den bedre. Det tok ikke lang tid før vi fikk tilbakemeldinger på feil og mangler, og da var det bare å hive seg rundt, fikse feilene, og laste opp en ny versjon så fort som råd var. Alt dette ville antakeligvis ikke blitt tatt hånd om så raskt som det ble, hvis den ikke hadde vært ute og tilgjengelig for salg på et tidlig stadie.
Etter to uker med effektiv jobbing kan vi med glede annonsere at applikasjonen vår nå er på Google Play Store! Applikasjonen vår, som nå er døpt Strandfunn, kan lastes ned fra Play Store til en rimelig lanseringspris.
I disse to ukene har vi parallellt med programmeringen holdt intervjuer, hvor vi har vist frem nye iterasjoner av design og funksjonalitet. Dette har gitt oss raske tilbakemeldinger slik at vi har kunnet tilpasse oss raskt det brukere ønsker, og få bekreftet antagelser vi gjorde angående utseende og funksjonalitet. Et eksempel på hvordan tilbakemeldinger har vært verdifulle, er hvordan filtreringsfunksjonen i applikasjonen ikke var intuitiv nok. Vi begynte med et søkefelt hvor brukeren skrev inn egenskaper som stranden skulle ha (såkalte tags). Når brukeren begynte å skrive ville applikasjonen foreslå forhåndsbestemte tags som passet opp mot det som ble skrevet inn. Dette viste seg fort å ikke være intuitivt, da brukeren i de fleste tilfeller ikke la merke til søkefeltet i det hele tatt. De som la merke til søkefeltet prøvde å søke på samme måte som man bruker en vanlig søkemotor som for eksempel Google og ble forvirret når de ikke fikk noen treff på sine egendefinerte søkesetninger.