Our answer is a series of twenty questions that will help you develop and refine your software product idea. See below for the first seven. We also cover these in our workshop Idea to Revenue, that gives you the time and tools to develop and leave with a one page plan.

Q1 What is the product or service?

What is the problem you solve?

What benefits do you offer?

Do you help save cost, save cycle time, save material, improve quality, reduce non-value-add people time?

Q2 Who is the customer? What is the size of the market?

Who is the buyer who makes the final decision? What are they responsible for ? How are they measured?

Who else has to approve or has influence?

Who actually uses it?

What kind of company, in what industry? Are there are other key attributes?

What pain, problem, or need does the buyer have? What problem do you solve?

What are the symptoms or characteristics to look for in a company that would indicate pain or a strong need?

Q3 What are the “must have” features? (Primary Buying Criteria)

What are basic features that you must have to participate in the market

What are differentiated (leadership) features that set you apart from existing solutions

What features do you need to minimize the switchover costs associated with using your offering: can they use your product or service in parallel with existing solutions and go back?

Q4 What are the “should have” features? (Secondary Buying Criteria)

What features would provide further differentiation but are not worth slipping the release for.

Ideally there are just a few “should have” features and these define what the develop team should focus on if they cannot assist with a must have feature.

Q5 What are the “nice to have” features? (Emerging Buying Criteria)

These are roadmap features that are clearly “below the line” for the current release but can be communicated to customers as part of a roadmap or statement of direction.

Ideally there are just a few key “nice to have” features and these define key elements of a roadmap.

These features should not be worked on unless the developer cannot in any way contribute to the “must have” or “should have” list.