How to MVP
Four questions to ask before you start
Maybe it’s my old artist genes, but I’m quite the sucker for the cool breeze of the blank page. Whether it’s an artwork or an app, the point of inception conjures boundless possibilities; Nothing has yet gone wrong. Anything might happen. And so over the past few years, like a moth to a flame, I’ve found myself repeatedly working on nascent software products both with my own startup and through consulting for others in the sphere of EdTech. Yet building MVPs from scratch is a risky business where horror stories abound. So, out of my lived experience, I’ve attempted to answer four questions which founders might ask themselves when embarking on version 1.0.
What should I build?
Resources are tight and you’ve resolved yourself to build an MVP. But what aspects should be prioritised and which features should make the cut?
Focussing on why your business needs an MVP will help answer what you need to build. Decide whether your MVP is actually a Validation Tool — a threadbare component of your app designed to test a hypothesis about your product and users, a Demo — a partial implementation of your app designed to woo potential customers and investors, or a Market-ready product — the minimum version of your product which can be sold to customers using your proposed business model with the aim of achieving initial traction.
Your choice will affect the scoping of your build:
For a Validation Tool aim to use as few resources as possible. Look and feel, engineering, and usability concerns all take a backseat to data collection.
For a Demo, aim to display all of your platform’s key functionality to a single user in just a few minutes. Prioritise implementing unique selling points over table stakes functionality such as logins or dashboards. Consider faking user data and activity along with unimplemented features through static UI elements.
For a Market-ready product, aim to implement the bare essentials required to sell and deliver the core value proposition. There’s a lot to consider including security, robustness, customer support and compliance, but there’s slack in terms of scalability — your early traction will involve hundreds or even tens of customers. Consider ‘Wizard of Oz’ing your more complex processes through manual work behind the scenes.
Who should I get to build it?
Your MVP build is likely to be the largest expense in the short history of your company, so it’s an undoubtedly scary prospect. Many choose to outsource to a software development house. These guys cover all aspects of the build including specification, design, compliance, project management and infrastructure. By efficiencies of scale, they boast faster development times and cheaper prices. I can see how this is attractive to non-technical founders, but I’m going to go out on a limb here and say that in my opinion, this is not the way to go.
Outsourcing encourages waterfall patterns of periodic releases, and this does not suit the fast pace of startup product development. Alongside your MVP you should be aiming to build a sustained workflow of rapid and incremental changes in response to data and user feedback. This happens best in a tightly-knit cross-functional team — for instance, a coder, a designer and you as the product manager. Building such a team with specific expertise around your product adds to your company’s value — you may even find your future CTO or CPO.
If I’ve convinced you, then this still leaves the problem of who should you hire. Don’t expect to tempt your friend who works at a FAANG away from their lucrative and stable position. In any case, being accustomed to a highly structured and well-resourced working environment would make them a poor fit. More likely candidates are high-performing graduates looking for experience, entrepreneurial developers with startup experience, or developers who are passionate about the domain of your product. Expect them to be unconventional and perhaps a little bit of a maverick. Nevertheless, they must be professional, and it is crucial for you to establish that they have the necessary technical skills. A good way to do this is to find a technical advisor — this may well be your FAANG friend. They can help with writing a job specification and carrying out technical interviews — you should definitely do these. Later on, your advisor might act as a mentor to your developer.
How do I tell them what to build?
Communicating a product vision to a developer can be particularly challenging for non-technical founders. Sure, you’ve compiled a short list of features to be implemented, but there’s still a huge amount of detail to be elucidated. Much of this will need technical input. There are several well-established techniques that you can use to document and clarify your product vision ahead of briefing your developer.
Story mapping is a great way of breaking down broad feature descriptions into detailed subcomponents which can be later organised into tasks for a sprint. Wireframing involves producing rudimentary drawings of your UI. User flows plot a user’s movement through the app via chaining successive user stories or wireframes together into branching sequences. The documents you produce should prioritise visual communication at low fidelity. I like to draw my wireframes with an iPad pen and produce my User flows on FigJam.
It’s important not to outsource this work to a designer at this stage. Engaging with this process will give you deeper ownership of the product revealing any inherent contradictions and oversights in your vision. I’ll once again flirt with controversy and say that high-fidelity designs are not useful until the project constraints have been fully explored. I’ve seen so many elaborate Figma prototypes binned after an initial developer meeting brings expectations back into scope.
I suggest breaking technical planning with your developer into two meetings. The first one is for you to present your product vision via your documentation. Plan this presentation carefully so that your developer gets a full understanding. As you present it to them, get your developer to speculate on the technical requirements explaining in lay terms as they go. The second meeting is for the developer to propose their technical solution following some offline research and planning. Work with the developer to split the solution into a logical series of two-week sprints each resulting in a deliverable. It is likely that the developer will need to do some research and learning at the start of the project. This work can still be expressed in deliverables through example projects and documentation. Doing this process may well expose over-specification, and you should be willing to revisit the project scope at this stage.
There are two final considerations to include in your planning. Firstly, make sure that you understand the running costs. These can be complicated to predict and are often overlooked by developers who don’t pay the bills. Secondly, allocate some time for light documentation in each sprint. A small downpayment from your current developer will save time and money with onboarding future ones.
How do I ensure that they build it?
Managing developers is another tricky area for non-technical founders and it’s where disaster is most likely to strike.
You want to catch miscommunications and poor performance fast so that you can correct course before the budget is spent. Luckily your sprints and deliverables provide a good framework for this. Sprints should be split into granular tasks which you and your developer should track via a Kanban board — Jira is an industry standard.
Even the most experienced developer can underestimate timings, so sprints need to allow some flexibility. Avoid extending sprint deadlines, rather move overdue tasks into following sprints. There are a couple of questions you should ask your developer when a sprint is overrunning. Firstly, is it over-specified? Developers tend to be overly optimistic during planning. Secondly, can it be achieved more simply? Developers sometimes over-engineer designs beyond performance requirements or implement features from scratch where third-party libraries exist. In any case, sprints should always end on time with a demo of whatever deliverables have been achieved.
It goes without saying that you should have a contract with your developer and pay in instalments. Payment should ideally be linked to sprint deliverables, so if possible, the finalisation of the contract should follow planning so that it includes deliverables. It’s also well worth including clauses to cover late delivery and of course IP ownership.
In the case that your developers leave before the project ends, you need to ensure that all of your data remains secure and accessible. It’s imperative that you own the master keys to all of your data. All code should reside within your own Github organisation with you as the administrator. The same applies to services such as AWS and Heroku. Don’t forget your non-technical services such as Google Docs and Figma. Invest in a password manager such as 1password with a business tier. Don’t scrimp on subscriptions and don’t share accounts between multiple people.
I want to stress that most of the developers I know are self-motivated and diligent folks. Yes, these measures are intended to shield you and your company from rogue actors and mishaps, but they also protect your developer from unrealistic and unclear targets, anxiety and burnout. Consider careful project management as an act of kindness.