Recently I’ve been able to interview several startup founders, ranging from very early stage to actively scaling, bootstrapped to funded. Along with the lessons learned from my own hands-on work with startups, I’ve put together my highlights on key points that could make or break your startup venture.

You’re on to a unique insight and idea. You’re excited about what this might become and if you’re honest, you’re visualising yourself as a successful entrepreneur. That’s great – hold on to this energy and allow it to drive you through the challenges of creating something from scratch!

The danger at this stage comes from only listening to things that validate the picture in your head. If you ignore the questions I raise in this article, it obviously won’t all suddenly come crashing down tomorrow. However, as you chip away at your war chest, neglect of these items may slowly come back to haunt you and potentially end the party before it’s truly begun...

90% of startups fail, so ask yourself this...

Prior to product launch

One - Are you willing to pivot and adapt?

A pivot is when a startup decides to change a major part of its business. In essence, using cheap and fast methods, it’s possible to test the underpinning assumptions of your idea. While a pivot-causing insight may distort the perfectly formed picture in your head, it’s actually really good for you. It’s the reason why you’ll avoid wasting money, time and countless hours on development effort on things that won’t work. The question for you is, what are you actively doing to test the foundations of your startup venture?

Two - How evidence-based are you?

“Most successful founders are driven by impact rather than experience or money.”

Every part of your idea can be tested – the business model, the design of your product, the apparent customer need and so on. It takes a bit of time, but it could make all the difference. One of the most valuable things you can do is to test your product design before you build anything. User testing can be really simple – sit with your target “users”, invite their opinion, their natural behaviour and avoid biasing what you say. This alone can reveal changes large and small that can be the difference between an effective product and a dud. So ask yourself, how much are you testing your assumptions?

Three – What have you done to validate your business model?

In the startup workshops I run, we typically draw out and crunch the numbers on the business model. To date, this exercise has revealed flaws in the model 100% of the time – by this I mean, the numbers just don't add up. Armed with a model that adds up on paper, we can then conduct lean experiments to test the model further with real data. If you don’t know where to begin on this front, ask me about the Customer Factory Model approach – it’s actually a really enjoyable exercise to get things started.

Post-product launch

Four – If this works, how easily and affordably can you hire permanent engineers using your specific technology stack?

A technology stack, also called a solutions stack or a data ecosystem, is a list of all the technology services used to build and run one single application. The social site Facebook, for example, is composed of a combination of coding frameworks and languages including JavaScript, HTML, CSS, PHP, and ReactJS.

It can be very tempting to find the cheapest and swiftest build partner to launch your product. If you don’t have a technical co-founder or advisor, perhaps you don’t even know what to begin looking for. If you do, this question still needs to be asked.

Let’s assume your product shows clear scaling potential at launch. Before long, your ability to scale will in part be determined by your ability to hire a permanent engineering team. How easy and affordable this is will vary considerably according to the technology your product has been built in. To this end, it’s important to have unbiased, future-gazing consultation before you choose your technology foundations. Getting this wrong can force the difficult decision to rebuild your product at the very point that you should be adapting and scaling.

Five – If this almost works, how quickly and affordably can I make changes to adapt the product? How sustainable and scalable is this working relationship?

It’s easy to get excited about a fixed-cost design and build quotation – traditional digital agencies specialise in winning this work. What’s more important for you though, is what happens once the product has launched? Your product won’t be perfect and on a regular basis you’ll need to adapt and improve if you want to scale.

This is tricky, because it’s impossible to predict how much time you’ll need or what exactly you’ll need done. To this end, it’s important that you work with a team that can offer flexible skill sets and response times. If you need to have several meetings and wait for new scope documents to be written for each new product release – this is a warning sign. Most important of all – you need to know for sure you’ll have timely access to the multitude of skills that you may need. If product is at the centre of your business, anything less than the above would be a massive scalability risk.

Six – If this works, will it perform if we suddenly have 1000 users? If not, do I need to rebuild everything?

Especially if you’re working with cheap freelancers or agencies, this is a conversation you need to have early on. There’s a very real risk that they’ve not built a high usage website/app before. While this is understandably not your focus when you have zero users, it’s important to ensure you’re working with engineers who know what it takes to make a digital product perform.

Most likely, you’ll invest in this later – but my advice is to have an expert technology consultant check that your developers of choice know what they’re doing. This means putting good foundations in place to allow you to improve performance as required later and the experience to execute on it when the time comes.

In addition to performance, security is perhaps even more important. The last thing you need is for your nascent product to suffer security breaches early on. Once again, this boils down to good foundations and engineering practice.

Seven – If this works, what if I don’t have the time to drive the high level vision and also attend to the minutiae needs of a growing customer base and imperfect product?

I’ve spoken to several founders who’ve found themselves spinning several plates not long after launching their product; holding back their ability to scale. Once you have a customer base, you become very busy – especially in the early days when many things need to be done manually. To effectively run and scale a business, you now need to free yourself to focus on the big picture – the vision that inspired this whole venture.

In order to avoid drowning, you need a product manager who can oversee a constant design/build/learn/adapt cycle on your product relative to your scaling goals. This means someone who has experience with marketing, product design, user research, analytics – someone who talks to you in plain language about what is happening with your product and why.

This job is often confused with a “project manager” and the two roles couldn’t be more different. What’s more, product managers are not all equal – they have different specialisations and skills sets. All the same, this is what you need if you want to scale.

Eight – If the relationship with my technology partner stops working, what are the time/cost/IP implications and how many alternative choices will I have to avoid re-build?

A bit pessimistic perhaps, but worth thinking through. The main thing here is to check you have good options i.e:

• Have an agreement in place and run through the process of moving before commencing build.
• Be on top of your technology choices – ensure you’re working with technology that is relatively easy to hire for or move to a separate development team if required.
• Ensure not only that the Intellectual Property is yours, but you have access to it. This includes access to code, assets, any accounts setup for analytics, app stores etc.