Being Head of Engineering at tsf.tech, my job is to make sure we build the right thing, build it well and find the best way of delivering it. I work closely with tech product entrepreneurs to define and build their Minimal Viable Product (MVP), which is the first concrete realisation of their startup dream.
Done well, an MVP is a quick and effective way of getting your initial product in the hands of early users and getting your startup off the ground, which in turn drives your future product’s design, features, and user experience.
However, building an MVP can come with a lot of rigmarole. It does involve a lot of thinking, wrangling, and quite often some tension, usually over what to class as ‘minimum’. When it comes to the initial phase of a product launch, there can often be a challenge in a startup between finding the balance between what’s ‘enough’ and what’s viable.
This article will briefly guide you through these challenges and give you a nudge in the right direction when it comes to creating your MVP. Myself, Ian and James talked a lot about building an MVP in our recent podcast too so feel free to check that out here.
It’s a sellable product that works, mostly
MVP isn’t just building something to test the waters or creating a proof of concept. I like to think of it as the distinct, next phase beyond that. The clue is in the name, really. There are three key features to an MVP.
The first is it’s minimal. It doesn’t need to have all the bells and whistles for every user. Rather, it just needs enough features for the early adopter users.
Secondly, viable means to me that it doesn’t have to be perfect – pretty much every piece of software in the world isn’t perfect. Everything’s got bugs in it. It doesn’t have to be optimised. It just has to work… mostly.
And then thirdly, it’s an actual product. That’s not to say it has to be physical, it could still be an ephemeral service but its engineered with the quality your customers expect for the price they pay for it, rather than a lashed together prototype.
With that said, building something with minimal functions doesn’t have to be shabby or full of bugs. Today’s software tools are far more powerful and more accessible than they have ever been before, so it’s not prohibitively expensive to build something of reasonable quality.
So how do we narrow our ideas down into the absolute minimum features? Where do we put our focus?
It’s impossible to put more than one thing as a top priority
We ran an analysis a couple of weeks ago of our design sprints and discovered on the first day that our clients found over 80% of their desired features were essential, which is incredible!
Often founders of startups have spent months sketching out their products in great detail and it’s one reason why many of their features are considered essential. It can be hard to guide them away from that philosophy.
It’s normal and it’s not just in startups either. As we run out of testing capacity for COVID-19 cases the government has prioritised who gets tested first. Of course, people in the medical fields and schools are a priority. But the other day I overheard a conversation on the train that retail workers are priority too! Brilliant. They seem to have prioritised everybody to the top of the list. I wonder how well that will work.
The lesson here is that it’s impossible to put more than one thing as a top priority. Rather than grouping your features into must-have, should-have, could-have or priority-1, priority-2 categories ask yourself, What order should I do these things in? When you are forced to choose, the decision becomes more meaningful, and picking out your essential features will become far more manageable as a result.
Not just a feature list
But it’s not all about features only. A lot of people tend to think of MVP purely as that list of feature sets but that’s only one dimension of it. If the feature list is the breadth, we need to think about the depth. Including things like the design, UI and UX.
For example, If you build a customer-facing software, the screen and graphics will need to be more polished. However, if you are building a data science tool, then the main focus will be functionality, and the workflow doesn’t necessarily have to be as swish.
Legislations or domain regulations may set a minimum bar for certain features of an MVP such as quality, security or resilience. This is especially common for companies in the fintech arena. However that doesn’t mean you can’t refine the MVP scope and release early.
Remember, an MVP only needs to do a certain part of the job of a finished product. So contrary to what some say, you can have a safe MVP of an air traffic control system, just don’t expect it to have the same scope or user experience as a future release.
Make room for growth
Making feature cuts when building MVP is inevitable, but no matter how minimal your product is, you should still create something with room for growth without over-engineering it.
Let’s say you have predicted a million users in three years. You should still focus on the hundreds you have for now. However, at the same time, you should be using some technology that will allow you to get to a million users without having to start again from scratch.
Apple did this very well. When the iPhone first came out, it was a product with only essential functions but had huge development capacity. It added cameras, battery-life, sensory recognition, and countless other game-changing developments over time once the users had a say. They put it out to market and let their early adopters inform their long term growth strategy.
So MVPs give you a great growth strategy for your product. They can tell you if your idea is scalable, if there is a market for it, and ultimately determine the final product. But it’s got to be about what’s most effective for the customer.
The closer you get to your customers and the adoption, you have greater sense of control over what your finished product should be. You’ll find out exactly what features are genuinely more valuable, from the people who will be paying for them.
Set your expectations
We’ve always found that what people assume to be minimum always seems to get inflated when we talk about MVPs. Often, founders of a startup who have an idea of something want it to be absolutely amazing. But many people miss the point that things start slowly. It’s us from the engineering background, who know how hard it is to create even simple things, that know there is a need to focus.
The MVP for a music streaming site like Spotify may not need a complex search and categorisation to help users navigate a million songs. Because it may only have 20 or 100 tracks to start with. It could even make it harder for new users to use if they are forced through this long search process at the very beginning. A simple scrollable list in that scenario would actually make that kind of product easier to use.
When targeting your first early adopters with your MVP, it is key to set your expectations slightly different from your big vision. Try building something a bit different from what you anticipate being the end outcome and leave room to expand as you learn from your customers.
It’s a long continuous journey
So when it comes to MVP, remember it’s not about creating the perfect product. It’s about building something that works, which can provide you with valuable customer feedback. Prioritise your features into an ordered list and make sure you have room for long term growth.
Try not to think of your MVP as something concrete. Instead, think of it as a long continuous journey of build, measure, learn. Don’t be afraid of getting it out there early. If you wait and wait until you are totally happy with it to release, you’ve probably missed the boat.
Just focus on the now, and use what you learn to build towards the bigger vision.
I hope this has been useful and if you have anything to add we’d love to hear from you, post a response below.
Alternatively, feel free to get in touch with us by emailing at ericc@thestartupfactory.tech
P.S Myself, Ian and James discussed this idea of creating your MVP in more detail in our upcoming book (due out this year, head to tsf.tech for release updates!), and also during episode three of our podcast, ‘From The Factory Floor’, so if you wanted to hear that just click this link to listen.
