At MISSION+, we work with a lot of founders at various stages of their journeys. Through this process, we have seen patterns that work and behaviours that predict success.

‍

We describe this journey below, and hope it helps guide the weary traveller who is making their way through this long & arduous - but incredibly rewarding - path.

‍

The Beginning

‍

You have an idea. You’re sure it’s a winner, and you can’t wait to start building. Stop.

‍

‍

Have you validated this idea? There is a large amount of work that can be done before starting to code, and ideally before you have committed too much time!

‍

With today’s technology, initial prototypes can (and should) be driven by founders. The prototype doesn’t need to be perfect, but building it will give insight into whether the idea makes sense or not. We’ve previously worked with founders who have realised their vision wasn’t quite as compelling as they thought it would be, once they could see it.

‍

The prototype should focus on areas with the most ambiguity. For example, there is no point building a prototype of a simple onboarding flow - we all know that is possible. The question is will someone find value in the product once they’re onboarded?

‍

A second prototype may be useful, where specialists help elaborate on the initial vision using design thinking workshops, user interviews and higher fidelity mockups.

‍

These mockups or clickable prototypes can then be used to get investors, stakeholder buy-in, or simply to act as a guide for future work.

‍

Importantly, these prototypes should be entirely throwaway. Too often we have seen people try to build a prototype/MVP hybrid; anxious that they’re “wasting” time by building something throwaway, they reason that one might as well build something that can then be reused later if the idea goes ahead. In almost all cases this slows down the process and misaligned objectives.

‍

When the product vision is large - for example a complex enterprise software platform - choosing the areas to prototype can be difficult. Unfortunately, this will be equally true when building the ‘real’ platform, and you don’t want to get into a situation where months of build are required before the product can be used. Find the small pain-point that people will pay for, then iterate out into the complete vision.

‍

Relevant KPIs

Validation Metrics: Number of customers interviewed who identify with the issue, Email sign-ups from a waitlist page.

‍

‍

Ready To Build

‍

OK everyone is aligned on the vision. You’re Ready to Build.

‍

‍

In these early days, clarity of product vision is most important. We sometimes talk to companies that are searching for a Chief Technology Officer, but don’t have a Chief Product Officer. The priorities are backwards.

‍

A great product person with an average tech team has a strong chance of building something useful. A great technology team with a mediocre (or non-existent!) product person will almost certainly build an impressive architecture that doesn’t necessarily solve customer problems. Choose wisely.

‍

Once your tech team is in place (MISSION+ naturally 😉), it’s time to select technologies and begin the architectural design.

‍

In most cases, Choose Boring Technology. Large pools of developer talent along with vibrant communities will typically pay dividends over a niche technology that solves problems in a funky and elegant way, but will need a future migration when the cool kids move on. It pains me to say it, but full-stack JavaScript is hard to argue with.

‍

As the build progresses, we cannot stress enough the need to keep things Uncomfortably Simple. Every release should feel like you could have done more… You’re a little uncomfortable. This is a time of high risk, high reward. Embrace it.

‍

Getting your feedback loops in place as early as possible offers a path out of uncomfortability. As the old joke goes: “First time founders worry about bad feedback. Second time founders worry about lack of feedback.”

‍

A guiding principle I like to share with early stage entrepreneurs: “You’re much more likely to have zero users than too many users.” Frame your decision making accordingly.

‍

Where should you invest? Automated testing & release management is a strong candidate. In these early stages, rapid feature deployment & testing different approaches is key to unlocking product/market fit. The more time spent wasted on prepping releases, the less time spent on building features that customers want.

‍

During this stage, engaging your customers and building feedback loops is everything. Selecting a methodology such as the “Build, Measure, Learn” loop in The Lean Startup can help guide you, although just making sure you’re regularly talking to people is half the battle.

‍

Spending time on future-proofed solutions is probably not the best use of time. For example, we see people try to use digital marketing to expand sales before people are already signing up themselves. Accelerating a process that doesn’t work, doesn’t work. Paul Graham covers this beautifully in Do Things That Don’t Scale.

‍

Performance concerns during these early stages should be a low priority. Regular stress testing will show the true bottlenecks, and beyond that there aren’t many issues at this scale that can’t be “fixed” by throwing a bigger server at the problem. Once you are onboarding users faster than that, someone will give you money to solve that challenge.

‍

Relevant KPIs

User Engagement Metrics: Product Sign-Ups, Deployment Frequency

‍

‍

Time To Scale

‍

Congratulations, you have successfully proven product/market fit. Now what?

‍

‍

As you sign up more customers and generate more revenue, there will be a pressure to onboard more team members to scale capacity. This is where inefficiencies in processes that didn’t previously mean much suddenly matter a lot.

‍

Look at your team as you would any distributed system. Where are the bottlenecks? Where are there synchronous processes that ought to be asynchronous to prevent locking? I recommend literally drawing out the information flows (Thinking In Systems may be useful!), and annotating with notes when things aren’t working out. The answers should soon present themselves.

‍

For the tech team, one of the largest areas of inefficiency will be the human touchpoints between services and systems. When the same people were on both ‘sides’ of a boundary, debugging issues and resolving questions is trivial - it’s the same decision maker or investigator involved for both parties. This is no longer the case.

‍

Instead, observability tools and centralised logging must be put in place so that each team can solve most of their own problems, even if an error is technically on another system. The alternative is raising endless tickets against one another, even in non-production environments. This will grind productivity to a halt.

‍

Interactions with users change in nature. Making data-driven decisions using information captured at scale must become a core activity, so automated product analytic and event tracking tools must become widely adopted.

‍

Now is the time to select and architect a data platform. Prior to this point, there probably weren’t enough data points to really make it worth your while. No longer.  The volume and diversity of your data provides a treasure trove of insights waiting to be unlocked. Even if specific analysis or reporting gets written years in the future, it can only operate on data that has been captured in the past. Don’t waste the opportunity.

‍

Relevant KPIs

Product Performance Metrics: User Growth/Retention (DAU/MAU), Bug Resolution Time

‍

‍

Stabilise

‍

The rocketship of growth may or may not continue, but at least the rate of change has slowed down. Deep breath, time to reassess the platform.

‍

‍

Things become more difficult once you have scaled out, and have thousands or even millions of users. You can no longer move as quickly as you once did. Outages become huge public events, potentially even making the news.

‍

The inclination of some will be to try and prevent risk through inactivity. Hard to break things if you don’t change anything.

‍

Resist this urge.

‍

When we slow down our release cycle, each release becomes proportionally larger. But proportionally larger is disproportionately more complex. The number of potential failure points multiplies. The chance that particular untested scenarios occur increases.

‍

Instead, double down on automation and testing - then release small changes very frequently. Applications & services will multiply, but trying to keep them aligned through a common build & deployment pipeline will make life easier.

‍

But we do need to try and make things more stable. If slowing down releases isn’t the answer, what is? Enter Site Reliability Engineering (SRE) - “what you get when you treat operations as if it’s a software problem”. If you don’t have an SRE function yet, create one. If you do - do they need anything?

‍

Technical Debt is borrowing from our future selves; the problem with debt isn’t the loan principal, it’s the interest payments. If the interest rate is low, that’s a good investment. If the repayment is high, it eats into our hard work. Technical debt has likely been accruing prior to this point. That is likely “A Good Thing” - it allowed us to move quickly, and given we have managed to get this far, it was a good investment. But now is the time to determine areas where the interest rate is highest, and pay down that debt!

‍

Relevant KPIs

Service Quality Metrics: Uptime Statistics, Customer Satisfaction (NPS)

‍

‍

The End

‍

Not the end of The Journey, there is still much to do, and a multitude of new Journeys will have been spun off as new paths from this one. But it is the end of this walk. What have we learned along the way?

‍

We cannot do everything, so choosing where to allocate time and resources is essential. This should lean towards simplicity over ‘purity’ to try and get to profitability (or at least revenue) as soon as possible.

‍

Feedback loops are essential. Knowing that you’re going in the right direction is key to success and minimising waste. I have often heard people say Agile is about “going faster”. It is not. It is about putting feedback loops in place; a steering wheel, not an engine upgrade.

‍

Automation is the investment most worth making relatively early on. Choose to automate the processes that let you launch the most frequently. Rapid, stable releases loosens the shackles that then allows for iteration and feedback loops.

‍

As you grow, thinking in systems & ensuring observability across components is a cheat code towards not getting bogged down in inter-team dependencies and waiting for help from other teams to debug issues.

‍

Technical debt is not necessarily a problem. Interest on that debt is the problem. Hunt out and tackle the highest interest rates, but don’t waste time on elements that are annoying but cheap.

‍

Enough tales for today, now rest. Tomorrow we continue on our mission.