MVP Outsourcing Failures
Non-technology founders usually need to outsource the development of their v1 most valuable product (MVP), but as a CTO with 30-years experience of supporting people start and scale technology businesses, outsourcing software agencies will normally f* your startup.
It’s incredibly difficult to outsource software as a non-technology person, and at the early stage of your business where the money you’re using is what we call “non-institution”, i.e. it’s coming from your savings or friends, family or followers, you need to make sure you’re not just setting fire to your money.
In this video I’m going to teach you some skills that will make it way more likely you’ll have the green shoots of a business at the end of your MVP outsourcing project, rather than an amusing story to tell the grandkids.
OK – here’s what we’re going to go through in this video…
Prelude – we’re going to have a look at a story from my own personal life that will frame the discussion. Don’t worry, unlike most of the stories from my personal life, this one will be interesting story,
Useless vendor – we’re going dig into the issue of being unlucky enough to choose a vendor that is simply incompetent (which in fairness is the less likely outcome),
Building the wrong thing – a much more likely outcome is that you end up choosing a good vendor, but they end up building the wrong thing.
Let’s get on with it…
PRELUDE
Let me tell you a story that, to be honest, I’d forgotten about until I thinking about the script for this video.
Years ago I bought a flat, and it was off-plan, i.e. it hadn’t been built yet. One day I get an email from the project manager that says that he’s “very sorry but the structure engineer has found a problem”. Basically they had done the roof loading calculations wrong and unless they added some structural steel into – I dunno – somewhere in the roof, the building would collapse.
He said he was very sorry and he said that it would add about two weeks to the move in date, but they’d absorb the cost.
Now that’s REALLY like having a technology co-founder or a CTO (chief technology officer) within your business. How much did that construction company pay for that structural engineer. If that person was a consultant, that work maybe cost them £400; employed, maybe £200. And just that one insight saved that project from catastrophic failure.
The remedial work can’t have been that expensive either or I would have been “invited” to pick up some of that cost.
And you can imagine how it happened, e.g. the engineer might have bene lying in bed and juuuuuust as they were nodding off, suddenly the had this “WAIT A MINUTE!” moment where their unconscious competence popped up an awareness that something was wrong, and they were now in that mode where they HAD to find out what was wrong, and voila, they did.
That’s the sort of insight that you need to have within your business. Getting support from competent people who are going to have those “WAIT A MINUTE!” moments is incredibly valuable.
That’s precisely what you get when you have a technical co-founder or a CTO within the business. They are the people that a) know how to build a roof such that the entire building won’t collapse two days after the works completed, or b) are able to spot mistakes on the horizon and give you and the rest of the team a chance to fix it.
But, if you’re seeing this video, the YouTube algorithm is such that I can assume you probably don’t have a technical person within the business. But that’s cool, because I do content to help people who don’t have a technical person within the business. And it can be done – you don’t need the PERSON, but you do need the SKILLS. If you want to outsource your MVP development without facing the risk of failure that’s the gap we need to close. We need to get you to know how to find the skills externally, and help you leverage them.
Before we crack on, if you still trying to find a software agency to build your MVP, check out this video (also in the description), as in it I go through how to shortlist and select an MVP.
SWOOSH 1 Incompetent Vendor
Putting this video in two parts let’s us look at two types of risk – the first is that you choose a vendor that straightforwardly can’t do the job. This is the equivalent of choosing a “cowboy builder” to build an extension on your house – you just got unlucky.
To define the term “incompetent vendor” – this is a vendor where regardless of how good you are at describing the project, the work they do is just substandard.
Happily though, it’s actually quite rare to choose an incompetent vendor, because much like in the 1980s where it was possible to buy a “bad car” and now all cars are built to similar high quality, these days it’s quite unusual for vendors to be bad.
The problem as a non-technology founder though is that because you’re new to the activity of commissioning software, the warning signs that the vendor is just straightforwardly useless are quite opaque.
What you need to do is rely on someone else qualifying the vendor for you – i.e. you should be relying on a recommendation from someone that you trust. This will remove the cowboys from the scenario. If you don’t have or can’t find a recommendation from your direct network, you would do best to socialise the request on LinkedIn via your second-degree network.
I would definitely not try and find someone directly. Using Google, or relying on an approach from a cold email or a LinkedIn direct message, I would not touch with a ten-foot pole.
SWOOSH 2 Building the Wrong Thing
There’s a 20% risk that you choose a vendor that’s straightforwardly incompetent. But if you ask for a personal recommendation, I would say that’s pretty easy to avoid. 80% of the risk then sits is getting the agency to build the right thing.
How do you do that? Let’s break it down:
Know the philosophy of how agencies work,
Know how to specify your project,
Know how to oversee a project,
Know how to test and evaluate outputs,
BONUS: Know how to sequence a pilot project.
SWOOSH 2a How agencies work
From my perspective of someone who has been building software for 30 years, software agencies operate in a very strange way.
The first issue is that software agencies exist to augment existing software teams, not to be a business’ only software team. This means that your engagement with them as a non-technology founder cuts against the grain of how they are supposed to work as you don’t have any technology team to augment – by default, they operate as your whole software team.
Coming back to my example about the structural engineer, in that we need we need those technology insights and skills but you don’t have a person to put those in, you have to find them elsewhere, you have a challenge here in that you need to get the agency to provide those skills for you. In my experience, agencies will do this, but they have a bit of a habit of getting carried away and taking over – because they can smell your money and agencies like clients that can keep spending with them.
Specifically, your outsourcing agency should be a DELIVERY PARTNER, not a TECHNOLOGY PARTNER. The distinction is that you are building a TECHNOLOGY BUSINESS and you don’t need a TECHNOLOGY PARTNER because you are one. It’s the equivalent to cloning and marrying yourself, any partner you do have should be complementary to your skills.
The way you do this is that you need to frame their engagement with you as ADVISORY rather than EXECUTIONARY, i.e. you need to get to a position where you know you can trust them to give them you good advice, but that you still make the decisions.
This means that over time, your objective is to wean yourself off of using agencies completely. As a technology business, you will need an in-house team, which means that when you get to a point that when you are scaling-up the business as opposed to starting-up the business, you will have your own developers.
The second issue with agencies is that they “operate on rails”, by which I mean “they will only build what you tell them to build”. This makes sense if you consider that they get paid purely on outputs. Your project with them will likely have a fixed cost, and if they have to do more work than they budgeted for, they make less profit.
The reason why the software engineer part of me finds this strange is that if you imagine yourself five-years time when you do have that in-house team of software developers, in-house teams tend not to be so concerned with how much things cost to build. This can cause its own problems, but what it means is that they tend to do the right thing, rather than the purely profitable thing.
Practically this translates to a higher level of adaptability of application.
This sounds a bit academic, but it’s actually really important and is a very common way in which non-technology founders get screwed by agencies, albeit not deliberately. It’s just a function of how agencies work.
Imagine you have two parallel universes, one where you have some money to build an MVP and use an outsourced team, and another with the same amount of money to build the same MVP, but this time with an in-house team. You present both teams with an objective, which is that not only do you have an idea, but you have a potential customer who’s willing to operate a pilot project.
The problem with pilot rollouts – which we’ll come onto in a moment – is that people tend to forget that there will be “learns” that come out from a pilot project, i.e. the project will prove some product-market fit, but you’ll need to do more work to close in on a more optimal-product market fit.
The first universe where you are using an outsourced agency will build you a piece of software that will do just what the pilot project needs, but most likely that output will be quite “brittle” and you’ll struggle to modify the outputs to apply the learns from the pilot project. This happens because agencies are motivated to build to optimise profit, and it usually follows that as you add flexibility, you reduce profit.
The second universe where you use your own team, the output will likely be much more flexible because in-house teams build to optimise longevity, and when it comes to software longevity is achieved by adding adaptability, and from there you can make that software more flexible.
So in the second universe example, you are more able to take the learns from the pilot project and take those into the next version of the product. This is a good thing.
To square this circle, what you need to do is – as we were saying before – use the agency to give you advice around how to make the product more flexible and try and tease them away from a mentality where they operate on rails. Just be a cautious though because what you don’t want them to do is add so much flexibility that they just double the cost and give you something overly flexible. You want to get to a middle ground.
SWOOSH 2b Specifying Software
Just give me a moment as I need to stop myself from getting triggered by the trauma of trying to get people who don’t want to write specifications to write specifications.
People hate writing specifications. But the truth is that the better the specification that you can write, the less money you will waste. Let me explain.
In all software projects, a percentage of the money that you spend is wasted. By waste, what I mean is that you pay someone to write a piece of the software – some lines of code – but those lines don’t make it into a final useable product, i.e. some work is done and paid for, but it’s wasted because it delivered no value to the business.
The better your team is at writing software, the smaller the percentage of waste. You’re never going to hit 0% waste, but 1%, 2% waste is fantastic.
How waste works when it comes to the agency is that there’s some internal waste, and some external waste. So they too not cannot hit 100% efficiency in the work they do internally, and you have no control over that but they bake that into the cost – but the external waste is the bit that you have control over. For example, you might be designing your pilot project, misunderstand what the customer wants, ask the agency to build it, they do build it, and you give it to the customer and they say, “eh? What’s that?” That’s external waste, and that’s the bit that you have absolute control over.
And the way you control external waste is to be better at writing specifications.
Writing specifications is a big topic, look for other videos on my channel about how to get better at writing them, but let’s do a quick run-through.
The first thing about writing specifications is that you actually need to do it. It’s like going to the gym, or sticking to a diet, you have to turn up to do the work. The temptation, just like it’s easier to buy a nice cake from Sainsbury’s and sit down in front of Judge Judy all afternoon as opposed to driving to the gym and whaling on your pecs, is that you rely on the agency to write the specification. This is never a good idea because you need to be in CONTROL of the project. Again, you are trying to make the agency a DELIVERY PARTNER, not a TECHNOLOGY PARTNER, and this means you need to be in the driving seat, and the person writing the specification is the person in the driving seat. Don’t be a passenger princess.
You can’t really skip this step. But people do, and it leads to crappy results.
The second thing about writing specifications is to err towards keeping the language more clipped and structured, as opposed to prosaic. Most of us in business settings are taught to write in a way that is quite dense – formal business writing in the form of reports creates something that requires a good deal of concentration to go through. If you write a software specification in that style, people get bored.
There are two tricks where you can draft your specification so that its more readable and comprehensible, even though it is likely to be quite a boring body of work whatever you do. No one is going to the WHSmiths at Heathrow and picking up a copy of your software specification for entertainment on a long flight.
The first is that imagine you are writing for a social media post, rather than a report. Because everyone online skim reads, social posts that get read and get engagement tend to be single short sentences, one per line. The second trick is to use the MUST, COULD, SHOULD rule, which is where you ensure that each short sentence has one of those words in it, ideally capitalised.
Here's an example of a very short part of a specification, which is written in a prosaic/narrative style:
“Once the user has logged in. They can see a list of plots within the building site. They can select the plot that they are interested in, and then select ‘Add Snag’ to add a new snag. A new screen appears that allows the user to take photos of the issue, and add a description. It’s not necessarily to take any photos, but it is necessary to add a description”
And here’s an example of the same specification, written as short sentences with MUST/COULD/SHOULD:
“The user MUST be able to see a list of plots within the building site.
The user MUST be able to select a plot. WHEN they have selected a plot, they MUST be able to choose an option marked “Add Snag”.
WHEN the user selects “Add Snag”, they MUST be presented with a new screen.
The user MUST add a description of the fault.
The user SHOULD be able to upload photos of the issue.
The user MUST be able to select an option to save the snag to the database.”
The purpose of writing in this way is that it removes ambiguity. It so happens, if you’ve never written software before, it’s closely aligned with HOW the software itself is constructed. This means it’s VERY easy for a software developer to look at this and know how to build to these requirements. All the questions they would have are in there – for example it’s really clear about whether photos are REQUIRED or NOT. That requirement happens to be in the first, narrative specification as well, but it’s easier to find and comprehend in the second draft.
Once you know how to write a specification like that, it’s just an issue of making sure you have complete coverage of the product you are trying to build. Happily, this should work out because the agency will not be able to quote without having a proper specification.
(Although a gotcha here is that agencies do quote without a proper specification, which is a surefire way of ensuring that one, the other, or both of you do get burnt because the quote will be too low and will require heroic efforts to fix. Don’t accept a quote from a supplier unless it’s against a fully fleshed-out specification.)
SWOOSH 2c Know how to oversee a project
You’ll know by now that I’m keen to labour this point that your agency should be a DELIVERY PARTNER not a TECHNOLOGY PARTNER, and part of this is the oversight part.
The agency should be doing the project management of the project – that bit certainly is a core part of the service that you are paying for, but you need to oversee it. It’s not that you shouldn’t trust them, it’s just some healthy cynicism is likely a good investment, plus you are looking to CONTROL the project whilst they MANAGE it.
A good agency – i.e. one that’s managed to deliver enough projects and get to a scale where you feel comfortable enough to commission them – will most likely have good internal project management practices, because – frankly – it directly ties to their ability to make profit.
What you absolutely need to do when outsourcing software is to convene a project board, and the supplier needs to report into that project board. In a bigger business, the project board would need to have representatives from the end user, the supplier, and the commissioning organisation.
As a startup, it may only be you from the business, the tame customer you have lined up for the pilot is likely not wanting to make that big a commitment to sit on a project board. You also probably don’t want them to see what’s going on behind the curtain anyway because you’re on a learning journey and things are likely to look sketchy to outsiders.
You absolutely have to turn up for the project board meetings, but from the supplier you want both the project manager/account manager, and the senior technician who’s on your project. I would suggest if you are a one-person organisation, you should find a friend who can also sit in on the board both to advise you and act as a proxy for the customer. (They may do this out of love, or you may need to find some way to repay them for their time somewhere down the line.) This gives you something that looks and should function like a proper project board, even if you are at a smaller scale.
One of the reasons you do this is that you can smoke out problems on the agency side. A common problem, especially for startups, is that your work might be less important than the other clients the agency has at that time and you can get “shadow deprioritised”. If you have regular project board meetings, you can detect this or stop this from happening. Another reason for doing this is that it’s exactly the sort of practice you need to embed as you transform into a proper software business.
SWISH 2d Know how to test and evaluate outputs
The reason why I added this one is that, in my experience, over the last 20 years the best clients I’ve had in terms of them getting fantastic outputs from the work they’ve commissioned through internal our outsourced teams have been the ones who were better at testing outputs. It’s fair to say that they also had an x-ray laser focus on what the customer needed and what the product should do, but the more care and attention that they took personally to testing that the outputs aligned to their vision of what they product should do – they had more success.
I think that’s all I have to say on that one – my observation is that you get consistently better results the more you test. That’s contingent on the supplier actually giving you things to test, however, so that links back into the project board stuff we went through before. Make sure they are regularly showing you whatever sausage is coming out of the sausage machine.
SWISH 2e BONUS: Sequencing a pilot
I’m adding this one in here because it’s top of mind for me, and although I did some shorts on it, I think it’s worth having in evergreen content. I alluded to this earlier, in that a really common situation that really screws founders up is that they laser focus on the pilot project, and forget that the pilot project will throw up some learns that require more development to get proper product-market fit.
Another way to put this is that a pilot project usually will reveal that there is some product-market fit, but that level of product-market fit will always be somewhat poor.
Founders have a bit of a habit of putting all the money they have into developing the MVP for the pilot project and don’t hold anything in reserve to apply the learns from the pilot. This can leave the founder stranded with a product that actually doesn’t work and is unsellable, at least until more money can be found. And oftentimes more money can’t be found and the whole endeavour is wasted.
The analogy is that you are flying a plane and island hopping. The first island you land on is nice for a short break, but it’s not where you need to go. Don’t end up stranded.
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.
CONCLUSION
Cool, so we’re all done. If you work through everything we’ve been through in this video, you should significantly de-risk your MVP outsourcing project.
* SPONSOR