PlayingLean_02

Can a board game be a Lean Startup?

Before Playing Lean I didn’t have any experience with making, producing and selling a physical product. Creating a board game about the Lean Startup, I had to ask myself: Can a board game be a Lean Startup? Will the lessons I try to teach my software-making clients still apply?

Executive summary: Yes.

When I’m writing this, our second Kickstarter campaign is in progress. It was funded in just 10 hours. This stands in contrast to the first one that ended at 24% and failed. A lot has been learned. I need to write this now to remind myself of that. Afterwards, I may start telling myself that this was a straight line from plan to success.

Here are the three lessons that stand out most clearly right now.

Continue reading

Mot fremtiden med jerndisiplin og fysisk avstraffelse?

Jeg husker den første prisutdelingen med Great Place to Work som vi var med på. Vi var et ungt selskap som akkurat hadde begynt med medarbeiderundersøkelser. Tre av oss dro på banketten, men var helt fri for forventninger.

Det viste seg at vi fikk en flott tredjeplass, og vi måtte selvfølgelig opp på scenen for å ta i mot. “Hvorfor er egentlig Iterate et så bra sted å jobbe”, lød spørsmålet fra konferansieren.

“Øh… vet ikke?” Jeg hadde ikke tenkt på noe godt svar.

gptw-2012

Fra førsteplassen i 2012. Stolte, ja!

I går var vi på prisutdeling og mottok en hyggelig oppmerksomhet for andreplass i kåringen. Igjen kom spørsmålet: “Hvorfor har Iterate vært blandt de beste i 6 år på rad?”

“Jerndisiplin og fysisk avstraffelse”, svarte jeg. For å være morsom, selvfølgelig, men også fordi spørsmålet er vanskelig og svaret er komplisert. Egentlig kan det deles opp i to deler – “hvorfor” og “hvordan”.

På spørsmålet om “hvorfor” hadde egentlig gårsdagens konferansier, Jannik Krohn Falck, deler av svaret i sin egen introduksjon. Han mente at vi er med på å skape en bedre verden gjennom å skape bedre arbeidsplasser.

Jeg vil snu på det. Å skape bedre arbeidsplasser er en nødvendighet for å bevare det vi har bygget i Norge når den store omstillingen kommer. Gode arbeidsplasser handler om å skape en virkelighet hvor alle får sluppet løs sin skaperkraft og innebygde lyst til å bidra. Slik vil vi lykkes med den nyskapningen det er behov for når vi ikke lenger kan leve på inntektene fra Nordsjøen.

Hvordan har vi gjort dette i Iterate?

Jeg tror det aller viktigste er vår felles identitet. Iterate består av en gjeng engasjerte nerder. Vi snakker om ny teknologi og nyskapende forretningsmodeller med samme intensitet som vi diskuterer hva som er god kaffe (nei, det er ikke Nespresso).

Dette krever faglig ydmykhet og nysgjerrighet. Konsulentene i Iterate har spisskompetanse på mange ulikeområder, fra programmering og design til forretningsutvikling og ledelse. Allikevel har det aldri vært greit å være stolt av det man ikke selv kan. Jeg tror ikke et sekund at jeg selv kan gjøre jobben våre konsulenter gjør ute hos kundene, men jeg bruker mye tid på å lære og forstå hva de gjør.

Et annet aspekt er at vi har bygget selskapet sammen og for oss selv. Ikke for kundene. Det er det kanskje ikke lov å si, men jeg tror at et selskap hvor de ansatte trives og utvikler seg til syvende og sist også er den beste leverandøren for våre kunder. Det fører også til at alle føler ansvar og tar tak i ting de mener må forbedres. I Iterate elsker vi initiativ.

Det siste poenget, og kanskje det viktige er at vi har mange møteplasser. Dette er kanskje anderledes i bedrifter hvor alle møtes hver dag, men i Iterate er konsulentene ute hos kunder og i ulike prosjekter i hverdagen. Derfor møtes vi ofte. Hver uke har vi frokostmøte med faglig og sosialt innhold. Hver måned skjer det mye, alt fra konferanser til ølbrygging på kontoret. Hvert år arrangerer store fester og hyggelige turer. Så vi endelig kan lande diskusjonen om hvilken kaffe som er best.

Vår oppskrift på en god arbeidsplass kommer ikke til å være lik din, men den har sannsynligvis ingen elementer av jerndisiplin og fysisk avstraffelse. En god arbeidsplass i 2015 er en arbeidsplass som gir ansatte frihet, mestring og mening. Jo flere slike vi har, jo høyere er sjansen for at Norge kan fortsette å være et “Great Place to Live”.

4 clues on how to leave your job in style

Leaving in style is the best way to start your next job

Leaving in style is the best way to start your next job

“I hereby inform you that I will be resigning my position at…”. An employee is leaving the company. A few decades ago this would be brutal, like a wrecked marriage.

Today, however, few employments are for life. Instead, employers and employees are partners, helping each other to reach the next level. At certain point, it is only natural that you would want to grab that next opportunity.

In 2014, quitting your job is a natural part of how business works.

Don’t get me wrong: I’m not happy to see that our ways are parting. It’s sad, but I’m also proud that your years at our company has left you with the skills and know-how that qualified you for your next mission.

I know you will go on to make other companies great or even start your own some day. Nothing will make me prouder than seeing Iterate alumni as industry leaders in the future.

In the meantime, remember that it’s important to leave with style. Think of the notice period, whether it is two weeks or three months, as your final show.

Here’s how you do it:

Put in an extra effort. Nobody will be surprised if you find it a little harder to keep motivated. If, on the other hand, you use this time to go the extra mile, you will surprise and impress. Is there a better way to be remembered?

Say “we” – and mean “us”. Don’t say “you guys” when you talk about our company. There will be no doubt that your mind has already moved to your next job. Instead, talk about “us”. We will consider you a part of the team until your final day.

Be super social. Take part in everything that happens. Instead of going into hiding, double down on the social side. Friday beers and office parties, you are there, showing us that you really don’t look forwards to leaving this nice crowd. We want you to be there!

Stay in touch. If you hadn’t before, add everyone as connections on LinkedIn and maybe friends on Facebook. Ask for private email addresses, and remember to send a farewell email with your new contact information. As you quit, good colleagues turn into friends and business connections. We should be an important part of your network.

Follow this advice, and you will be remembered as a great employee. Professional, social and loyal to the last. I know our paths will cross again – until then I wish you the best of luck.

A very quick way to A/B-test

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.

Continue reading

Economies of Scala

As a consultancy, we’re always on watch to see what might be the next step forward in the field of software development. I usually find that paying attention to what our developers are playing with provides a good clue.

These days, many of them are toying with Scala, and they are eager to try it out on a project. I have challenged them to come up with compelling business reasons to use Scala on a project, but they have come up short.

I figured I would help them find a good business case for Scala.

For software companies in a tight employment market like the one in Norway, most technical advantages are dwarfed by one concern: Access to good developers. It clearly doesn’t matter what kinds of technical advantages a new language can bring if you can’t hire any developers to work with it. On the flip side, if you can bring great developers to your project, you’re probably in good shape no matter what language you have chosen.

The question, then, is what language should you choose to maximize your access to good programmers?

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.

Developer’s DNA

“The candidates must have at least three years of Java development and experience with four of the following five technologies…”. This is how a typical request for consultants goes, both for public and private sector customers. It clearly favors candidates with long, stable assignments behind them. It seems to be commonly accepted in our industry that the most important quality a developer can bring to a new project is experience. That may not be such a good idea.

The underlying premise here is that training makes you a more effective developer. That may be true, but only to a very small degree.

The problem is that deep tool knowledge is not where the biggest gains are. Software development is just not that trivial.

I have seen teams that have success based on criteria that are different from this kind of experience. A developer with 4 different projects in a 2 year time span take along more good thoughts than one with 5 years of experience with the technology being used. A fresh graduate with nothing to defend often asks those stupid questions that makes the rest stop and think. One who is attending meetups and reading relevant blogs takes along experiences others have gained without having been there himself.

Efficiency is not first and foremost dependant on the speed with which you can code because you have long experience with a specific tool. Efficiency comes with the one who asks if we really need to use the framework we have taken for granted. It comes with the one that had heard of the tool that ends up saving the team for weeks of work. It comes with the one who takes the time to think clearly and simplifies our process and makes everyone more productive. The efficient developer thinks like an innovator.

Development is innovation, and the best developers are innovators. The good news is that you do not have to be among the very creative to think new thoughts. You do not have to be fresh from school to ask the stupid questions, and you do not need experience from many different projects to be able to draw on other people’s knowledge.

Continue reading