As a non-technology founder, you have an idea, but how do you turn that idea into reality.
The decision that most founders make is that they need to outsource development of the software to an agency. But, there is a major problem with that in that – in my experience – having worked with founders for 20 years, most of the projects that I have had to rescue have been because the agency made some crucial mistakes that left the founders at best out of pocket, and at worst out of pocket and without any outputs that they could use to actually build their business (because they spent all the money on software that didn’t work for them).
Being a non-technology founder who’s outsourcing their MVP through an agency is hard. Really hard.
And in this video, I’m going to go through how you can successfully outsource your MVP as a non-technology founder.
* STING *
OK so here’s what we’re going to do.
ONE I’m going to reframe what an MVP is so that you have a better chance of successfully outsourcing
TWO I’m going to show you how agencies work, so that you have a better chance of successfully outsourcing
THREE I’m going to show you how to select an agency that you are likely to have success with,
FOUR I’m going to show you how to instruct that agency to build that software, AND show you how to manage that agency throughout the project life so that you – guess what – have a better chance of successfully outsourcing.
* SWOOSH 1 Reframing what an MVP is *
The reason why we need to go through a reframing process so that we look again at the definition of “MVP” is because the wild success of the concept of MVPs over the past decade or so means that the basic idea behind them has been lost.
MVP stands for Minimum Viable Product.
Everyone now is fixated on the “MINIMUM”, but it’s the “VIABLE” part that’s the most important.
We get the idea of MVPs from a book by Eric Ries 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.
Where this has got distorted over the past 10 years is that idea was about the experimentation, NOT the total spend. You’d spend the same amount of money using a lean approach as opposed to a – non-lean, what is that “fat”? approach, you would just increases your chances of having something… and here comes that word.. VIABLE at the end.
I suspect Eric Ries chose the word “MVP” for its snappiness rather than laser-accurate etymology, especially as MVP means something culturally within the US that it doesn’t within the UK so us in the UK miss some resonance of the term MVP, but it’s muddled because the VIABLE refers to the BUSINESS, NOT the PRODUCT.
In order to have a viable BUSINESS you need to be able to sell your product, and have a cost base that is low enough to afford some profit, not just once, but over the long-term. You may have your own exit plans, but unless you are building something that has legs for a minimum of 20 years, you don’t have a business.
This is where things get really distorted because the focus on MINIMUM PRODUCT as opposed to VIABLE BUSINESS means that within the echo chamber of the community that supports non-technology founders to build technology businesses, all the chatter is around SHORT TERM moves as opposed to LONG TERM sustainability.
Where this comes to a head is when you are relying on using a agency to build your solution. So let’s look at how agencies work…
* SWOOSH 2 How agencies work *
I am going to come straight out and say it.
Agencies exist to augment existing technical teams, they should not be a business’ only team
That noise you can hear coming from outside wherever you are is every agency owner worldwide yelling at their screen right now. They hate this, because agencies position themselves as being a partner that you can “hand-off” work to, but when it comes to software development, this is straight-up not true.
Outsourcing software to an agency is not a “customer/supplier” relationship, like getting someone to empty the bins in the office and run the Hoover around. An outsourcing agency MUST be a “delivery partner”, however YOU need to run the relationship and direct the work. They are HELPING YOU to deliver, not being the be all and end all of delivery.
The reality is that in order to get good results from an agency every time, there has to be a technology person within the business that is the guiding the agency – because the agency is AUGMENTING your technical team, not JUST EXISTING AS your technical team.
Practically this means that you need to have a technical co-founder or a CTO to do that job because just having at least one technology person within the business gets the agency into this “augmentation” mode where you are effectively guaranteed good results.
However, if YouTube has recommended you watch this video, you likely don’t have a technical co-founder or a CTO, so what do you do?
(I’m not one to say that something “can’t be done”, so here we go…)
A founder of a business will sit somewhere on a continuum of being product-led, or sales-led. The product-led founders will spend a lot of time and attention fixating on creating a beautiful product that the customers will love. (The challenge there though is that product-led founders can fixate so much on perfecting the product, they never bother doing the vulgar part of actually selling it.)
Sales-led founders love an opportunity and are hyper-focused on listening to the customer needs and then doing whatever needs to be done to meet ghat customer need. The phrase to watch here is “yes, we can do that” – whereupon the actions after the meeting are all hands to the pump with everyone trying to work out how to deliver what has been promised.
For a non-technology founder, the rule is is that you can offset the fact you don’t have a technology person within the business so long as you are product-led. (And we’ll see why this is in part 4). As a rule, non-technology people who are outsourcing software development CAN make the situation work by focusing on product, but CANNOT make the situation work by focusing on sales.
This matrix describes the problem.
No technology person, product-led OK
Has technology person, product-led OK
Has technology person, sales-led OK
No technology person, sales-led NOT OK, and/or HERE BE DRAGONS
All of this is because agencies can effectively execute when they are told to build something specific, but will usually fail spectacularly if there is less specificity over what they are building. A product-led approach is highly-specific (and risks being inflexible), but a sales-led approach is highly-flexible, but non-specific.
What actually happens behind the scenes with a sales-led approach is the technology person is implementing measures to support greater levels of flexibility. You can do this when using an agency, because the technology person just instructs the agency to add in those flexibility-supporting measures, without necessarily telling the non-technology founder that that is going on. (It’s all part of the magic.)
An agency will typically NOT add in things that are not specifically requested. This is not a criticism of how agencies work, it’s just economics. Agency work is expensive, so the approach is to cut everything very close to the bone – from the agency’s perspective, if the customer asks for something, it will be built, but if the customer does not specifically ask for it, it will not be built.
For a non-technology founder, if you are very product-focused, you naturally have a clear end-goal, and that end-goal can be expressed as a piece of software, and the agency will likely hit the target you describe, because that is what their business is.
The trick here is that even if you are a very sales-led person, you will be an order of magnitude less likely to be successful, unless you fix your approach on having a very product-led interaction with the agency.
Avoid the dragons, be product-led.
* SWOOSH 3 How to find an agency *
This one is simple. Ask a friend to recommend one.
If you are a non-technology founder, qualifying and choosing an agency is very difficult. You can make this a great deal easier if you just ask someone that you trust.
Even if you can or can’t source a recommendation, let’s just unpack what we mean by outsourcing and then come back to how you might find an agency.
Within the software industry, when we think about “outsourcing”, we have a word that goes along with this which is “offshoring”, and we do that because some time back, some bright spark worked out that if we hire developers in – in particular – India, we can spend less than if we hire a developer in the UK.
However, what we also worked out was that it was quite difficult to offshore in this way and get good results without developing specialist skills in managing offshore developers, and so an another bright spark hit upon the idea of offshoring to Eastern Europe, where the pricing was still cheaper than the UK, but not as cheap as it was sent over to Asia, but that for whatever reasons it was easier to instruct developers in, for example, Poland, than Pakistan.
(As we go through this, pricing in the US is roughly parity to the UK so US viewers can use UK pricing for comparison.)
Specifically, outsourcing to Eastern Europe is roughly 50% cheaper, and outsourcing to Asia is roughly 70% cheaper. But it still holds that it’s generally easier to manage “nearshore” developers in Eastern Europe that offshore developers elsewhere.
The upshot of all of this is that domestic outsourcing – i.e. if you’re in the UK, outsourcing to a company in the UK, isn’t the default way outsourcing is done. Most non-technology founders are sent off on a mission to find an overseas agency to provide their software.
Happily, because most outsourcing companies rely on trade from overseas, they are almost all very good or better at that client-engagement piece, so you should find that both the hygiene pieces like contracts and paperwork, along with the day-to-day is just as straightforward dealing offshore as when dealing with a domestic business.
How do you find one though if you can’t rely on a recommendation?
Well, one thing you can do is just open LinkedIn and wait five minutes for one of them to send you a direct message trying to sell you outsourced software development.
* PAUSE – badoom-tish *
I’m – half – kidding.
I would definitely socialise the query on LinkedIn – using LinkedIn to find any type of technical resource is far more effective than using Google; as even if you can’t find a direct recommendation from your network, a secondary recommendation is worth something.
I would also ensure that you get at least four quotes – not three, definitely not two. Over the years I have spoken to plenty of founders who have straightforwardly just overpaid for outsourced agency work because they hadn’t got benchmark/baseline pricing dialled in.
I would try as far as you can to ensure that the agency has a scale such that they are likely to have enough cash in the bank to reimburse you if it all goes to custard. But, you need to ensure that they are small enough to care about your project. You can only really get the answers to that question by asking them what their average project size is, and how many projects do they do of that size each year. The average project size should be about the size of your project to 1.5 times the size of your project, and they should be running 4-5 projects of that size at any one time.
Counterintuitively, it’s not massively important that they have built projects like yours before, mainly because if you’re doing it right, there shouldn’t be enough projects like your one such that a random outsourced agency in India or Thailand or Estonia has built something like it before. But there does need to be some alignment in type of customer.
For example, in “direct to consumer” work, the way an app looks and feels is really important; less important than if you’re building a “business to business” tool to support the constructor industry. Try and aim for some alignment in the type of end-user, but actual specifics – e.g. sector experience – is not terribly important.
Once you have that shortlist of four, it’s just a matter of the one that engenders the most trust and is close to the average cost-profile.
* SWOOSH 4 How to instruct *
At this point we know that we need to be a) building a product that supports a viable business (not just trying to rush the first thing we think of out to market), b) looking from a product-led perspective, and c) working with an agency that’s likely overseas and has ideally come from a recommendation (but in any case we know we’re paying a fair price, and we know the agency is at a scale where the work they are doing for us is important to them), and that d) the agency is a delivery partner of OUR business and whilst they MANAGE the project WE are in CONTROL of the project.
Back in the days when people used to be scared of computers – as opposed to now when everyone spends half their lives using a supercomputer that they carry around with them 24/7 – one thing that you could say to someone who was anxious about computers is that “they only do what you tell them to”.
Engaging an agency is like that – they will only do what you tell them to do. Ergo, what you tell them to do is important.
Look on my channel for other videos around how you actually do software product design, but as a quick introduction to the topic, product design is all about considering the user journey and working to “remove friction from the customer experience”. What this boils down to is thinking about outcomes.
There’s an adage in sales – which to be honest I love so much I wish I could marry it – which is “if someone walks into a DIY store and buys a drill bit, they are not buying a drill bit, they are buying a hole”. The product is the drill bit, yes, but the OUTCOME is the ability to make a hole in whatever thing it is that they own which currently should have a hole in it but at the moment does not.
To conceptualise this, people don’t use Tinder, they want a date. People don’t post on Instagram, they want connection through engagement. People don’t use RingGo or one of 8.2 trillion parking apps because they need to pay for parking, they want to avoid getting a parking ticket.
Software product design is like this in that what you are trying to do is help the user go through a transformation – and the PRODUCT will be better the more you are able to a) understand where they start, b) understand where they need to be, and c) can visualise how to get them from the start to end, in manner that they experience as DELIGHTFUL.
(Different people have different philosophies about how software should work – for me, for whatever reason, software should be DELIGHTFUL, so that’s the term I use. It’s shorthand for whatever passion or X Factor you want to introduce into your work.)
The agency is going to require you to describe what the software should do in a clear and precise way. As a non-technology person, this is likely to be the first time that you have done this, so you will almost certainly be on a learning journey.
In order for the agency to have quoted you in the first place, you would have had to express to them at a high-level, although in detail, what the main “flows” of the software actually is. They can’t quote you if they don’t understand what your end user’s journey is – i.e. they can’t quote you if they don’t understand the VISION of what you are trying to build.
But that is at a high-level.
In the day-to-day, when you come to do the actual work, the vision has to be broken down into smaller and smaller parts, and each needs to be described in greater detail. A very accessible way to do this for non-technology founders is via user stories, which literally are just little descriptions of the user’s journey through each part of the system.
I don’t have time here to go into masses of details about user stories – check out my channel for more – but as a basic description they are literally just a narrative description of how some function within the software should work. Eventually, you’ll write enough user stories so that the whole vision of your product is captured, and as you test and experiment with customers, that vision will end up aligning beautifully – delightfully even! – with the customer’s need.
For example, if you’re building an app that allows someone on a building site to record snags (i.e. mistakes) in a new house that has been built, a user story might say something like: “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”.
Hopefully, that story there is so easy to understand that even as you’re reading you are able to visualise how that feature would work. If you, and others in your business, can understand it, it should be a certainty that the agency will understand it too. As you build a better relationship with your agency and work more together, you should get better and better at writing stories, and your final vision should become more and more clear.
There are a bunch of other things that needs to go into the process of effectively managing an outsourced software project, but this idea of being able to express the product as a series of small user stories that all fit together nicely is at the core of it.
Then, as the project progresses, you just need to make sure that you keep your “product owner hat” in order to make sure that what you are building aligns what the customer needs. Then we come back full circle to what we’re supposed to doing in relation to all this Lean Startup stuff – just keep testing and experimenting with actual users. That whold process will almost certainly – I’m willing to guarantee it, to be honest – you will get to a position where your Version 1 MVP is an effective product that lets you build a viable business.
Some YouTubers have sponsors, but I sponsor my own videos. So here’s a message from me, my own sponsor.
If you’re a non-technology founder starting a technology business, I have a self-paced course on my website that takes you from the idea you have, to getting a fully-operational and profitable technology business startup.
I’ll show you in the course how to get your MVP built, how to find product market fit, how to get traction, and from traction either build your pitch deck and financials and get seed investment, or turn that traction into the cash-flow you need to get your startup to scaleup.
If you’d like to learn more, there’s a link in the description, or just head to fractionalmatt.com/course.
Thanks for listening, and I’ll see you next time!