Ten years ago, I had a printout pinned to a noticeboard in my office of the top 20 reasons why tech startups fail. The number one reason why startups failed was “poor product-market fit”.
If you look at the same list today, you get the same reason at the top – “poor product-market fit”.
Even the other items on the list relate back to “poor product-market fit”. “Run out of money?” Well, maybe you ran out of money before you found product-market fit…
It always has been POOR PRODUCT-MARKET FIT.
It always will be POOR PRODUCT-MARKET FIT.
It is POOR PRODUCT-MARKET FIT.
How then when designing your MVP do you not spaff all of your money on a product that ultimately has poor product-market fit?
Swoosh…
So here’s what we’re going to do:
We’re going to define Product-Market Fit
We’re going to look at how to run your MVP project so that you converge on product-market fit and do this first time
We’re going to look at how pilot projects affect your ability to get your MVP to have good product-market fit.
What is Product-Market Fit
The actual definition of product-market fit is quite dense, but the way that I like to look at it is “does this pass the ‘so what’? test”.
Specifically, if you put the product in front of a customer how do they respond. Do they seem to like the idea, or do they look at it askew with a sort of “…ok… and” attitude. Do they fully channel their internal surly teenager…?
I was actually going to put in the script – “we’ve all seen what it’s like when you see something for sale and it doesn’t pass the ‘so what’ test”, but now I wonder whether this is a survivorship bias thing.
For example, if you go to out to your local shopping centre, anything that you can see for sale in the public domain likely does pass the “so what” test, because in order for a product to be visible to you in the market, product-market fit would have had to have been proven. At least that’s true of large retailers; we’ve likely all seen examples of smaller retail businesses that have popped up and then shuttered quite quickly because what they were selling didn’t make sense.
You might personally not like the new Telsa, or the new iPhone, or the Oppenheimer movie, or that new seasonal coffee they are selling in Costa, but someone is buying them because the companies behind them have proven – to an extent – product-market fit.
In my time working as a CTO for nearly 30 years, I will say that I have seen more bad ideas than good and a lot of founders don’t work through this “so what” issue well enough.
This question can be multidimensional as well – for example you may have a product that the actual end users love and DOES pass the “so what” test for them in that they think it’s cool and like using it, but for some reason it DOES NOT pass the “so what” test for people who actually have to sign off on the thing and buy it. This can happen a lot when selling into large corporates where a product tests well with the user base, but management don’t see the point and don’t want to buy it. There’s an element here of it being important to understand how product-market fit applies to the broader sales journey in more complex sales.
If you’re in a position where your job involves you seeing a lot of ideas go past you like plates on a sushi conveyor, e.g. you’re an investor or someone who works with a lot of very early stage businesses –you can get quite good at intuiting the answer to a “so what” test. It can be very hard though if you are a founder to look at your product dispassionately, because if we have an idea we naturally assume it’s amazing and can get carried away building something that ultimately turns out not to have great product-market fit.
Ultimately finding product market fit is a process of experimentation – which we’ll come onto into the next section, but let’s just bullet out the general shape of what product-market fit is. It is:
User satisfaction – do users actually like using the product. A good metric of this is, “would they tell someone else that it was cool”; another is, “does this become habit forming”, but in a good way, i.e. does it become part of the user’s workflow as a net positive. Net promoter score surveys, or what’s called “instrumentation” within the product (i.e. where the product “phones home” and gives an indication of how it’s being used) can indicate whether user satisfaction is where you want it.
Minimal churn – most technology businesses look to sell things on a monthly-recurring basis (also known as a “MRR basis”). MRR is great for cashflow, but it invites the customer to think each month whether what they are buying has value for them – i.e. each month they get this little reminder to think about the bill, as opposed to in the olden days when you’d have a larger upfront purchase you’d need to make peace with, but could largely forget about the spent thereafter. A high churn rate indicates that the customers are reevaluating the value that they get from your product each month, they’re finding it lacking, and then they’re cancelling their subscriptions. A lower churn indicates better product-market fit.
Minimal competitive pressure – a weird one this, because you never want to be in a market with no competition as it implies there is no market, but what you want is a position where users don’t “jump ship” to competitors because what you have works for them. This is about building an effective “moat” around your offering.
Commercial growth – the best indicator that you have product-market fit is that the business is growing. You’re able to more effectively address more of the market month-by-month, and get people to buy. However, be careful of the tail wagging the dog here. You can have a product that is genuinely great, but have no idea how to sell it so it feels there is no product-market fit, because you cannot access your market. The general rule is that if the product-market fit is good and the marketing tactics guided by a good marketing strategy are applied consistently, you will make sales and see growth.
MVP OUTSOURCING & PRODUCT-MARKET FIT
At this point, you have an idea, and you need to produce a piece of software that implements that idea, whether that’s an app, a website, or a portal.
As a non-technology founder, you are going to have to find someone to build that software. (You’re also going to have to find somewhere between £70k and £100k to pay for it.) This means you’re going to have to find an outsourced software development company to give the work too (I have other videos on my channel about how to do this.)
However, I am on a one-person mission to try and solve a massive problem in the startup community which is that MOST non-technology founders that try out outsource software will fail. Outsourcing software is a specialist activity that to all intents and purposes REQUIRES a technical co-founder or technical senior leader, like a CTO, within the business to manage the outsourced project.
You know how when you watch Grand Designs and the owners try to do the project management themselves and end up being £200k over budget and build the house up-side down, whereas if they’d spend £50k on a project manager, they wouldn’t have wasted £200k and have the house the right-way up. That.
It can be done, but as I say my mission is to teach non-technology founders like YOU in my audience how to outsource software without having that technical input.
The general shape of the problem is that software projects don’t work like other projects. Let’s imagine you want to startup a business that’s– for example -- a drive-through bagel shop. In the real-world this is a simple undertaking. You find some land, you ask an architect to design the building, you get some input about how to set-up the internal and external space, but realistically the parameters are really constrained. There has to be somewhere to park. Cars need to be able to drive around the building to make and collect orders. The staff have to be able to move product around within a kitchen in order to hand the finished goods to people in the store and people at the drive-through. It’s static. It’s contained and constrained by physics.
Software projects do not work like that. All software projects are like trying to build castles in the sky out of fairy dust and wishes just using your mind and the power of positive thinking, because there are no physical constraints. There’s absolute freedom when it comes to building software, which is fantastically freeing and makes it the most amazing thing in the world to do, and software let’s people genuinely change the world, but that lack of constraints makes it a 1000x easier to make ridiculous mistakes, and from those mistakes, build something that no one wants.
To try and tie the analogies together – in the software world, you could build a drive-through where the drive-through lane was 1000 feet up in the sky only accessible to wizards riding flying unicorns, and it would work 100% great if you were a wizard riding a flying unicorn, but perhaps there aren’t enough unicorn-riding wizards in the local area who like bagels to make the business a success.
And pity future version of me who has this afternoon has to find all the B-roll footage of wizards and unicorns to edit into this video…
To ground this a bit more, the problem with commissioning software is that it looks like you are commissioning something like a traditional construction project, but finding product-market fit is an experimental process that cuts against the grain of how traditional construction projects work. Software agencies want the project designed up-front – but you can’t possibly know what you want to build-up front.
This is actually where we get the idea of MVPs from. MVPs come from a book published in 2012 called The Lean Startup. This book has been so successful that it spawned a movement, and now all startup businesses operate on the principles in the book – but to understand the principles, we need to understand the history.
Back in the day, the way that technology businesses would pop into existence is that someone would have an idea, ask a software team to develop it, and that software team would take the stairs into the basement, build some software, not talk to anyone, and emerge blinking into the light 6-9 months later, only to find the customer hated what they had built.
The problem for the new business was that they had then spent all the money and got nothing usable. The developers had had lots of fun however – effectively people were building holiday camps for software developers, which was only good news for software developers.
The Lean Startup approach dictated that more experimentation was required, that rather than disappearing off and not talking to a customer before all the money was spent, you build a bit, show the customer, listen to what they said, build a bit more, show the customer… rinse and repeat.
The MVP approach proposed in The Lean Startup is highly compatible with the need to experiment in order to discover product-market fit, it’s easy to conflate the two principles into the same thing.
Let’s try and work through this as an example.
Software outsourcing agencies exist to AUGMENT EXISTING TEAMS – i.e. they work best when the customer is a technology business with its own software developers and they need a bit of extra resource. What happens with non-technology founders is that they have to use outsourced software agencies as THEIR WHOLE TEAM, which is unnatural to how the agency needs to work, but anyway you better bet they are going to take your money regardless, because they will.
You will go to the agency and tell them you want to build a bagel drive-through, and they will say to you, “OK cool, we’ve built a few drive-throughs before, and we know what we’re going”. They’ll ask you a few questions about what you’re trying to do, and they will come back with a “specification”, which is a design for what will be built, along with a quote. You then pay them the money, and off they go.
There are then two ways in which this can go. You would be quite unlikely to engage a company that was just useless, which I’m defining here as spending all the money, taking all the time, and not coming back with anything at all. Most likely, you will get something that looks like the agreed specification.
Now this is where the problems start. You drive to the site of your new bagel drive-through and it looks amazing. They staff know what they’re doing. The signage is on-point. Everything’s looking really good.
You invite the first few customers and the very first one that turns up says to you, “hey, where can I hitch my unicorn?” And so you look at this wizard in their robes riding a unicorn and realise that the specification has no provision for unicorn parking, and as such there is no space for the customer/wizard to hitch their unicorn. You don’t worry too much, until you see the opening day offer in the local paper has caused a tailback on the A41 because 200 unicorn-riding wizards are all roaming around looking for somewhere to hitch their unicorns before tucking into their tasty smoked salmon and cream cheese everything bagels.
This may seem extreme, but actually having been doing this for nearly 30 years, this is exactly how I would describe the problem of commissioning software for non-technology founders, and how product-market fit eludes founders in their version 1 MVPs.
It’s not possible for you as a founder to know what to build before you commission the work, but the software agency will behave as if it is. If left their own devices, that agency will build to whatever idea you have in your mind.
At this point, you’re going to have to find more money and find some way of converting a chunk of the space used for parking cars into a chunk of space used for parking unicorns.
So how do we fix this?
The answer is to operate the project in a far more experimental manner, and to deliver the work in chunks, whilst having a) a more flexible “specification”, and b) a more flexible way of managing the spend. The irony is is that ALL outsourced agencies CAN do this, but none of them DO DO THIS without explicit guidance and direction from the customer, i.e. you.
Building software is like trying to land a space rocket on an asteroid. You have to keep measuring where you are and where the asteroid is and keep tweaking the heading so that you can neatly land on it, as opposed to just “firing and forgetting” the rocket.
This is why outsourcing works better if you have a technologist within the business – they do this guidance part for you. Part of that is splitting the spend and project up into phases, which allows for a sort of “review-replan-ensue” arrangement. By doing this, you get flexibility as to how the money is deployed, new features can be introduced, and other discovered-to-be-less-important features can be dropped as the project runs. i.e. you get FLEXIBILITY.
Anyway, back to our bagel drive-through. What we want to do is build a bit, and then invite the customer to come down. For example, we might clear the plot and ask the customer to pop down and explain to them how the final thing will work. Now if the customer/wizard says, “OK, where do I hitch my unicorn”, you can now say, “what do you mean, ‘unicorn’?” and you’re able to have that conversation surfacing those REAL customer needs much earlier on.
Once you work out that it’s not just an aberration and it turns out that you’re about to create the perfect bagel restaurant for wizards, and that means unicorn parking now has to be part of your core offer, you can now go back to the outsourcing agency and modify the specification such that the car park is 50% cars and 50% unicorns.
If you do it right, you’re going to be able to land the project within the time constraints and within the budget constraints. But more important, on day one when you open, you’re going to have spent the same amount of money and the same amount of time, but you’ll actually have GOOD PRODUCT-MARKET FIT.
The phrase “beta test” is in common use these days, but did you know that is comes from a much older three-part system of an “alpha test”, “beta test”, and a “gamma test”.
The beta test we understand as the vendor saying, “forgive us any problems that might be in this”, i.e. the user knows the product is a bit shonky.
The gamma test is somewhat tongue-in-cheek, because it refers to an actual release. So it’s a bit of “comedy” there in that the developers are saying, “lol, this might not work”.
The alpha test is this experimental part that we spoke about in the last section.
The way to look at this is that alpha test is that you’re supposed to be in the driving seat, and the customer is watching. The beta test is that the customer is supposed to be in the driving seat, but you’re watching. And the gamma test is where the customer is off on their own, but you might get the odd phone call or text message about an issue.
The beta test comes at a point where we have something that is known as “feature complete”.
In the tech startup world, particular in business-to-business offers, there is this special type of beta test called a “pilot” and they’re sufficiently important for me to make it the “third act” in this video.
The intent of a pilot is that it is transformative, and what you’re testing with the pilot is NOT the product but instead the VALUE that comes from using your product, and you’re going to have to convince someone to shoehorn your – UNFINISHED – product into a real workflow or process that a real customer is using with whoever their end customers are.
This sounds harder than practically it is, because most people are generous with their time and attention, and most people who are good at their jobs, and who are good leaders, are always looking for ways to improve what they do. Most people have scores of people like that in their contact list, and even if they don’t have tons of them, pilot customers are generally not that hard to find.
The principle of a pilot is that you are working hand-in-glove with the customer. In order to pull off a good pilot project, you will need to go somewhat native and really get under the hood of the customer. Working closely with one of your potential customers on a pilot gives you rarified access into how the product is actually being used.
There is a major gotcha in the land of pilot projects however in that although the project let’s you laser focus in on the customer needs, most founders forget that the pilot project will present a bunch of learns.
You will still be pre-revenue when you are doing the pilot, which means that the money you are paying the outsourcing agency to build your product is still coming from your own pocket or your own reserves. What I’ve seen happen WAY too often is that the founder runs a great pilot with their version 1 MVP, but then the work that needs to be done to roll the learns from the pilot into the product – a process required to then get product-market fit – comes at a time when the money has run out.
Think of this like island hopping – you have flown the plane to Pilot Island, but you still need some “fuel” (i.e. money) to hop over to Final Release Island.
One, this is a reason to use one of my favourite video clips (they fully do not look like they can stop this plane!), but two this comes down to sequencing, and ties into the last section about how to need to break up the spend with the outsourcer so that you retain some reactivity in how your complete solution is being delivered.
If you’re asking me how much money you should hold in reserve – it’s a “how long is a piece of string” question, but I don’t like those so I will offer something. It’s not 10%, and it’s not 50%. I would suggest you hold a third back.
For example, if you’ve managed to find £75k to build your first MVP, you might spend £50k on the work to deliver the pilot, but then you have £25k to get to where the pilot project told you that you needed to get to.
SIGNOFF
* TBD