Lean Startup: Safe failure vs failure

2. July 2015 — Leave a comment

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:

A very quick way to A/B-test

30. April 2014 — Leave a comment

In discussions about A/B testing, everyone usually agrees that it is a good thing. To get started, however, somebody must first have the time and the resources to build the A/B test rig. It will take weeks, and will probably involve some interesting big data technology. Also, it usually never gets priority enough to actually get done.

5 MAGISKE LYKKEFORMLER FOR BUSINESS DEVELOPMENT

19. February 2014 — Leave a comment

Lykkes du – så del med andre hva du har lært. Deler du, så lærer du og det tror jeg er en god formel!

Her er fem ting jeg har lært om forretningsutvikling i store organisasjoner:

#1. Finne flere personer som vil det samme:

Det er viktig å finne engasjement på mange nivåer som vil det samme. Du trenger støtte på høyeste hold, på ledernivå og 2-3 operative som motor. Dvs. at man må ha 5-6 personer som finner ut av at dette skal skje og bli enige om dette.

#2. Skille ut fra eksisterende tankesett og beskytte mot makta som rår:

Hovedargumentet for å skille ut er å beskytte funding og passe på at ressurser ikke dras i flere retninger.

Schibsted har mange gode eksempler på dette, eks. vis VG når de skulle «vinne» kampen på mobil, startet de et eget AS. I 2013 tok de det inn igjen siden mobil nå er blitt en så stor del og kan måle seg med avis delen. De skilte nylig ut VGTV og kommer til å føre det tilbake igjen når det er oppe å går.

Nokia kjører et super hemmelig prosjekt som skal rette opp skuta. Norsk sjef. De er skilt ut som et eget miljø, med egne budsjetter og med topplederstøtte gjennom at Elop og noen andre VP sitter direkte i styringsgruppen. De stiller nær sakt aldri i møter, men alle vet at de bare er en telefon unna om noen prøver seg på å stjele funding eller trekke ut ressurser.

#3. Utholdenhet og utålmodighet, på en gang!

Det er utrolig vanskelig å lykkes med nye ting!

Hva skjer om man er utholdende uten å være utålmodig? Jo, mange titalls, kansje hundre millioner kan være bruket før noen setter ned foten.

Det å finne beslutningstakere og «stake holders» som har akkurat den perfekte balansen mellom utholdende og utålmodig er sjeldent. Finner du en så hold godt fast i denne/disse!

Å finne miljøer som klarer å komme frem med «udødelige» ideer. Dvs, på tross av alle som prøver å rive ned, hindre, utsette osv. så klarer miljøet å sjonglere stake holders, produktet, marked og penger på en unik måte. Disse personen vet at om de feiler på bare en, så faller alt.

#4: 3D forståelse av terrenget du er i

20140206091024

I en 2D verden trer man inn i et terreng hvor du bare ser det som er rett fremfor deg. Du ser et produkt, en tjeneste eller en forretningsmodell, men du ser egentlig ikke så godt hva kunden egentlig prøver å få gjort, hvordan endrer dette vår posisjon i markedet, hvordan kan vi gi kunden mer verdi?

Hvorfor har droner tatt over krigsmarkene? Jo, de sparer potensielt krigerens eget liv, men det er noe mer her.

De gir beslutningstakerne en 3D forståelse av situasjonen, hva som er under oppseiling og ikke minst: Hva betyr det av endringer i planen!

Jeg mener man kan oppnå dette 3D bildet gjennom å bruke flere personer med ulik bakgrunn og erfaringer som sammen diskuterer og lager planer innen et gitt området. Disse må relativt raskt kunne settes ut «live» gjennom simulering og testing i terrenget – på ekte kunder. Gjennom dette kan du som tilegne deg denne evnen til å forstå ditt marked i 3D.

#5. Kontroll på NÅR

Kanskje det vanskeligste.

Når brenner det akkurat passe under beina på «stake holders»?
Når er markedet klart for noe nytt?
Når passer det for intraprenøren å ta egen risiko (kan jo miste jobben/posisjonen)?
Når har org nok selvtillit (det har jo vært noen fiaskoer i historien bak)?
Tror du lett kan finne 20 viktige NÅR faktorer og de skal alle stemme…..det er sjeldent, temmelig sjeldent, dessverre.

Deler du så lærer du og det tror jeg er en god formel!

Torve

Agile Nearshoring with Yogurt!

30. April 2013 — Leave a comment

At a recent beerstorming (*), we discussed how to make nearshoring of software development work. Funny enough, the smooth taste of Yogurt entered the picture.

(*) Beerstorm is a fun-name invention for a practice came out of experimentations; it has very good effects on my spirit, it literally drags me into the zone…

A primer on Yogurt cultures!

Yogurt brewing, when done the natural way, is a fascinating process. A perfect example of nurturing a self-reproducing organism. The bacteria used to make yogurt is known as “yogurt cultures”. Fermentation of lactose by these bacteria produces lactic acid, which acts on milk protein to give yogurt the characteristic texture we love.

Know your feedback loop – why and how to optimize it

1. October 2012 — 2 Comments

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:
Continue reading

What seems to be the Problem, Solution?

10. September 2012 — Leave a comment

Like so many others, you’re ready to start practicing Lean Startup and Customer Development. You’re about to start working on a new product or feature, so the timing is perfect. You sit down with a Lean Canvas and start filling it in. However, if you are like most of us, you will quickly come across the following obstacle:

You have already gone ahead and designed a Solution in detail. You’re also quite sure that it is good. Why go through all that work if you already know what to build?

The quick answer is that you may have built a Solution, but not a Business Model. You have to take one step back: Is there actually a Problem out there that my Solution is the answer to? Is the Problem important enough for Customers to pay for having it solved?

You can and should do Problem Interviews with potential customers even though you have a specific Solution in mind. First of all, it might inform you and enable you to make your Solution better. Having figured out the most pressing Problems will help you build a better Unique Value Proposition and thus improve the chance for success in the marketplace. Finally, if you figure out that your envisioned Solution does not solve any important Problem, you will have saved a lot of money.

Reverse-engineering a Problem from a Solution is quite possible. You have to get out there and do Problem Interviews, but you have to follow a few simple rules to succeed:

1) Don’t go out looking for confirmation. If that’s what you do, you will find it. Keep an open mind and do what you can to keep your hypothesis falsifiable and your interview scripts unbiased. The input you get will be very valuable when you decide to go ahead and build your product.

2) Listen to the customer, but don’t ask for advice. It’s very easy to show your Customer a demo of your Solution and ask him what he thinks. Pure politeness will require him to be positive about whatever you put in front of him. Find ways to test your hypothesis without leading the Customer to a given conclusion.

3) Get out of your own circles quickly. Interviewing friends and family is a nice way to get started and to iron out issues with your interview script. But they are not unbiased enough to build your conclusions on, and they are not likely to represent your Customer Segments well. If they have ideas for more people to interview, though, you will quickly be heading out of your closest circles.

4) Don’t give up too fast. Problem interviews can be discouraging when your Problems don’t resonate with the first Customers interviewed. However, your problem doesn’t have to be must-have for everyone. When you dig deeper you might be able to find a Customer Segment that feels your Problem more than others, and who really has the need for your Solution. They will serve as your Early Adopters and help you build your product.

That’s it. Put your Solution aside for the time being, and start testing to see if you have a Problem worth solving.

You’re Writing the Wrong Software – You Never Know What Users Want Until You Ask Them

12. August 2012 — Leave a comment

Too often companies and IT departments believe that they know what software they should create. However users often need and want something different than you believe, even if you’re a domain expert yourself. My colleague and dear friend Ivar had exactly this experience when designing a meal planning tool for his girlfriend and himself. He knew everything perfectly – the previous tool they’ve used (a paper on the fridge), the problem domain, the users. Yet the first prototype tested did not at all match the ideas of what he thought was needed.