Wouldn’t it be nice to know if a project was going to fail after two weeks rather than two years?

By MARK RIFFEY for the Flathead Beacon

A new project idea is always exciting. You think you have a great idea that’s going to take off in your market like gangbusters and you can’t wait to get started. In fact, the gravitational pull of this new bright, shiny object might be so compelling, you might discard all encounters with reality and start without doing any sort of market research, perhaps even setting aside real paid work that has stacked up.

As you might expect, I have another suggestion: use a concept called the minimum viable product (MVP), which is part of process called “Lean Startup“. While this originated in the software world, the process of developing a MVP can be used in ANY business.

Let’s talk about what usually happens to a new project idea.

New project idea development

While the minimum viable product concept took root in the software business, it can be used ANYWHERE.

Let’s take a brief look at the old way. I’ll discuss it in the context of the development of a software project, but this can happen during the development of any new project idea in any business.

The Lean Startup world relates primarily to software startups. Lean Startup recognizes the history of software project development over the decades and that it’s had a high failure rate. This failure rate quite often happened because software development often looks like this:

• Software people get an idea
• They determine what they believe to be the perfect solution and fall madly in love with it.
• They run into a room for two years (or longer) to develop it, and work incredibly hard to produce this perfect solution to fit their idea or problem they’ve identified.
• After years, they emerge, sweaty and victorious, having completed some portion of this perfect solution

These developers might emerge from their self-imposed development exile having become chest-bumpingly-giddy about their victory, only to find that they built something in a vacuum of customer feedback and the customer finds the solution misses the mark – often by a wide margin. Either it solves a problem the customers don’t care about, or it addresses a problem in a way that makes little sense to the customer, or the customer thinks it’s workable, if only the software people can make these 247 changes to how it works.

Making those 247 changes might take longer than the initial development, might cost more than the initial development, may not have management support, and idea doesn’t do much for a team of software people who became quite misty-eyed over the baby they worked on for the last few years.

Minimum viable product does away with running into a room for two years, and with creating what has universally become recognized as a danger to new and existing businesses: a vacuum of customer feedback.

Test, gather feedback, repeat

The Minimum Viable Product process is a rather efficient, mostly emotionless process for getting to the root of the problem and to the solution that best fits the customer. It looks something like this:

• Talk to clients.
• Build what you think they want – but build the smallest possible solution that emerged from the conversation about the problem or idea.
• Place it in the client’s hands as soon as possible. If you can make this happen in two weeks or less, do so.
• Watch them use it, ask them how they feel about it, ask them what they like, don’t like, hate, love, etc.
• Go back to work, leverage their feedback and quickly make changes based on the discussions you had.
• Repeat as necessary.

During your feedback sessions, ask them if they would pay real money for your solution and let them do so if they say yes. If they won’t pay for what you’ve shown them, you need to reconsider further investment in (or the direction of) the project.

Rather than two years (or some other long, expensive period) of product/service development, you might have two to four weeks invested. It’s better to find out that you’re on the wrong track earlier, rather than later.

Want to learn more about this process? There’s a free course at Udacity that will take you through the process and teach you how to do it yourself. https://www.udacity.com/course/how-to-build-a-startup–ep245 

You don’t have to be a software startup to use this process. It works for almost any project.

*****************

Want to learn more about Mark or ask him to write about a strategic, operations or marketing problem? See Mark’s site, contact him on Twitter, or email him at mriffey@flatheadbeacon.com.  Check out the Flathead Beacon archive of all of Mark’s blogs.