10 things I’ve learnt about lean startup

By Laurence McCahill, May 1, 2013

This is a transcript of my recent talk at Lean startup Brighton.

In this article I’ll be highlighting the things I’ve learnt from applying lean startup techniques over the last couple of years and how that pans out in reality. In particular the challenges we face integrating lean within an agency environment, with a particular focus on the early stages of a lean startup – customer development.

First, a bit of background…

For those of you that don’t know I’m co-founder of Spook Studio. We’re a startup consultancy and design studio by the sea that helps startups get started. We’ve worked with many startups over the years and have learnt a bit along the way.

We love working with startups as we get to see an idea come to life, plus also we get to work with visionary people that are looking to disrupt the status quo and do something different. Not just dreamers, but dreamers that do.

As well as organising Lean Startup Brighton we also put on a couple of events in London aimed at startups. Lightbulb to Launchis an event for entrepreneurs that are at the idea stage and struggling to take the next step. UX Café is an event aimed at startups that need a little design love. We’re passionate about getting more startups to appreciate the value of good design and so these events help towards this purpose.

So, why go lean I hear you ask?

This is why.

We all want to work on stuff that people value and use. If, like us, you’ve worked on projects that tanked or never saw the light of day, you’ll know only too well it can be quite soul destroying – particularly if you’ve devoted months (or even years in some cases) to it.

Which brings me to the traditional model for product development,waterfall. You can see the risk of using this approach to develop innovative products. The longer you go without releasing the product, the bigger the risk attached to it. Spending 6 months in a dark room developing something isn’t the best way to create startups.

What works much better in most cases is a more agile or leanapproach to releasing. ie. early and often. This helps to mitigate risk and means our focus is on learning and validating, rather than purely developing.

As you can see, waterfall is perfectly adequate for projects where there are no unknowns, but it falls down when either the problem (or solution, or both) are open to questioning.

Agile is great when there’s a defined problem but the solution for solving this is unclear. Have we made the right thing?

Things get a great deal more messy when the problems you’re trying to address themselves are undefined. This is where lean comes in. Does the problem exist and will this thing solve it?

At Mind the Product conference recently Marty Cagan gave a great talk on how to create a product that users love. The above quote sums up his findings from working in Silicon Valley for 30 years. You may hit the bullseye first time but it’s highly unlikely. First you need to validate your ideas before you build them, and if and when you do launch be prepared to iterate until you get it right. It may take 2, it may take 8. But either way it’s a long road to the holy grail for any startup that is product-market fit.

Rather than the waterfall approach of having plan > design > build > launch, lean startup is focused on the cycle of build > measure > learn. The idea being that this is a continuous loop of learning, analysing and developing.

The Lean UX model takes a slightly different approach, a more designed-focused think > make > check. One interesting point is the focus on ‘reducing the cycle time, NOT the build time.’ Lean doesn’t mean fast, but it does mean accelerated learning. At this early stage the focus should be on learning, not building.

Key principles of lean

• Test your assumptions
  First of all, and probably the key principle of lean is to reduce waste. And an easy way to do this is to rigorously test your assumptions. I’ll talk about this more in a sec.

• Focus on customer needs
  Next lean promotes the notion of creating value and this manifests itself in digital products as focusing on user needs. Anything that doesn’t satisfy these can be seen as wasteful.

• Reduce cycle times
  This is key to the lean approach as I’ve mentioned already. And as a result of this we’re making decisions based on actual real world use and data, not guesses.

• Less documenting, more doing
  Another way of reducing waste is to move away from documentation to more doing. Whether a workshop, a prototype, interview, etc lean requires working models to help communicate ideas. Rather than talk in conceptual terms or on paper, show people something. It can be a sketch, a wireframe or a Bootstrapped prototype. Whatever is the cheapest, fastest way to test out your assumptions with users.

• Right action, right time
  Finally another key takeaway is the importance of doing the right thing at the right time. For instance it’s wasteful to do A/B testing before you’ve even validated there’s a need for your product. Focus on what’s important at the time and forget everything else.

So….. onto my lean learnings.

1.RFPs suck! Requirements = hypotheses

First up, RFPs suck. For those that don’t know an RFP is a request for proposal. Generally for an agency this means competing head-to-head with other agencies to pitch for a project. The first stop for this is a proposal. We’ve moved away from these now. As Jeff Gothelf says above, a list of requirements in a brief can be seen as a bunch of guesses. Over the years we’ve found out that what we end up building for a client is often very different to what they actually need. For this reason RFPs are a waste of time for startups or those looking to innovate. Startups are unpredictable so change is something to be expected (and even embraced).

We’ve got around this by hosting workshops with all key stakeholders before we put together any costs. This allows us to get a better understanding of the business and key decision makers, whilst also getting everyone on the same page and appreciating the different opinions that come into play.

By listing out the key problems we’re trying to address, we can re-frame the requirements as hypotheses which need to be validated through talking with the target customers. We’ve found our kickstart workshop a great way to get things moving. Also it helps to build trust between us and the client, allowing us to feel like one team rather than client and supplier.

Which leads me neatly onto my next point.

2.Egos and lean don’t mix well.

Politics, egos, lack of trust can be major issues in any project. We try to mitigate this risk by building up trust early on in a project. Also we got better at weeding out potential troublemaker clients before we engage with them. If we can see that there’s not buy-in from above or we haven’t even got to meet the key decision maker then this rings alarm bells. To be truly lean you need to embrace failure, have full faith in your team and not be worried about who’s right or wrong. Great ideas can come from anywhere. And I don’t just mean egos from your boss or client. Designers can get very protective of their work and lean can often share this load meaning the designer gets less credit as it’s a more collaborative way of working.

For any good designer this is a good thing. The outcomes are more important than who takes the plaudits. Lean encourages the designer to be the facilitator rather than the sole creative brains. If a developer comes up with the killer idea, why not run with it?

3.Context changes tactics

This is something that we really got to grips with over the last few months but we were struggling with why each project we took on ran differently. Lean isn’t a silver bullet and so every project is different. Tactics change depending on the circumstance. There’s no point blindingly following the process rigorously if the constraints you’re working within don’t allow it.

For instance, for a recent project the client needed to have some hi-fidelity design concepts to show their potential first customer (& investor) before we’d really nailed down what the product did. But this was a strategic move that ultimately gave us more leeway further down the line. Often there’ll be time or budget constraints, or a client will want something perfect for the MVP. As long as you communicate that it comes at the cost of increased risk then you’re doing your job. Don’t try and force a process on a project if the constraints don’t allow it. Think of it as a lean toolkit, where you choose the right tools for the job.

4.Balanced teams make better products

One of the reasons we set up Spook many years ago was that we got frustated working at large agencies and companies where there was huge divide between designers, developers and managers. We’ve always worked in small teams with people that have a wide mix of skills. Whilst you don’t have to code if you’re a designer, it sure helps to have an understanding of it. Likewise if you’re a developer, having a good understanding of what makes a good user experience will put you in good stead. Again we don’t want egos or roles, we want great products. And from my experience, this comes from having a balanced team. I get frustrated when I see startups that just have an engineering team and no in-house designers. This may work for some products but in this era, design is becoming more of a competitive advantage and so these guys could be missing a trick.

5.Customer development is hard (and founders should do it)

One of the key components of lean startup is customer development. Finding customers that will use (and hopefully buy!) your product. From my experience the products I’ve seen work best are ones where the founders have been present during early stage customer discovery. Outsourcing customer development is dangerous as you’re detached from your audience and it’s all too easy to ignore feedback. We’ve tried out different ways of engaging clients in this process and we prefer to take an advisory or mentoring role to facilitate this. Once you get the hang of it it can be addictive talking to customers, but at first it can be might scary. Have no fear, get out of the building!

6.Bad news gets worse the longer you leave it

When we’re educating clients about our approach we try and get them to understand the potential risks attached to blindly following a spec and releasing in one hit. As Steve Blank says ‘no business model will survive first contact with its customers’. So at some point you’ll get bad news. Customers may not feel the problem in the way you think they do, they may hate your idea of a solution, or they may be expensive to reach. Eliminate the unknowns early and often so you get bad news sooner. It may be painful but it will save your cash (and energy).

7.Opinions = guesses (and the founder always wins)

Tom Chi from Google was another great speaker at Mind the Product and he described meetings as one big ‘guess-athon’. I think that just about sums up meetings or calls with the client – often it’s just opinions. ‘Should we go with this feature?’, ‘will users like it?’, ‘how many people will pay extra for this?’. Unless you actually learn from your customers any opinion is a best guess. Don’t guess, learn.

8.MVP ≠ Minimum Viable Pants

Partly thanks to Eric Ries, startups think that it’s acceptable to release a crappy version of their product in order to test out their idea. But I think this can be dangerous. Think athelete not a skeleton.

We prefer to have a minimum base level of design and usability across all core features of the MVP to know that it’s not this that’s broken. Also your audience may dictate how crappy your MVP can be. We’ve built a product for the luxury market and we know first hand that a half-baked product won’t cut it for this audience. People use Apple and Steve Jobs as the antithesis of the lean startup, but even they had an MVP for the Apple I. Although minimal it’s still kinda nice and neat. Not quite the iMac but you gotta start somewhere!

9.One metric that matters beats 100 that don’t

Measuring everything and doing nothing is much worse than measuring only one thing and doing something with that data. As Eric Ries says vanity metrics get you nowhere. Who cares how many hits you have if it doesn’t improve the bottom line. Measure what matters, and at first, ignore everything that doesn’t.

10.It ain’t no silver bullet (nor cheap/fast)

Many people in the startup world are (rightly) concerned about lean becoming another Prince 2 or Scrum, with certification and all that comes with it. Just because you know a process, doesn’t mean you’ve got a winning ticket to startup success. Question lean and don’t follow it blindly. Also don’t expect that you’ll spend less cash and realise your vision sooner. All lean does is make you more efficient, reducing waste and accelerating learning. Good judgement, a great team and a little luck are just as important despite what people say.

So in summary, how to get it right:

1. Rip up the spec and host a workshop
2. Get biz, design and tech around the same table
3. Decide on priorities from day 1
4. Work with people you like (that trust you)
5. Kill your ideas before you build them
6. Talk with customers throughout
7. Don’t guess, learn
8. Make your MVP minimum awesome
9. Find your one metric that matters
10. Own the process, don’t let it own you

Online tools for your lean startup:

Some essential startup tools to get you started

Some further reading:

• The Lean Startup by Eric Ries
• Running Lean by Ash Maurya
• Business Model Generation by Alex Ostenwalder
• The Startup Owners Manual by Steve Blank and Bob Dorf
• Lean UX by Jeff Gothelf
• The Lean Entrepreneuer by Brant Cooper and Patrick Vlaskovits

View the full slidedeck from this talk 

Thanks!

STARTUPS ARE HARD
If you need help turning your startup idea into a successful web product, visit www.spookstudio.com or contact me via Twitter @welovelean. I offer a free 20 minute sanity check for startup founders to share and discuss their ideas in confidence via Skype.

Categories: Customer Development, Lean startup, MVP, UX

Tagged: customerdevelopment, lean, leanstartup, leanux, productdevelopment