Conceptual Design – The Missing Link in Small Company Product Development

Few would disagree that the iPod saved Apple from bankruptcy, but it was not just about the idea of a digital music player. There were at least 20 other digital music players on the market long before Apple started the project. Apple understood at a very deep level that the requirement of “easy-loading songs” was extremely important, and they developed the concept of iTunes as a result of that understanding. We all know the results. Imagine if they had said, “We don’t need to worry about a conceptual design. We know what we need already—we just need to focus on getting it to work.”  If the mission was singularly focused on getting a prototype to “work”, then Apple and the iPod would both be on the waste heap of yet another failed startup/product just like all the other digital music players/startups on the market at that time. Apple’s Conceptual Design for the iPod is largely responsible for saving what would eventually become the most valuable company in the world.

If only all startups were as focused on Conceptual Design. Too often they focus on just getting a prototype, or getting it to work, long before any ideas about the Conceptual Design have been considered. This is unfortunate as good Conceptual Design is not all that complex and can be mastered with basic processes and some simple rules.

Conceptual Design sets 90% of the development cost, unit cost, performance, usability, number of fires you will have down the road, etc. Ninety percent of the success of a product is determined in the Conceptual Design phase – not in the detail design phase. It is the most leveraged part of the development processes. Get this wrong and everything after can be a colossal waste of time and money—something small companies can rarely afford to do.

  1. Rank all the requirements (you did write a Requirements Document, if not, see:  First, decide which of the requirements are “defining requirements”; that is, requirements that if they exceed the specified requirement then the result will be a better product.  Take these defining requirements and rank them. For example, if there are 10 defining requirements, the most important one ranks as a 10. For each of the other defining requirements, decide how important it is to exceed the specified requirement relative to the number 10 requirement.  A 5 means it is only half as important as the number 10 requirements. In the iPod case, the ability to easily load song was a very high ranking requirement.
  2. Now generate at least three different concepts for achieving the requirements. If you can not think of three, then keep thinking, or get someone to help.  Do not accept that there is only one way to do anything.
  3. Now create a spreadsheet (or download it here: with the defining requirements down the side and the concepts you developed on the top.
  4. There will be a box for each intersection of a concept and a ranking requirement.
  5. Score each box on how well that concept will meet that requirement.
  6. Multiply the rank by the score and add them up.

Your sheet should look something like this:

Requirement Rank Concept 1 Concept 2 Concept 3 Concept 4
Unit Cost 10 10 8 7 7
Development Budget 8 4 10 7 7
Battery Life 6 7 3 10 9
Reliability 4 5 5 2 10
Performance 4 5 5 5 10
Score 214 218 214 260

This will take a little time to set up and to get everyone to understand, but it will be well worth the effort.  The magic of this processes is that it focuses the team on debating one requirement and one concept at a time. Is this requirement more important than this other one?  Will this concept be better than this other one in exceeding this requirement. Too often, teams get to overwhelmed and confused because they try to talk about everything at once, or miss important aspects of certain concepts because they are too focused on how well a concept will perform on some other requirement.  Focusing on one box at a time brings clarity and objectivity to the conversation and decision making.

Here are a few other things to keep in mind when doing Conceptual Designs:

  1. Its a team sport:  Conceptual Design is a group activity.  To make a good decision, and to truly develop innovative products, you need input from many different areas: marketing, sales, production, operations, engineer, etc.
  2. Make sure your requirements are validated:  A conceptual design can only be as good as the requirements document is.  Are you certain the requirements are complete and have some form of market validation?
  3. Beware the technical expert:  Nothing wrong with having a technical expert (deep knowledge, but not very broad) as part of the team, however, most of the team should be people with very board knowledge, not necessarily very deep (sometimes called “T” people).
  4. Guard against NIH (Not Invented Here) Syndrome. Use a good facilitator who has the skill to uncovering decision bias.
  5. Avoid Groupthink.  Bring in outsiders at key decision moments to mix up the thinking.

A product is only going to be as good as its Conceptual Design, no matter how well the detail design is done.  Using a proven methodology for conducting a Conceptual Design is a good start – especially for small companies and startups.


Leave a Reply

Your email address will not be published. Required fields are marked *