Over my years at tsf.tech, one of the biggest, most important and most interesting interactions I’ve had with founders is determining what the scope of an MVP should be, to the extent we’ve dedicated a whole half a day session per startup to figure it out! In this blog, I want to cover a few things. Firstly the definition of an MVP, secondly how we use our scoping session to define an MVP and then finish up on some tips and tricks to help judge your own MVP scope.
So first things first, an MVP is Minimum Viable Product (not most valuable player for the sports fans out there). Seems straightforward enough right? Well, sometimes you’d be right, but in many instances it is not as straightforward as you think, hence scoping sessions. I think the easiest way to break this down is to tackle the three constituent parts of MVP.
Minimum
The smallest amount or quantity that is possible, usual, attainable, allowable, etc.
We all know what minimum means (and if not the definition is above). However, often in the heat of the moment and in the excitement of seeing your startup offering baby come to life, it can be hard to stay restrained and stick to what is truly the minimum you require to go live with your product. Some systems by design may need to be bigger than others and so the minimum is very much a personal view but here at tsf.tech we have methods of trying to ensure that scope is kept to a common understanding of what minimum should be.
One method for doing this is having an MVP goal and using this as our anchor throughout our scoping sessions. If we feel that a feature doesn’t add to the goal, then why is it being added at this stage?
Another is thinking about automation. As a founder, your role can be eclectic and involve wearing multiple hats, often at the same time. With this being the case you may want as much automation as possible to try and reduce your workload to focus on the other hats. But here comes the rub, a lot of that automation is not necessary to make your MVP work, and a lot of steps can actually be handled manually, to reduce the cost and risk of your build. As a neigh on perfect segway, we then encounter the second part of the MVP…
Viable
Capable of working, functioning, or developing adequately to provide a minimum level of value to users.
Part of tsf.tech’s value to founders is in helping to scale back the MVP to really focus on the minimum of what is needed. What we rely on is the founder’s expertise and vision in defining the viable. As much as tsf.tech has a huge experience in assessing and building tech companies, we’ll never have the experience that a founder has in their sector.
This is where some of the conversations are the most interesting during scoping sessions. The fine balance of what can be considered the ‘functional’ minimum and what is the ‘operational’ minimum. When does the ‘operational’ minimum cross the boundary into just above minimum? Hard to say and each business and founder is different. The easiest way to balance this is often the classic ‘Five Whys?’ to get to the crux of whether a feature is being added to help customers or to help the general running of the business.
Why do we need to add a billing system, can’t this be handled out of the platform?
This is a question that crops up a lot, especially with B2B propositions and often the answer is this is something that can be added later. At this stage, if part of the MVP goal is to hit ten users, you can raise ten invoices a month manually assuming success… if you’re hitting 10,000 users though then maybe that’s automation that is needed to make this viable. But maybe for the first cut to reduce cost and risk, consider what you can handle manually, but not at the expense of the final part of the MVP, Product.
Product
An article or substance that is manufactured or refined for sale
Whatever you do and where you set the needle for what is minimum and what is viable, the focus must always be that this is a product that users will be buying. The majority of investors in today’s climate want to see traction before investing. To that extent, the MVP once completed needs to be a functioning product delivering value.
Whether it’s a fully automated smooth machine or you’ve got a man behind the curtain flicking switches and twisting knobs and tapping dials, as long as your users have a functioning product then often they won’t be bothered how the system works. This means that you can prove traction in the most efficient way possible, and then your raise builds the product that lets both you and your product scale by adding in features and automation that give you the time to focus on all the other roles that a founder needs to focus on.
So what are the takeaways from this?
When you’re looking into your MVP and what is actually needed, think about the three constituent parts:
Minimum: Is everything I’ve said that needs to be in scope absolutely necessary?
Viable: Once this is built is this something which can function and scale as a business?
Product: Are people going to pay for this?
If the answer to each of these is yes then congrats you’ve successfully scoped out an MVP. If not, don’t fret, this is something that you can iterate to fine-tune and hone. As I said before, scoping an MVP is more of an art than a science. If you’re not sure, then drop me an email and ask, I’m always happy to help!
