By understanding what the product idea is as opposed to how it’s implemented.

It’s amazing how many people think you can’t test an idea without tons of effort. Say you had an idea of selling shoes online. You need an IT team to make a web site, a manufacturer, and a distribution center right?

Well yes you do. But the website can be pictures of shoes and a form that sends you an email. The manufacturer can just be the local shoe store. The distribution center can be your kitchen table and a few postage stamps.

How is that a test? Well if the problem is that no one is ordering shoes you have a result. If the problem is that you’re spending to much time in your kitchen mailing out shoes you have a result.

This test proves whether people will buy shoes online. It gives you the kind of data people who might invest in your business care about.

There is only one answer to this question: build a prototype as quickly as possible! Prototyping means you skip on unnecessary and unimportant parts such as configurability, proper error handling, etc. and just test whether the core idea works. Don’t bother documenting and/or commenting the prototype code well, as the prototype is anyway designed to be discarded. If performance of the software is unimportant, I would advise to use a modern high-level interpreted language such as Python. However, performance may be a core part of the product, so in some cases a JVM-based language or either C or C++ may be necessary.

Do, however, allocate time for reimplementing the entire thing if the prototype is chosen to become the product. We at work omitted reimplementing the prototype for some of our code, and it has caused major amounts of pain because the prototype with low code quality and omitted error handling has needed major amounts of work to effectively function as a product.

You can’t test, in the true sense, a product before you have built it, but you can:

• Mock up the look and feel with static images or even video
• Describe the behaviour to potential stakeholders in documents &/or videos
• Prototype UX and behaviour so as to demonstrate what it might be like

You could start by building a minimum viable product — the smallest, simplest product that you might be able to convince someone to pay you for. This could be a barebones tool integrated into your users’ existing workflow that provides some benefit to the user to justify the additional effort. A good example of a piece of software I use that evolved this way was You Need A Budget, which started life as an Excel/OpenOffice spreadsheet before becoming an independent application.

One way you can think about an MVP is as an initial step towards a lean startup approach, in which your initial MVP is just the first iterative step towards your final product: you share this MVP with a few users, collect feedback on which users benefit most from which feature, then “pivot” to create a new MVP that focuses exclusively on those users and their needs here — the goal being to focus not a large group of potential customers who want your product, but on a smaller group of customers who need it, and so would be more likely to pay for it. Building an MVP can let you test multiple product ideas before zeroing in on the one most likely to be successful.

A well-known example of a product that developed in this way is Flickr, which started life as a video game before becoming a chat room before becoming a photo sharing site.