So… your brilliant idea for a web or mobile application is going to completely change the way consumers or businesses [fill in the blank]. Great! But the days of investors cutting checks for ideas with zero validation are a fading memory.
Today, investors more often commit money to scale companies than for initial market and customer testing. Therefore, the best first step for many startups with an idea for a B2C or B2B software application is to build a Minimum Viable Product.
According to CB Insights, the number one reason startups fail isn’t lack of cash (though that’s a big reason). ‘No Market Need’ (i.e. you created a solution in search of a problem) tops the list. This reinforces the importance performing comprehensive customer and market research as part of the MVP process.
Plenty has been said about the purpose, value and proper timing for building an MVP. I stand firm in the belief that MVPs are meant to generate ideas, test assumptions and minimize risk.
There’s room to debate how to approach building an MVP, but once you commit, be aware of a few main areas that determine whether a large majority of projects succeed.
The following are three common mistakes to avoid:
1. Assembling an incomplete team
Traditionally, co-founders that are software engineers or developers accept equity for the expertise and services they offer to bring an MVP to life. However, for many talented programmers, it’s undesirable to gamble on an invalidated idea that’s not even theirs.
Additionally, the number of non-tech entrepreneurs looking for technical co-founders vastly outweighs the reverse.
Therefore, if you lack the required programming and design know how or internal team to build an MVP, then finding a technology partner that can provide the right team is paramount to your project’s success.
Having the right team to handle the technical responsibilities and challenges not only increases the chances of success, it allows you to focus on other aspects of the business – without giving away equity.
A common misconception is that it takes just a developer and graphic designer to build a successful MVP. However, building an MVP is just like building any other piece of software and requires a full skill set including UI/UX design, frontend and backend development, system administration, and QA and project management.
Very rarely these skill sets are combined, and almost never single person can handle all of that.
While MVP development time is ideally a few months (some say any longer than 90 days is a recipe for problems), there are many crucial crossover points from design to development that require cooperation from the whole team to ensure smooth sailing.
Whether serendipity is on your side and you can assemble an internal team, or you need to find a technology partner, having experts able to deliver all the required technical responsibilities and skills needed to plan, design, and build an MVP is a key element of early success (think Ocean’s Eleven).
2. Mismanaging the prototype phase
The prototyping phase is an important part of the overall development process that should not be skipped and provides you with a number of business benefits. By thoroughly planning and creating a high-fidelity prototype, you can bring your project’s ideas to life with an interactive model, reduce risk and remove ambiguity.
Some of the main areas of MVP prototyping are:
Interface architecture: This focuses on building the base structure, as well as the information and interaction foundation of your application.
Low-fidelity interactive prototype: This consists of low-fidelity wireframes that map out your application’s information architecture and shape and include interactive elements.
High-fidelity interactive prototype: This includes high-fidelity graphic images and will have a number of interactive elements that allow you to navigate your application.
Production design: By this phase, all internal and external feedback will have been implemented. In order to make the transition into development smoother, your prototype’s graphical elements will be prepared for development.
It’s easy to feel like a kid in a candy store when deciding which features to include in your prototype.
Prototyping isn’t just about making your MVP look pretty, and it’s important to tie every potential feature to a real benefit for the end user.
Think about how each potential feature enhances the user experience. This should come from analyzing the results from your initial customer and market research, as well as understanding your goals and core business. The quickest way to botch a prototype is to include the wrong features.
Some common features to leave out of an MVP include:
Bell and whistles: These are best described as features that have no real purpose except to look good and don’t add real value to the MVP. An example of this is social media integration, which looks fancy but rarely adds value to most MVPs.
Me too: Competitive analysis is important, but don’t automatically add a feature just because the other guys have it. When it comes to building an MVP, trying to keep up with the Joneses often just adds time to the development phase. Stay focused on your application’s goals.
Upon request: Even though a major point of building an MVP is to garner outside input, it can be a mistake to rush into adding every feature to a prototype that early users request. Implementing requested features should be based on research and analysis – not a knee-jerk reaction.
3. Choosing the wrong development method
As with any application development project, MVPs can be built primarily using one of two methods: agile or waterfall. The pros and cons of both approaches for software development have been widely discussed.
Ambysoft’s 2013 Project Success Rates Survey concluded that the agile method has a 64 percent success rate, compared to just 49 percent for the waterfall model. When it comes to MVP development, my take is that agile is far superior to traditional waterfall methods in terms of quality and time to completion.
Another consideration in the development process if you’re working with a technology partner is paying an hourly rate versus fixed price.
The waterfall method is usually based the fixed price model and may be appropriate for certain types of software projects. Agile methods are usually based on hourly rates.
It may not seem like payment structure could affect an MVP, but just like working with a contractor on your home, it can significantly affect the relationship with the dev team and even the project’s outcome.
For building MVPs, the main benefits of the agile/hourly rate are:
Transparency: This method provides you with a better understanding of the project’s progress as you can see how much time has been spent on different part of the MVP and what the results are.
Flexibility: With this method, developers can take a progressive approach to development. The need for flexibility is a common part of software development and the ability to change direction when required is essential to MVP success.
Speed: With this method, developers don’t have to spend as much time planning to avoid risk and can start working on the project earlier. Developers deliver the product in incremental sprints typically two weeks that can be reviewed and tested. This method quickly provides working features and valuable feedback to will go into finishing the MVP.
Beginning with an MVP is the first pillar of success for many startups today. With thorough planning and awareness of the common pitfalls that come with building an MVP, you will greatly increase your odds for success – not only in the MVP itself, but your entire product idea and business.
One final note: don’t give up too fast. The purpose of the prototype and MVP is to test, gather feedback, evaluate and learn, improve and test again. This cycle may take a while until you get it right.
This article was originally published on The Next Web on the 12th of April, 2016.
