4 Crucial Tips When Setting Out to Build a MVP (Minimum Viable Product)

As a software/engineering company specialising in complex web applications and engineering projects, we’re constantly being approached by both companies and individuals looking to launch a brand spanking new product. This is an exciting time, both for our client and for us – our developers would love nothing more than to be given free reign to let their creativity flow on a blank slate. All sorts of ideas for UI/UX, performance, scalability, security – everything get’s thrown about in our many brainstorming sessions, and everyone starts dreaming of the challenges that lie ahead…
However, it’s really important to take a step back – both from the development perspective (i.e. us) and from the business perspective (i.e. our client). Most products don’t fail because they have bugs, or don’t perform to perfection, or are lacking that special feature. They fail because no one wants/needs them. I was recently personally referred to the “Lean Startup” book by Eric Ries and it is definitely a fascinating and worthwhile read. I’ve tried to summarise our experience into 10 points on how to go about building an MVP (Minimum Viable Product). This doesn’t go into detail about the business drivers behind a project/business in the first place (i.e. is there a market for it? is the monetization strategy sound?) but rather looks more at the technology and development approach behind the product once you’ve decided it should be built. However, these two elements really do go hand in hand. By employing a “Lean Startup” mentality, you can invest less in the short run and really learn a lot more throughout the process, than you could otherwise.

Do you really know what you clients want, or perhaps even who they are?
Ideas tend to fall in to two broad categories: Copycats (to some extent) or true innovations that no one sees coming. Both of these present very tangible problems when you’re considering who your client is, or what they want. If you’re iterating on an existing product and looking to introduce a new feature, how positive are you that it will be the deciding factor in increasing adoption of your solution? Just how much will people like it, and even if they do, will it outweigh the benefits of the other competing solutions? It’s impossible to answer these questions unless you take a very methodical approach to developing your MVP. Identify the key feature or features that you believe bring the most benefit to your customers. Don’t worry excessively about the monetization strategy at this stage – that can come later (at the end of the day, you’re not investing large sums at this early stage – or at least you shouldn’t be!).
Don’t try to replicate what your competitors do, like for like
Being inspired by what is out there is unquestionably good. Not re-inventing the wheel on every minute feature is also a great way to go about building something. However, if you’re looking to launch a social platform by building on what Facebook has (for instance) then chances are, you’re going to fail. Companies like Facebook spend tens of millions every year on development and iteration. Yes, as a result, they have a very refined solution that has undergone countless split tests and analysis – so it’s definitely a good starting point. However, the reason it works so well is down to the tiny details behind the scenes. How users get tagged in pictures. How it knows where you are. How advertisers can target you. These are incredibly complex algorithms and processes that cannot be replicated overnight. You’re much better off focusing on a few select features that Facebook don’t have, and starting off with that. If people love it, then you can think about what to do next.
If you’re building an MVP, there’s a very good chance securing investment is on the horizon
It’s hard to start a business – particularly an online business – without resorting to investment in the early stages. It’s just too difficult to build a sustainable business when in a lot of cases the entire monetization strategy is either not yet there, or relies on some sort of a critical mass. As a result, even from the outset, many entrepreneurs know they will need investment. However, speaking from experience (both personally, and working with clients in a similar position), you’ll find this incredibly difficult unless you already have a demonstrable user base. Investing in a business that has nothing increases the chances of failure significantly. It also doesn’t demonstrate the passion, drive and commitment from the founder(s). Investors generally want to see a product that is generating interest, has a decent user retention and has founders who have worked night and day to make their dream a success. Rather than let this put you off, just take a step back, identify what you really are trying to achieve, and build the simplest possible solution that will allow you to take the first step. Don’t be concerned about building a “bad” product at this stage. You’re building a good solution with a restricted feature set, and these days there are countless platforms that will allow you to have this built quickly and effectively, without compromising security or performance.
When selecting development partners, don’t ask for the world
It’s unreasonable to provide a large specification to a development company and select one based exclusively on cost. Firstly, as a “Startup” you need to be innovating incrementally and learning from your customers – this is the entire purpose of starting fresh! By supplying an elaborate spec and selecting a provider based on cost, you’re essentially limiting your development partners to those that are most desperate to have some work – any work. Any sensible company should understand this iterative process, both from the development perspective (agile development) along with the business perspective (the lean startup mentality). It’s much better to understand that you’re working with a company that understands this process, than one who could theoretically deliver the project – as a whole – for a marginally lower cost.