Now that you know and trust your idea, it’s time to get that first marketable build ready. You may be familiar with the term MVP, or “Minimal Viable Product”. In short, once you know your idea and your market, it’s time to boil it down to a set of features that would be acceptable for launch. Quality in your core features will get those early adopters in, and those folks are going to be able to give you feedback on what works well, and may even drive some traffic to your app.

Focus on and iron out your Core Features, your full feature plan can be implemented as the app evolves.

Now that we know our goal, we believe in it, and have a core set of features coming together, we need a platform to push off from. “But hey, my app is definitely going to secure funding to get onto 8 different platforms right from day 1, I know our scheduled release was 9 months ago, but you can’t rush quality!”

Going multi-platform could be a huge boon…. eventually. More likely, you will wind up fixing bugs and reworking features several times at once in completely different environments.

Keep your build open to expansion down the line, but be patient. Once your idea is actually functional one platform, then it’s time to use that foothold to expand to other markets. Until then, your resources are better spent on polishing your flagship.

Growth comes first.

Next, we come to another scary rabbit hole, however, this is one even the big guys make with surprising regularity.

You may be thinking that the only thing investors care about is Money, right? No. Not at all. In fact, most successful investors care about long term stability first and foremost. As such, remember that focusing on only profits may actually be what scares off investors down the road. This focus generally tends to the deterioration of core features, a negative customer experience, and will ultimately just lose Brand Value in the long run.

Lastly, your idea needs an Expiration Date. You need to pick a concrete date as the finish line for your app. This helps to home in on making your MVP, knowing what to cut, and when. All of this will assist in avoiding the unfortunate road to development hell, and heartbreak that comes with it.

Pick an End Date. Stick to it.

To understand what a minimum viable product is we first need to establish some context. Before MVPs became commonplace most start-ups spent their time, often years, developing in secret fully realized, fully functional applications, which they then released and attempted to sell.

This approach is, at first blush, quit rational. If you were building a car wouldn’t you make certain every single system needed to make the car function as optimally as possible was in place before you sent models out to dealerships? You wouldn’t include wheels but no engine. You wouldn’t install a driver’s seat but leave holes in the floor where passengers might sit. You would build a finished car and then attempt to sell it.

The problem with this approach is that, assuming you don’t run out of seed money before bringing your product to market, you have no idea whether the product you’ve built for your potential customers is the product they want. Developers are smart people, certainly, but they’re not mind readers. It’s entirely possible that after years of development that shiny new product they’re proudly parading out to customers is a lemon, a spiffy, feature-rich failure that no one wants and that no one will ever buy.

A minimum viable product attempts to short circuit this quagmire of uncertainty by getting something in front of potential customers as quickly as possible in order to learn as much as possible about exactly what sort of product these customers need.

Put simply, the first version of your product doesn’t need to have every single possible feature implemented fully. It just needs to have a minimum subset of features that allow it to be useable by a portion of your potential customer base. This group, generally early adopters, is capable of understanding your vision for the product even in an incomplete form. As long as it possesses a rich enough feature set to allow it to address the central problem your product is designed to solve these power users are willing to overlook missing functionality. They’ll use your product and give you feedback. You can then use this feedback to improve your MVP, add features and then iterate.

In order to understand how this works let’s return to our car analogy. Imagine they don’t exist and your start-up is trying to solve the problem of how to move people around quickly from place to place. Instead of designing an entire car from the ground up as we did earlier in the article we could instead develop a car MVP. We need only build a product with a minimum feature set to solve the proposed problem. We might take a plank of wood, screw axles onto the front and back and add some wheels.

Bingo! We have an MVP that moves people from place to place quicker than they could if they walked.

It’s car-like but not yet a car. It is a glorified skateboard at best. It fulfills the basic problem we’re trying to solve, so we roll it out to customers (no pun intended).

They buy it, try it out and give us feedback.

The early adopters generally like it but they tell us, among other things, it isn’t fast enough, it’s difficult to steer and they’re not fans of having to stand up.

We have feedback! We just learned very useful information about what our customers want without spending years building a fully realized car. So now we take that data and iterate. Maybe we add in a seat, attach the wheels to a steering mechanism and install pedals to allow faster movement. It’s still not a car. But Release. Get feedback. Iterate.

In the next version of our car MVP we replace the pedals with an engine. Release. Feedback. Iterate. We go from two wheels to four for increased stability. We enclose the passenger area to keep out the elements. Iterate. We improve the engine for greater horsepower. Iterate.

You get the idea. By the end of this process we have a function-rich, fully realized car built incrementally with constant feedback from our end users. By the time our car is released we’re about as certain as we can be that it’s exactly what our customers want because they’ve been involved throughout the entire development process.

In a nutshell, that’s MVP. Products are developed with only those features that are absolutely necessary for the savvy user to get it and give us feedback on how to proceed. After multiple iterations, each round improving existing features and adding new ones for testing we arrive finally at a finished product that does exactly what it needs to in exactly the right way. We know our customers will buy it because in a very real sense they helped develop it.

We started this article off talking about how many people interpret “minimum viable” to mean, “requiring the least amount of effort possible”. This misunderstanding has led to some pretty lousy MVPs because their creators focused too much on “minimum” and not enough on “viable”. They didn’t put enough effort into thinking through exactly what their customers needed from a minimum viable experience in order to see the vision and appreciate what the product might eventually do for them.

As a result, a contingent of thought leaders in the industry have called for a nomenclature shift. Instead of “minimum viable product” they’ve coined the term “minimum awesome product” or MAP. This new way of thinking better captures the spirit of the MVP. It isn’t about delivering a barebones experience that leaves your customers confused and dissatisfied. It’s about providing them a great experience, built with just the features needed to test the current product hypothesis. Your MAP/MVP isn’t complete. That’s explicit in the idea. But it shouldn’t FEEL incomplete.

I am not a fan of this kind of visuals as example, because that is kind of cliché, however, like they say, it is a cliché because it is true!

Again, think of the car companies. Every company tries to lure customers by offering a better model than their competition at an almost similar price. If they don’t do it, how long do you think they can survive?

The same logic applies to your startup. If you are trying to build a product where competition exists, you have no choice but to make it awesome. Now, that doesn’t mean that you need to spend drastically more efforts, time and money on making your product awesome. It all starts with planning and research. You need to keep your user in the center and then start thinking around their pain points and possible solutions. In other words, listen to your users and focus on delivering an awesome user experience. It won’t cost a lot, but the number of users adopting for your product will definitely be significantly higher.

MVPs, or MAPs if you’re feeling saucy, are the best way for a start-up interested in controlling costs to deliver quality products that they know their customers are interested in. And now that you understand exactly what goes into an MVP you’re ready to get your team working on one for your customers. So get started, and happy iterating! If you need help defining your MVP, feel free to schedule a call with our experts.