The challenge has been set, the startup has been formed, and initial release objectives defined. Now what?

How do we get from Zero (a clean slate) to One (first release)? What do we do first? When do we do it? How many people will be needed? And when do we need the funding for it?

In this post, I will outline the four (4) stages of development needed, and the strategy I will be following this year in our new startup, going from Zero to One.

 

Stage 1 of 4 - Pre-Alpha: Architecting the First Release

So, we’ve had the conversations so we know what our startup needs to build. Time to get coding, right?

Nope, this is the part where we stop and think. Zero to One is limited resource, limited funding, time limited work. Squandering any reduces the probability of getting to One successfully. Design and architectural decisions made now need to hold from Zero to One, we do not have the capacity or flexibility to roll back a bad, or worse, missed, decision later.

So spend the time to:

• Design the architecture of the product, paper test it and iterate on it until you cannot find fault with it
• Choose the right tooling and dependencies, these are the building blocks with which you will assemble the product, and you want to be sure that they can and will get you there
• Brutally limit the scope of work, the more you try to squeeze into the Minimum Viable Product (MVP), the less likely you are to achieve it

This stage burns time, uses only the resources you have in the startup (like founders and friends), and costs barely anything. But if you do it right, the next three stages will run to a stable, predictable roadmap, strongly increasing the chances of Zero to One success.

Stage 2 of 4 - Alpha: Proof of Concept a.k.a Working Prototype

Zero to One Startups need funding and to attract talent. The days of investors giving startups money based on a marketing deck and a prayer are over. The days of vendors and counterparties doing business with startups that only have decks are over too.

What a startup needs to do quickly is to tangibly demonstrate its thesis. For a widget, hand-make some, and put them in investor’s hands. For software, build a working prototype that demonstrates one or two critical components of your thesis. Investors, partners and talent alike need something they can touch, see or feel. Working prototypes attract investors and talent and give comfort to partners.

Working prototypes do not need to be pretty, or perfect, or even fully functional. They are there to show two things:

• Your thesis makes sense, it can be seen to work and be capable of solving the problem you set out to achieve
• Your pre-alpha planning made sense, you were able to build a proof of concept that can be grown to Minimum Viable Product

This stage will take less time if you spent the time in Pre-Alpha. One thing to avoid is experimenting here, building a prototype to “throw away”. If you use the architecture and tooling decided in Pre-Alpha and build the scaffold for later stages, you both prove the design and save time in the next stages. And if some of the decisions in Pre-Alpha were not so good, this is the best time to catch and fix them.

Working prototypes can be built with minimal resources, barely any funding, and possibly quite quickly. And if architected properly, the work will be ready for the talent who will take it on in the next stage. Better be looking for them (and signing them up) now.

Stage 3 of 4 - Beta: Minimum Viable Product

With seed funding secured, and talent arriving any day now, it’s time to flesh out the product and complete the initial capability matrix. Start with the working prototype, fill in the blanks and add capabilities until the Pre-Alpha Scope is complete.

Use this time to hand over components to talent as they arrive, to build tests and scenarios to prove the capabilities of the product and to demonstrate to the next round of Investors that your product is viable, complete and making solid progress. Bring in your initial Clients to help them get ready to work with your product. Paper your vendors and start using their data and services.

This stage is all about scaling the team, checking off items on the capability list, and in testing and proving the product. If regulators are involved, or standards compliance needed, this is when you bring them in.

Ideally, this MVP also gets your post-seed first round done.

Stage 4 of 4 - Release: Production MVP

The final stage in Zero to One has a lot of moving parts, but the end goal is to put the product into production and have early adopter Clients start using it for their benefit.

This is the toughest stage, and can take the most time, funding and resources if not planned and executed well. The pressure will be on to “get it out there” and start “earning its keep”. This stage may start with a capable product, but all the shortcuts taken to get to this point now need to be dealt with. The product needs to be polished, made performant and reliable, deployed, documented, supported, integrated with clients, and brutally tested. New personnel need to be trained, business processes tried and tested, questions answered, and everything double-checked.

The big day comes, and I wish I could say it will go smoothly. Even if you have run a rigorous Zero to One build, a certain Professor Murphy and his law always seems to intervene. Networks that worked all though testing may go down, servers may not start, clients may have issues. Plan for this, prepare for this, it’s normal.

Stage 5 of 4 - Post Release: The next big thing?

Okay, I said four stages, yet here is a fifth. Can’t I count?

Congratulations, you have gone from Zero to One, the product is out there, Clients are happy, Investors are happy, the talent is proud of their work, revenue starts to trickle in and the business grows. But promises were made, new capabilities committed to, scope removed that needs to be reintroduced, and everyone wants more. So what’s a team to do but to get on with it.

Nope, this is the part where we take another pause. A short one, but a definite pause to focus on production support and in learning the most common issues, misunderstandings and failures that always occur when Stage 1 plans come face to face with Stage 4 reality. If you do not deal with these now, before you get focussed on the next big capability, they will haunt your startup forever.

Take a pause after initial release to deal with these issues, and to re-examine your roadmap. This roadmap was made way back in Stage 1, lots of time has past, much learning has taken place, and the market and your clients have evolved too. What may have seemed important in Stage 1 may be less so now, and other, newer capabilities may be needed first.

The One will only get you so far. Before you start the One to Two, and to jump the s-curve, take a pause, stop and think again.

More on this in future posts.