I Have an Idea for a Software Product, How Do I Get Started?

Q: I have an idea for a software product, how do I get started?

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.

Q6 How does the customer find out about the product/service?

• What sales channels do you contemplate: direct, distributors, value added resellers, other?
• What magazines and trade journals do your prospect rely on to learn about offerings like yours?
• What websites, blogs, and on-line groups do prospects routinely visit, read, or take part in?
• What tradeshows and events would prospects normally attend?
• What consultants, recommenders, and buying guides would they consult to get information on an offering like yours?
• What open source projects are related to your offering, they may be a source of ideas and early feedback?

Q7 How has the customer done without this product/service so far?

• Are you eliminating or reducing and existing cost stream?
• Have they tried to solve this problem on their own? Have they spent time or money on a partial solution?
• Are they currently spending cycle time or non-value add people time to work around it?
• Can you reduce errors, error rates, or iteration counts?
• Do you enable them to access new markets or opportunities currently unavailable to them?
• What are you specifically obsoleting or replacing?