How to Design an MVP (the right way)

Ventive works with a variety of clients including tech-oriented startups and transforming enterprises (companies updating their processes from analog to digital) in need of a technology partner to provide technical and strategic leadership for designing, developing, and launching digital products and software applications.

Most of our clients come to us for end-to-end product development, some send us an RFP for software development, and other clients don't find us until they've already begun or completed the design phase. While we're happy to work with other talented designers, I've noticed that Ventive has a different approach than a designer might take...

Successful Product Development Starts with Three Letters: MVP

While individual designers and developers are essential contributors to the overall process, successful product development rarely happens in a vacuum of specialists.  As a full-service agency, Ventive is focused on user-validated requirements and building out an effective minimum viable product (MVP) to find market fit. We should never allow product to be driven by design alone!

“Only build features that your users want. It's a simple rule, but it's difficult to get right. It takes discipline to ship a bare minimum MVP, and then let your users tell you what to add.”  -Andrew Van Hook, Director UX‍

In the fast-paced environment of building software, where Lean-Agile principles are touted for their ability to go-to-market first, more efficiently, and most effectively, building out every conceivable screen on mobile and desktop for all primary and secondary stakeholders may not be the best approach.

Before we begin designing a product, Ventive aims to gain full understanding of the market's needs:

1. What problem are we solving?
2. Who are we solving it for?
3. Is the problem defined by the market the same way it is defined by our client?
4. Who will use the product (most)?
5. Who are the buyers and how will they justify the purchase?
6. What already exist in the marketplace that solves a similar or related problem?
7. Which features are vital to the product's success vs. which features could be saved for a future phase?

Let's look at this in greater depth:

1. What problem are we solving? Simply put, if it ain't broke, don't fix it. There must be a clearly defined problem by a clearly defined audience and it is best if we understand the problem in the same terms, from the same perspective as the client. If we approach the problem from the outside looking in, we risk taking the wrong approach and missing the mark.
   ‍
2. While it may seem redundant, differentiating between who we are solving for, who will use the product most, and who is the buyer is an important exercise.
   
   Think about a CRM: A CRM is designed to make sales teams more effective (who will use the product most), but it could be argued that it primarily solves a problem for sales managers who are trying to make their teams more efficient. On the other hand, the buyer may very well be a CEO, CFO, or VP of Sales, depending on the size of the organization. Thus, we need to build a product that sales teams will actually use and enjoy, but we can't forget about management's needs to measure and evaluate sales activity, nor C-suite's demand for an ROI (and ability to see it) when formulating the product. If we do, we run the risk the product will be deemed an "an expensive toy", and become slated for non-renewal.
   ‍
3. Lastly, understanding what already exists in the marketplace is vital because it can help us determine if there are potential strategic partnerships or integrations which could fulfill a major features set, thus increasing speed to market, reducing initial costs for production, and opening up a partner channel with ready-to-buy customers looking to enhance their current software.

Ventive's Team Approach to Product Design

Considering these variables, does it make sense that we can't simply design representations of a product around features and general ideas of user needs and preferences? Product design goes much deeper and requires a team of people with different focuses and skillsets:

• Planning
• User research & testing
• Product management
• UX Design
• UI Design
• Technical architecture
• Development
• Quality Assurance
• Go-to-market

When building a software application, mobile app, or even when compiling a software rfp, whether with a full-service agency or an individual designer, it is in your best interest to engage with the full team you plan to hire upfront in order to form a cohesive and laser-focused approach to readying your product for market. Anything less likely means wasted time and money.

Ready to build an app with our team? Visit us at our downtown Boise office, or set up a virtual consultation today.

‍