Blog
9 rules that power successful MVPs
Jun 12, 2019,

If you’ve landed on this page, it’s quite possible you’ve already read our take on why building your first app as an MVP might be a good idea. As observed, this topic is quite interesting to you and we’ve decided to go into specifics of building a Minimum Viable Product that could survive the competition and give you a better outlook on your target market.

MVPs are all about proofing your idea and spotting specific needs within your target audience. Focusing on making a good viable product is key and since startups tend to build an MVP the same way you build a product, we’ve decided to share 9 tips our most successful clients made use off, when building lucrative MVPs.

1. Do your homework

As we’ve mentioned, an MVP is not and will never be a low-value prototype. That’s why they call it a minimum viable, not minimum feature product. In a previous post we spoke about the importance of “doing your homework” before even thinking about building user experiences or user interfaces.

45% of startups fail because they build revolutionary products with no use for their audience. In other words, if your startup should survive the seed stage, you need to build products for OTHER PEOPLE – yeah, it is that simple. Put others first, get constructive feedback and throw away those “everything is going to be ok” glasses.

There are a few tips to avoid falling into those 90% failed startups outlined by a top-rated entrepreneurial mastermind, Mr. Steve Blank, in his “Customer Development Manifesto”.  At this stage, you can focus on 3 main ideas from that source:

a. There are no facts inside your building – get outside, try interacting (if possible) with your end-users and get inside their minds – you’ll be surprised how far-fetched your assumptions might be.

b. Validate Your Hypotheses with Experiments – there is simply no way to find out what really matters to your audience. Run a short survey or ask around your network what use-cases would qualify as essential. No business is built on nice to haves and this tip will help you filter the clutter.

c. No Business Plan Survives First Contact with Customers – don’t set your expectations too high. Remember that an MVP’s purpose is to test/experiment/gather your audience. You must be aware that things might not go according to the plan. The first touch with your customers will give you more clarity, but don’t expect the same circumstances to remain unchanged. Digital service provisioning is a dynamic market – so should be your expectations.

2. Find “the right” message

Expressing your idea into the right message is paramount. If you missed sending it, you risk everything. Fortunately, there are several steps you could achieve that.

One of them is Simon Sinek’s “Start with Why” roadmap, deemed to be as one of the most successful in building and engaging your audience. He states:

People don’t buy what you do; they buy why you do it and what you do simply proves what you believe. In fact, people will do the things that prove what they believe.

In other words, focus your message on your values, on your core beliefs and on practical use. Ask yourself why would they buy-in? These will not only make your audience relate to your product/service but will also drive more innovators and early adopters that found themselves in the same boat with your value set.

Simply put: if it’s to consider “The law of distribution of innovation” covered by Simon Sinek in his book  “Start with Why: How Great Leaders Inspire Everyone to Take Action”, you should direct your message to innovators and early adopters. These end-users are most likely to recommend, comment and build traction for your product and/or service – therefore, your MVP should appeal to these people in the first place.

Moreover, if a startup plays its cards right, not only will it survive its seed stage, but will also gain higher success rates in matters of customer building and/or service adoption. This is because the law of diffusion of innovation tells us that if you want mass-market success or mass-market acceptance of an idea, you cannot have it until you achieve a 15% to 18% of market penetration. If you manage to get that 18% among innovators and early adopters you can easily trip over that generic 10% of sales conversion everyone is proud of, leaping from insecurity to consistency.

3. Build a feature list and go into their specifics

Try picturing your business process or even better: invest some time in building that in a flow-chart. Define clear and achievable objectives and explain those as step-by-step actions. Once you’re done with that, open your favourite word processor or spreadsheet editor and list all features that power your business process.

The more you write – the merrier. Once you’re done, try to categorize these in 2 different types: Must haves (that are the core of your business logic) and nice to haves (think of additional login features like Facebook/Google/Phone# authentication – for an MVP one or maximum two will be enough). Once you’re done categorizing, re-check the must-have features and try to fill in the gaps in their description and/or reallocate some of those to the “nice-to-have” list.  If you’ve managed to do this – consider you have the application’s requirements done.

4. Picture your user’s need 

As you might assume, the message you’ve built is not going to cut it. You’ll really need to focus on how your end-user will use the service and how usable the service/product you’re providing is going to be. As mentioned before, you don’t have to spend hundreds of hours designing a full-fledged UX. If you did your homework properly, you must have some idea or at least some stacked suggestions about how your interface should be and look like.

Draw a screen map with interconnections for each element (buttons/menu elements leading to another screen). As a guide, follow that business logic flow-chart as well as your core functionality defined in previous steps. I’d recommend drawing wireframes or application screens on a flipchart, with respective connections – this will result in a User Experience map (or a User Journey) that will give you a better idea on how your app will work. In addition, when the time for a new feature comes, you’ll be able to point exactly where and what should be developed.

Again, the rule here is “design for others” – your assumptions might come from the right place, but if you haven’t tested your usability concept among some acquaintances there is no telling how end-users might react. If you’re more like me and would like to have this in a digital form, you could make use here of some prototyping tools like Invision or Pencil (we’ll elaborate more on these in a different post).

5. Consult your team before building

Once you have the user experience map and core functionalities straight, get a professional third-party’s opinion. That 3rd party might be a designer or a developer that could express his/her opinion regards your concept. If you’re outsourcing, your chosen service provider will definitely proof-check your UX prior to development. Try going through the application’s business logic, it’s User Journey and expected outcomes. You might get some insights on those core functionalities together with a better perspective on “nice-to-haves” that might hide within.

In addition, if you’re not quite technical, the team you chose might spot technology bottlenecks, advise on overcoming them and even suggest technology stacks that match your scope and would make Iterative Development possible. If your service provider says that “everything looks great” without suggesting you anything, there’s definitely something wrong.

At this stage, it’s merely impossible to deem something as ”perfect” or “great”. Based on my experience, before building the UI, at least 4 meetings are required: 2 for clarifying the concept and at least another 2 sessions to suggest the best stack, eliminate technical contingencies and any conceptual bottlenecks.

6. KIS it before you design it

Take another look at your User Journey and clean-up the clutter. Make sure you’re Keeping It Simple for your end-user and make sure there are less than 3 clicks/taps to achieving an objective.

This step is mostly a proofing one, where you re-evaluate your User Journey before translating it into an actual interface. Get your service provider involved in this. This isn’t their first app and they will definitely suggest improvements based on their experience – if those make sense to you, change the journey accordingly and only then green-light the User Interface sprint. Remember: changes are possible, it’s just that in time, applying a UI fix might get quite expensive, depending on the complexity of that change and its impact on your entire app.

7. Make use of iterative development 

Agree with your service provider on an iterative development model and build a list of deliverables. These should resemble something like this:

7.1 System Architecture – a short description of used technologies (or the project’s stack) with a graphical flow of your application that should represent a general interaction between databases, system elements and third-party integrations;

7.2 User Interface design – resembles a fine-tuned version of your user journey wireframes, translated into screen-by-screen sources for your interface markup);

7.3 App’s 1st iteration – a usable application (built in base of your User Interface design) that performs agreed functions for a specific interaction (for example, the application’s log-in interface and 20% of its functionality);

7.4 App’s 2nd iteration – sums functionality of your first iteration with additional features (aka 60% of the app);

7.5 App’s nth iteration – same as above, representing n% of your app’s functionality.

Building the MVP under such a model will allow you to get something usable at the end of each iteration/sprint and will enable a flexible Quality Assurance/Control process. In addition, while your service provider builds the next iteration of your app, you can probe your pre-alphas amongst investors and/or partners to get an idea regards eventual improvements.

Simply put, when you build an MVP in an iterative manner, you can build, measure and learn on the go, which will result in a better MVP for your stakeholders. Furthermore, since you actually have something to show for at the end of each iteration, you can pause your development when you’re short on money, with something to present to your potential investors. Resuming work would be easier and if you hit a dead-end, you can stop without having to lose it all.

8. Acquire user feedback and metrics

As stated, an MVP is designed to get traction and assess your market. That’s why technical development is not the biggest challenge on the table. You really need to test it against true circumstances and constantly check on your application’s dynamics, to do so, follow these steps:

8.1 Run incentive-based surveys

Once you’ve launched your app, try getting as much feedback as possible from your existing users. They will definitely let you know if something is wrong with your app but would be steep on suggesting improvements. If you’re not that big on money, run an incentive-based campaign (something like “complete this survey – get a 5$ gift-card for Amazon”). Those 500$ can get you insights about customer satisfaction and drive suggestions on improving your service faster than expected. Alternatively, you can do the same by participating at startup events (an offline campaign) where you can target innovators, early adopters and maybe even get some investors on-board.

8.2 Measure your traffic

Keep an eye on your application’s traffic. This insight paired with engagement (see 8.3), will point you in the right direction when deciding on roadmap or marketing strategies for your product. In addition, it could give you a better perspective on scaling decisions and prevent service outages related to server resources.

8.3 Check on your service engagement

See how many users are actually making use of your app. The application’s traffic might be high but you’ll never get the full picture if you don’t know exactly how many people are actually using your service. These potentials are worth targeting when running those survey campaigns – their feedback contributes the most to improving your business logic and is highly relevant.

8.4 Count your sign-ups and application launches

Do not confuse these with your number of actual users. While sign-ups and application launches are a feasible way to gauge user interest, it is not always a metric that points to actual acquisition. Sure, new sign-ups may convert to revenue, but their actual role at this stage is to make your product more relevant for potential investors.

8.5. (Mobile-related) Crunch your app size and monitor your app downloads

Here’s an inalienable fact:  lighter apps generate more downloads > more downloads increase your sign-ups > sign-ups make your service more relevant > relevant services are more likely to generate usage and revenue.
The advice here is quite simple, the lighter your app, the better. MVPs are generally low-weight and this should not be an issue for your first versions – keep it in mind for the next ones though.

8.6 Measure Acquisition cost/ your users’ lifetime value and their Churn

Keep track of your product success metrics to stay in touch with your progress and steer away from icebergs. These are not quite hard to crunch but will serve as the ultimate selling point to eventual investors. We recommend measuring at least these 4 metrics:

a. The average revenue per user aka ARPU

– is exactly how much revenue is driven by an active user by average. The crunching is quite simple: just divide your revenue to the total number of paying users and you’ll get your ARPU. If the monetization model is powered by multiple revenue sources, just calculate the ARPU for each stream, sum those up and divide them to the number of streams to get your overall ARPU.

b. Client Acquisition (CAC)

is a metric assessed per each user acquisition channel and gives you a better perspective on which acquisition streams perform better and which perform worst. To get this metric, calculate the number of paying users as per channel, figure-out how much you’ve spent for each acquisition stream and divide those figures (users per stream/expenses per stream) to get your CAC.

c. Churn

– is a metric that shows how many users you’re losing per month. This metric must be accounted for paying users as well as per free memberships. Customer Churn is quite easy to calculate: divide the number of uninstalls at the end of a given month to the number of paying users at the beginning of a given month: (number of paying users (April 1st) /Number of billable uninstalls (April 1st – April 30th).

d.  Client Lifetime Value (CLV)

– is a metric that relates expected time a user will spend on the app before uninstalling it. This figure should be calculated from paying users only since it implies acquisition costs: CLV = (Monthly ARPU * Number of Active Months) / Churn. CLV is critical for building genuine revenue forecasts for your investors, so keep that metric at hand.  Make sure to use that metric to build retention strategies and target your churn audience to understand what made them leave in the first place.

If you’ll manage to measure at least the above, we can guarantee you’ll know exactly what’s your next move.

9. Drop it or move to the next-level

Avoid making decisions based on your feelings and put those figures to work. Startups that ignore critical metrics like churn or CLV will simply fail to build a constructive roadmap for their MVP.

Some might act on hunches, others will try injecting their own resources into their startup but at the end of the day, if these decisions are not based on numbers, you’re simply keeping a dead body on life support.

Check on your user’s feedback, crunch those numbers and decide – if your forecast looks great, if your traffic looks promising, if your active users are slowly growing, chances are you’re attracting investors and there’s a chance your idea is amongst those 10 lucky percent – otherwise: it is not too late to get out.

In conclusion, an MVP is as advertised: maximum value with minimum risks. Even when done right, there’s still a chance of failure but the entire experience of building it, still makes you a winner. At the end of the day, building an MVP might have given you the opportunity to probe your idea within live circumstances, obtain a draft for an eventual lucrative app and get rid of that “What if?” lurking within.

All of the above is not a success formula, but merely a minimum set of requirements in building an MVP (at least from our stakeholders perspective). If there’s an itching idea in your head and you need an expert’s opinion, reach one of our Project Managers – they’ve each took part in over a dozen MVP developments and would be happy to cover any of your needs.

We’d also love to hear from those lucky ones that have succeeded in delivering MVPs and are open to sharing their experience. Such input would enrich the learning environment we’re trying to power here and we’d be grateful for such contributions.