Tag Archives: Lean Start-Up

Stopping Starting-up

I love start-up. The early ‘wouldn’t it be great if …’ conversations, the commitment to going on a journey into the unknown, the first days when absolutely nothing is in place and things like name, logo, and website are the focus of endless creative conversation, the first customer, the first hire …

Its a hell of a ride.

There’s a huge amount of start-up advice around for the would-be entrepreneur. May favourites are the writings of Steve Blank and Eric Reis; Customer Development and Lean Startup have more to say about how to go from a vague idea to a functioning startup than any other business approach I’ve seen. There’s an increasing amount of support for start-ups, in the UK at least, from various tax breaks for would-be investors to the well-intentioned but somewhat ill-executed Startup Britain. There’s also a lot of very early stage investment money washing around from Angels and Micro-VCs; let’s face it if you’re going to invest in a hare-brained, high-risk scheme dreamt up by a bunch wide-eyed idealists you’re probably better off taking a punt on someone’s idea for a new type of social network than buying Euro-zone bonds.

Start-ups will save us from the global economic crisis!*

But once you’ve started your startup, you’ve done some customer development, you’ve perhaps pivoted your idea, you’ve reached a core of a product and you have some paying customers, then what? Its time to stop being a start-up and establish your business. Steve Blank calls this phase ‘Company Growth’ in Four Steps to the Epiphany.

In my experience** there are a few things you need to stop being a start-up:

A sustainable business model

On day one of your start-up you are concerned with the necessary detail of the company: what are we called, what do we do, where do we work? On day two you should be out there discovering your customers and understanding your potential market. On day three you should be trying to show those potential customers why they should become actual customers. And so on. You shouldn’t be worrying about sustainability, about what you need to keep being successful in 12-18 months time because unless you focus on finding your customers and your product-market fit you won’t be around in 12-18 months time.

But at some point you’re going to know roughly who your customers are and your product will have demonstrated a reasonable fit with the market. At this point you need to be worrying about sustainability because things like cash-flow, excessive overheads, technical debt and the like might just prove fatal if you don’t deal with them.

A sustainable business model is simply one where the revenue exceeds the cost (and beware hidden cost; many lean start-ups rely on the early joiners living with a reduced or waived salary in return for a stake in the long-term success of the company, which is an inherently unsustainable situation). It doesn’t necessarily have to be by a lot and it doesn’t necessarily have to make month-on-month profits, but it does need to support itself. But whilst it is defined by financial security, sustainability is about more than just about the money: a sustainable company will retain its employees, improve its processes, and learn from its internal influences as well as its external ones.

Less Product-Market Fit, more Market-Product Fit

A good product, one that meets the needs of its customers and has established itself in the market, should start to distort that market, no matter how niche (“Find your niche and dominate it”† was one of the excellent pieces of advice we were given on starting Singletrack). Disproportionately successful products like the iPad and Facebook demonstrate this in extremis; the newly-perceived tablet market is actually an iPad market, many times greater in size than the tablet market ever was, and early social networks simply never imagined the market was as big as Facebook has demonstrated it to be.

But all successful products demonstrate this effect to a degree. The current dominant player in our market does one thing well and many other things poorly (according to their customers we’ve talked to). They have distorted the market to be all about their core strength and we are actively seeking to displace them by redefining that market. Some of their customers will buy into us, some won’t, but we hope that in the next couple of years, when people talk about the market we’re in, the conversation will be much more diverse than it is today.

What I’m not saying is that Customer Development is a short-term process, or that an established company no longer listens to or learns from its customers. What I am saying is that in the early days a lean startup will do almost anything (within boundaries of ability, desire and possibly legality) that customers commit to paying for. But as time goes on you have a lot more data to go on and a lot more experience in your market and there will come a time when leading your customers on a market-defining journey is more valuable to you and them than focusing on fitting your product to the market.

Weaning off the founders

In the early days the founders are the company. As the company grows this effect lessens but it will be quite some time until the company is immune to the loss of some or all of its founders. But that is precisely what an established business needs to be. In the early days people will buy into the founders of the business as much as they buy into the product.

In fact I’d go so far as to say that believing in the founder has far more to do with an early customer making a commitment to buy something that doesn’t actually exist yet as whatever it is the product is portrayed as shortly to be doing.

But as time goes on the founders’ need to replace themselves with others who do the jobs they’ve been doing better than they can. They need to reduce their day-to-day involvement and ensure they are steering the company in the right direction. This doesn’t mean they need to make themselves redundant or irrelevant, just that the company should continue on if and when the founders decide to leave.††

In Conclusion

These are the things I think you need to stop being a start-up and get established. But I’m sure there are more and am interested in other people’s experience. It seems to me that with all the buzz about start-up around at the moment, a good body of experience and knowledge about how to successfully stop being a start-up is going to be increasingly important.

*Actually start-ups won’t save us from the global economic crisis but they might just create a few much-needed jobs, create a bit of excitement and confidence, and instil more entrepreneurial spirit in this country.

** Background: I’ve started three companies. The first never got out of being a start-up and died midway through its second year. The second was modestly successful and is still around after 10 years. The third is currently making the transition from start-up to established business.

† Parker Harris, co-founder of Salesforce.com

†† I’ll know Singletrack is doing okay when the team start telling me to shut up and let them do their jobs. I’m looking forward to that day.

Minimum and Viable

I love Eric Reiss’s concept of a ‘Minimum Viable Product‘ – such an evocative phrase for anyone doing a lean start-up. However, like many evocative phrases it carries the broad concept well but doesn’t stand up to much scrutiny; how minimal is ‘Minimum’ and how workable is ‘Viable’?
There are other phrases knocking around that signpost the same concept. I like Minimum Marketable Feature, often talked about Minimum Usable Implementation when delivering projects rather than product, and Kent Beck recently tweeted:
i’m liking “minimum informative increment” as an alternative to “minimum viable product”
(to which Karl Scotland replied
@KentBeck I wonder whether its more about the learning than the information – “minimum learning increment”?
).
A year into our lean startup I guess I’ve come to the conclusion that minimum viability comes in different flavours and has different purposes for different people.
  • Developers can often learn a lot from doing very little in terms of scoping a new piece of work, understanding a technical challenge, trying out alternative approaches, etc. I’m often amazed that a spike of a couple of hours can tell me much of what I need to know about a piece of work that may take days or weeks to complete. This is the minimum investigation to get viable information about the work required.
  • Product owners and sales people can get a lot of value from doing very little in order to demo a concept or feature to customer or prospective customer. Working on the force.com platform allows us to rapidly show a ‘this will never work for you but at least shows you the idea’ type prototypes and we’ve also started using mocked-up screen shots and wireframes to solicit feedback on our road map and UX ideas. This is the minimum demonstration to get viable feedback.
  • Customers and Users can get a lot of value from a product feature that has had the minimum work done on it to deliver the necessary functionality. The Customer/User can benefit both from getting the feature earlier than they might have done if they waited for the ‘bells and whistles’ version to come along and from being able to provide feedback that helps to ensure they get what they actually need rather than what the product owner or developer things they need. This is the minimum implementation to allow the user to viably achieve their objectives.
  • Start-ups can get huge value from releasing a minimum set of workable features to paying customers. The presence of paying customers goes much further towards validating the business model than legions of people expressing ‘an interest’ and the handing over of money focuses the mind of the customer on giving good feedback far more than any prototype or free trial. Oh, and in any start-up cash is king: getting money through the door enables the business to provide increasingly good service (even if only because the founders get a better night’s sleep). This is the minimum product that allows the business to charge their customers a viable sum of money for which the customers get a viable solution to their needs.
There are pitfalls in all these and the other forms of minimum viability (the minimum viable development team is my current area of consideration) – if you get your spike wrong you can easily find you don’t understand your problem as well as you thought you did when it comes time to implement, and getting customers excited about features that don’t yet exist has many well-known issues – but it is the last two that concern me the most.
In our world the customer is often not the main user of the system (we sell SaaS to businesses and so the customer is usually the COO or the CEO and the users are people who work for them). In one instance the COO saw a very minimal version of a feature and decided it was pretty close to being sufficient for their staff. 10 minutes with the actual users told us that this was far from the case and we had a lot of work to do. In another case we had a working feature that allowed the user to do something but it was just too convoluted a process and our argument that, whilst not perfect, the feature was actually there was met with a blunt “if I have to mess about with it for 10 minutes it might as well not be there”. Fair enough; great feedback and the streamlined version of the feature is in QA as I write.
Those are just examples of where what we or the cheque-writer thought was minimum and viable feature turned out to be anything but. When it comes to releasing a minimum viable product we have an order of magnitude more difficult problem. To some of our customers what we offer is their first truly integrated, domain-specific application so almost anything that works is an improvement over what they’ve had before. But to others who are replacing an existing system their expectation is that our stuff does at least the same and hopefully a great deal more (or else why go through the pain of moving to something new) which really challenges some of the areas of functionality that are more minimal than others.
The more lean and scrappy start-ups succeed, the more the concept of minimum and viable will be understood in subtle as well as broad terms. My own small contribution to the debate is that learning, information, usability, ‘marketability’ and even ‘sellability’ are all great things but are often in tension with each other: if we place too many minimum features or feature sets in front of users that are the wrong side of being viable we may learn a lot but also risk gaining a reputation for delivering crap products that don’t really work. So when we’re talking about Doing the Simplest Thing or what the ‘minimum viable/informative/learning increment/feature/product’ is, its really important for us to understand:
  • Who is the beneficiary of what gets delivered?
  • What do they benefit from (learning, usage, cash through the door, …)?
  • What is the right way to deliver to them (spike, prototype, polished implementation, …)?
  • And, most importantly, what are their expectations? Because what they expect may not match with what we think is good enough for them.
When we’ve got the answers to these questions we find it a lot easier to calibrate what ‘minimum’ and ‘viable’ means for the particular situation.