These represent the context of the existing market that any new product will need to operate in. From that, you should be able to enumerate the areas where existing solutions fall short as well as where they do well. Both are important. (A spreadsheet app like Numbers or Excel is a great way to capture and organize this detail into a working outline.)

With that as a guide, create an outline of what capabilities your product will need to include, those you are consciously deciding to omit, and some potential ways to integrate your product/service into existing market workflows. Socialize this with trusted people in your target market, and use that to further refine what you are looking to do. This process should give you a more refined and focused definition of what your MVP should include.

From this, you should be able to estimate how much time it will take to develop your MVP, and line that up against the amount of time you know you have left (given your available funding, resources, burn rate, etc.) to execute on it. These need to be honest time assessments – and even then you will almost always underestimate the time it will take to develop something. In all of this, you really need be thinking MINIMAL. Keep trying to identifying the basic elements of value that you should try to deliver vs. the minimal version of some grander vision you’d ultimately like to achieve. Don’t be afraid to prune anything you find isn’t a necessary part of your key value proposition. Both your potential customers and your competitors are always in motion, so minimizing time to market is very important.

If your product is in a technical area, development should be built around an agile process, composed of short sprints that result in usable functionality. You want to be getting market feedback on various capabilities as soon as it comes out, so develop a good relationship with some people in the market that will be willing to test and comment on these early builds. Use their feedback in defining the goals of your next sprint. Keep in mind that if you can’t find anyone willing to do this with you, its possible that the opportunity you are looking to address might not be as significant as you think it is. If so, it may require more thought before moving ahead.

In addition to giving you incremental feedback, this “early engagement” process can also help you figure out when your MVP is finally ready. When the people you are working with begin to integrate your sprint releases into their daily workflows, you are probably there.

Package it up and make a release!

Keep in mind that defining an MVP isn’t a formal process – it is an organic mix of assumptions, validations, and feedback – all refined through iteration with the market. You won’t get everything right, but that’s OK. The goal is to deliver an initial product that provides some core values that are compelling enough for people to be willing to overlook any areas where it falls short. It can get better from there, guided then by real world usage and feedback.

The harsh reality is that no matter how much thought and planning goes in at this stage, you’ll never be sure that you’re building something viable until you have enough people in the market using it. And to do that, you need to ship. Don’t be sloppy, but don’t over think. Your strategy should be to research intelligently, ship quickly, learn incrementally, and iterate often.

This can’t be done in a vacuum. You can’t approach this as an intellectual exercise – it isn’t about servicing a market in the abstract. To be effective, you need to become a part of the market – and engagement and understanding need to be the cornerstones of everything you do.

I’m sure many of you have gone through this process at some point. Please feel free to share your own experiences around developing new products, and any lessons you think might apply.

My thanks again to J. D. Farmakidis for motivating this post. Hopefully this did a reasonable job of answering your question! If not, let me know…