Building a minimum viable product — something that can show what you want to do to prospects and perhaps even start bringing in a little money to help you fund the development of a bigger product — makes a lot of sense. It’s especially useful when your product is solely the result of the hours you spend at the computer: minimizing those hours to test the basic concepts means that you can discover what does and doesn’t work a lot faster.

But deciding on just what you’ll offer as your MVP isn’t always easy. Some projects have a small core component that you’ll have to build anyway to get started, making for a quick decision. But many projects have a lot of moving parts and it’s not always simple to decide which parts need to be tested first. These tips can help you make a decision.

1. Make some lists. It may seem old-school to just sit down and think about your product, but write out a list of the reasons the full product will be attractive to your customers. Create a list of the smaller pieces of the project that you could complete without building the whole structure, and note the pros and cons of using each piece as your MVP. Don’t limit yourself to what you can build, by the way. If you can mimic the function of an app by hand for your users or rely on a couple of APIs to get started, include those options.
2. Schedule interviews with your ideal customers for the full project. Unless you are also a member of that audience, it’s hard to tell what you’re assuming to be true and what that audience actually believes. Take your list and start asking questions. You may find that one small piece of your project is exactly what gets that audience excited.
3. Put together a short plan for actually building each of your contenders for MVP. Some options will be more minimal than others, at least in terms of what you need to build to make it available. Consider details like whether you prefer test-driven development and how they might slow certain options down.
4. Plan how you can test and gather data about the finished product. If you can’t find out how audiences respond to your MVP and what you need to change, then you’re not looking at a practical MVP. This needs to an experience you can easily learn from.
5. Decide what part you’re excited about. The coding always goes faster when you’re working on something you actually want to finish. If a lot of your potential MVPs aren’t exciting you, skip over them to something that you’ll be happy to put extra hours in on.

Image by Flickr user Gangplank HQ