Lean Startup as an invisible hand

Torve Indahl on Please share your opinion on what prevents lean startups in enterprise

invisible-hand

Business cases are in most large corp the key follow-up tool to measure your projects success and growth. When business managers do the traditional thinking and “lock” the business case at the project starting point, they then also lock or restrain the projects ability to learn and change. Eg. working with a norwegian telecom post acquisition for my 2006 startup in 2008, we where following the telecom´s 1 year old pre-acquisition business case and followed that path for 4 years. The company does not exist today. Many factors played in, yes, but fore sure the set path was one.

Working with lean startup for large and SME on a daily basis and as an MSc in Business, I frequently us this mindset (lean Startup) as an invisible hand. We don´t explain everything, we just use it. We change the business cases at every board/steering group meetings and wait for them to start asking questions about way there are all this changes. We are proud then to look them right in the eye and tell them “Sorry, we were wrong the last time“. We then show them the evidence from our market experiments on why we where wrong and let them in on the discussions on what to do next. Now you suddenly are on the road of trustchanges is expected and the board executives starts digging into if we are doing enough experiments….”what about the MVP then” (yes, they start using your words).

The best part is when our “success formula for new stuff” then becomes demand. Life is good

5 MAGISKE LYKKEFORMLER FOR BUSINESS DEVELOPMENT

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

Done in 18 bananas

Even though the word consult comes from Latin and French and has nothing to do with it, giving estimates feels closer to conning than advising.

Naturally we feel bad about this, we do not want to feel like con-artists. We want to feel like we are helping and in response to the embarrassing emotion of guilt, we banish the problem to another realm where we do not have to take responsibility for the inevitable estimate gone awry. It really is a pretty clever way of making ourselves feel better about the estimates that we give. You may break out your inner maniac’s laughter now. Go on, you know you want to, it is all right; for you are in the company of maniacs.

This rite of banishment is performed through the powerful, almighty word; oft used and abused, terms like rough estimates, story points, units of work, or anything that is not a direct reference to Time, are thrown around. Time becomes the elephant in the room, everyone is thinking about it, yet no one is addressing it. What context does this deep need of maintaining wiggle-room remind us of … ah, yes. The art of conning and the obsession with never giving absolute answers. Or, in the words of Bruce Lee, “Be like water, my friend”.

Surely every developer has had a discussion about what e.g. a story point actually represents. This is the bed we have made. Far too much effort has been put into creating abstractions in order to give the perception of more accurate estimates of length. That sounds like a paradox in itself; we make something abstract, Time, and make it more abstract, Points, in order to talk about it as absolute.

file3111258685095

-“Huh?”

That discussion about what the estimate means is a metaphorical train running full-tilt which if you get in front of, or find yourself in front of, you will have a Bad Time™. Eventually though, what happens is that everyone just kind of stops talking about it, externally accepting that it represents nothing.

Internally however, the conflict rages on. Every time the question, “How long will this take?”, is raised, an attempt to estimate length through conversion of abstract terms into some-what more concrete terms is made. This can lead to near Olympic-level mental acrobatics, which while impressive, is completely useless when pressured for an explanation on how the estimate was arrived at.

Especially a few weeks down the line, when the explanation of the acrobatics makes no sense at all because one or more factors changed between then and now. Much like dodging a bullet you have made an assumption about being fired in the future but never was.

Maybe we should strive to be plasma instead, existing in a state neither fluid nor solid. Flexible estimates? Fixed estimates? Pshaw. Plasma estimates!

Though if history has taught us anything, it is that just changing the terminology will not work in the long haul and this fanatical devotion to avoiding Time as a unit for measuring duration is actually more harmful than helpful. The nature of an estimate is that of a guess, so instead of making us better at guessing, which we have been trying for a while now, perhaps we should not make important plans based on guesses at all.

Consider this. Someone asks you how long it will take to drive to Paris from Oslo by car. You think about it for a while. You study a map. You create a mental model of the problem and apply your own unique problem-solving framework on the model and prepare your solution.

You are now ready to present them with your estimate on the trip’s duration, and so, you look them in the eye and say,

-“18 bananas.”.

/v.

Idle your product owner

As a first step towards dealing with an over-loaded development team, we showed an organization how to visualize their work by representing work items with Post-its on the wall, flowing from to-do, to in progress, testing and doneThe organization quickly catched the idea, and soon priorities were respected, deliveries became more predictable, and developers had a process to improve.

Which is what they did, and after some time we saw a new work pattern emerge:

  1. A product owner identifies a need and wants a designer to work on the details
  2. The designer grabs the task and sketches out a solution
  3. Developer tasks can now be defined, and they go into a special planning column, which gradually started to increase in size

Things are finally happening

Although tasks are completed at this point, the need is still not solved. Nevertheless, the message becomes: “Hold on tight everyone, things are finally happening now,” and while waiting for it, the product owner may start working on even more needs, which creates even more work for the designers, and subsequently even more tasks for the developers.

Which is what they did.

Continue reading

Agile Nearshoring with Yogurt!

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.

Continue reading

Know your feedback loop – why and how to optimize it

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?

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.