Back to Blogs
Building Your Minimum Viable Product
by Jase Oct 15, 2018
Ahmed xd 703570 unsplash

Minimum viable products paired with agile development methods means product owners and product marketing managers have to go to market with a working, although not ideal product. Often, product managers, software development teams and marketing teams don’t agree on when the product is ready to launch. Maybe it’s a case of semantics, but great product owners need to be able to define the minimum in MVP products accurately and properly manage expectations about their launch and functionality. The last thing any marketing and product team wants to do is go to market with a half-finished new product or feature, damaging the brand, and wasting ad spend on something that’s not complete.

What is an MVP

Alt Text


An MVP is a product with basic, but core functionality. Customers are expected to pay to use it. An MVP should be stable, and shouldn’t be prone to crashes and other technical issues. An MVP is also part of an initiative to get feedback from users on the functionality and design of the product. An MVP is a lightweight, pared-down version of the solution you’ll eventually build. It’s possible that all the code and designs will need to be re-done for the completed product, the odds are that the MVP starts as the base, and more features and robustness are built in there after the idea is validated.


The MVP is a viable product, that you are testing to validate its feature set, pricing and need in the market. The minimum represents the minimum spec that’s required for the product to work.

Why do an MVP


A few of reasons why organizations have begun to rely on MVPs when building products.


First, you get the market to validate your idea and product. The amount of early data you gather become invaluable to building your roadmap and product down the road,


Second, with many organizations using agile development methods, products are being built iteratively. Gone are the days of a complete product release. With agile, the product is in a constant state of change and improvement, as all software should be.


Third, MVPs are low-risk ways of testing an idea. Whether you're established in the market or just starting, an MVP lets the market guide the development and usefulness of your solution. Without investing too many resources, it’s easier to cancel the project or pivot.

Beta v MVP

Alt Text

The minimum viable product is just that, a working product. A beta phase is designed to test and iron out any bugs and kinks before you launch. Just because you’re doing an MVP, doesn’t mean you should forgo the beta. And inversely just because you’re planning on a beta testing phase doesn’t mean you should build a complete product before seeing if the market is interested. Thanks to Google, software companies are becoming more daring in how long they release and beta, and who has access. The beta tag can now be slapped on an unfinished product to excuse lack of functionality, bugs and design flaws. In essence, Google has users testing out betas for an indeterminate amount of time. Ultimately, this means that customers get a less finished product. You’ll never want to outwardly tell a customer that the product they are using is an MVP because it sets the wrong expectation. Ideally, the product would be labeled as a version one, or appear as a feature in your existing product before being spun out into a full blown ‘new’ product.


An MVP should never be released without some type of QA and testing phase beforehand. And an MVP isn’t an excuse to release a product with a bunch of bugs.

Setting the minimum requirements for the MVP

Alt Text


Setting the minimum requirements for the MVP is critical to have successful proof of concept. Not enough functionality and the MVP may be a flop not for the lack of vision but the lack of execution. Too much functionality and the investment and cost run too high. If the MVP doesn’t work, you’ll be left explaining why your MVP cost so much and failed. Neither situation is favorable for a product owner, or an organization.


The critical task to complete before setting out to define your MVP is to speak with potential customers and do a competitive analysis of the current product offerings on the market. This will do two things: first validate which aspects of the MVP are most important, second, ensure that you’re not building something which the market already adequately addresses.


Validate with customers by conducting customer validation surveys. There are many formats in which they come in, from Jobs to be Done, the Lean approach, the idea being that you’re 100% sure you’ve got the right problem your customers will need help starting.


Once the problem is defined correctly, you can either start building the MVP or if the project is a bit more complicated, relying on Invision (or similar) to create ‘functional’ prototypes for another round of validations.


After the validations are complete, and you’re sure of the problem your solving, the scope of the problem, and how it will impact your customers, then you can set out to build your MVP.


The notion that ‘we think customers will want this, so let us just build an MVP and see’ is a massive distraction and a large gamble. MVPs just like another feature or product should be validated with some type of customer or market data that supports the assumptions being made in the organization.

Your MVP isn’t the end product.

Alt Text


An MVP isn’t a perfect product that meets the needs of 100% of your customers. The MVP is a product that solves a specific niches problem while being functional enough to use without encountering technical difficulties. That means particular integrations, functionality, and designs might not be 100% perfect at launch.


Getting a working product into the hands of your customers is the primary goal with the MVP. Being able to validate the product idea, and generating revenue will allow you to see how much of an impact this new product can have on your organization.


Once the MVP is validated, either by sales metrics or through positive customer feedback, work can begin on creating a more robust version. Either your product team will do a rebuild of the MVP to make it more robust and scalable. Or they'll begin working on non-core functionality to make it a more marketable product. The next step is to start building on the other features that bring your MVP into a more robust and feature-rich product.

Launching an MVP

Alt Text


One of the most challenging parts of building an MVP and agile, in general, is that it’s difficult to draw a line in the sand for a marketing campaign. Ideally, you’ll pair an agile development process with an agile marketing process (another topic, for another post).


In my opinion, an MVP launch should fly under the radar. It’s something for your customers to discover, where expectations are set lower so that your customers can come away impressed by the solution your providing to their problem. If you’re marketing team pulls out all the stops customers may leave disappointed in lack of functionality. I think we’ve seen a lot in the world of VR fall victim to this. Companies like Magic Leap have promised the moon, and have failed to deliver. I understand hyping a new idea and product, yet sometimes, we’ll see it go too far where users end being frustrated by delays and other problems.


For an MVP focus on a lighter marketing launch. Speak to your current customers, make sure the messaging and ad targetting is tighter and focused in on the persona who will benefit most from the problem you’re solving. Don’t change your homepage, don’t spend money on OOH ad campaigns, don’t crank-up your add spend on something which may not generate revenue. Once you’ve validated that the MVP is a product which the market wants, then, and only then, is it worth it to invest more regarding marketing.


Many companies opt to create unique hidden landing pages for their MVP products in order not to dilute the brand. If your MVP is your first product, then again, keep the website and messaging simple, clear and focused on your persona and the problem your solving.

MVP is a compromise


MVPs are compromises. They are by their very definition minimum products, and your organization should never be happy enough with the status of an MVP product. Either you’re going to continue to develop and build on the product, or you’ll need to pivot and make the changes your customers are asking. The key to remember is that an MVP is not a satisfying or completed product, it’s the foundation to something bigger, and better.


Need help building your next MVP. Get in touch with us today to get a free consultation, and to discuss how we can work with your team on your next great idea.

Never miss an insight!
Occasionally receive useful information and tips. We won’t spam your inbox.
Subscribe