Skip to main content

When Building Your Website, Call In Your MVP; And I Don’t Mean Your Most Valuable Player.

By February 15, 2012June 26th, 2015Marketing Insights & Strategy
When Building Your Website, Call In Your MVP; And I Don't Mean Your Most Valuable Player.

If you are running a business chances are you either have a presence on the web or will in the future. For many businesses, especially those just starting out, a simple out-of-the-box website solution may be all that you need to meet business and marketing goals. But for other businesses looking to capitalize on the strengths of the internet and emerging technologies, a custom website or application can be far more worthwhile.

Custom websites and apps provide many benefits, including customer service functionality and business management capabilities; they can help reduce human resource time spent on recurring and repetitive tasks; they can offer a service to your customer base that you otherwise wouldn’t have been able to provide; in short, a custom app can help your business grow and establish your brand as a leader in your industry.

Making the transition to a web-based app is easy for some and difficult for others. It depends in part on your resources, goals and budget, but there are ways to avoid spending loads of cash on specialized labor to end up with a web product that does not yield a return on your investment.

Start With Planning

I build web applications. Some of them are small, some of them are big, but they all have one thing in common; they always start with a project specification. Whenever I engage in a new project, I begin by documenting the needs and goals of the project to the last detail.

The specification can take many forms depending on the scale and complexity of the website or app, but at its simplest, it provides a roadmap for my client to know what they are investing in.

This is also the first place where the wheels can come off a project. If goals and expectations are not managed, the project can scale to a size that is cost-prohibitive and useless to the organization.

Enter The MVP

My solution to this is to let the MVP drive the process. No, not the Most Valuable Player; the Minimum Viable Product. Every project has a goal, but without knowing what the bare minimum requirements are to meet that goal, it will be difficult to achieve.

For instance, you can build a house with many different products and materials, but no matter what you build with, you still need a foundation. Your project’s foundation is the set of features that are essential to your business and to your customers – and no more.

All of the apps I develop have another thing in common; they are all iterative. That means that they launched in one form, but evolved over time into another. Small improvements applied strategically make a good product better over time and allow end users to offer praise, critiques or complaints that can be measured and converted to actionable initiatives.

You can – and most likely will – scale from there, but at that point you are adding value, not meeting essential requirements. Adding value isn’t a bad thing, but value means labor and labor is gonna cost ya. If you have an unlimited budget, adding value may not be an issue, but nowadays small and medium sized businesses do not operate with unlimited budgets.

Remember, The Only Good Feature Is One That Your Customers Use

There are other advantages to an MVP. Many organizations have built web products only to find that their customers only use a fraction of the features. If those features go unused, then your money has been wasted. By releasing an MVP you can measure and track feedback and build features based on demand.

Some may not like this approach because it is reactive instead of proactive, but consider the feedback you get from customers after launch as an opportunity. If they tell you that your product is lacking in some way, build in the features your customers have asked for. In this scenario, you’ve saved yourself the expense of creating unnecessary features, while creating the perception that your organization is adapting to the emerging needs of your customers. It’s a financial win as well as a public relations win. Ideally, that cycle – analyzing your users’ needs and making improvements – should go on for the lifetime of the product.

Of course, even without user interaction, there should always be iterative improvements. Security alone is a moving target. Creating a web product and leaving it untouched for months and months is only asking for trouble. And as technology and hardware improves, you may find that there may be hardware solutions emerging to meet your software needs and visa versa.

Every website, web app or even social media endeavor should be considered cyclical. First, you establish goals; then an MVP specification is designed to meet those goals. From there you build, test and deploy and then the cycle starts over again. Your customers and technology will evolve and so should your web presence.

Here are a few things to consider when developing your MVP:

  1.  What features are crucial to your customers?
  2. What features are crucial to your business?
  3. What features are tied to revenue or conversely to expenses?
  4. Do you have a roadmap for your MVP and future iterations of your site or app?
  5. Do you have a mechanism for your customers to offer feedback?

A good developer will tell you that planning is important above all else. Without proper planning and discussions there can be no efficient development. When you engage a developer, ask questions and then ask more. Make sure that he knows what your business needs are so that he can architect technical needs around them. Avoid “feature bloat” at all costs; this is when unnecessary features are added to the specification because they are “cool” or for some other vague reason that does not align with your business needs and MVP.

And Did I Mention Planning?

The most important rule upon developing a comprehensive MVP is to make sure everyone is on the same page. Literally. Make sure the specifications for the MVP are in writing and that everyone has the same perspective on production. It helps no one for a developer to build one thing when the client expects another.

Finally, ask “why?” Why are you adding a particular feature? Why are you omitting another? Question everything about the project and make sure that there are solid, unambiguous answers to all of them. This will lead to a smooth development process and a smooth launch.

Technology is imperfect and there will be bugs along the way. Better to avoid whatever pitfalls you can because software development is not cheap or easy.

If you have a project you are working on that does not have an MVP or has created a little internal horror story for your organization, let me know. I’d love to hear your stories.

Don’t forget to sign up for our free newsletter for more insightful articles like this one. And before you go, follow me on Twitter, LinkedIn or Facebook.