It's 1966, and the largest car company in Europe is looking to create an inexpensive, fun sports car.  They own the biggest single automobile plant in the world, so manufacturing won't be an issue.  They have Pininfarina under contract, so styling will be clean and sexy.

The Spider hits the market at a price below most competitors, with a solid marketing campaign and good global distribution.  It sells pretty well and is a cool car for 20-somethings not suffering from testosterone poisoning.  They got 1000 things right with this product -- the convertible top mechanism should have won a Nobel prize -- but they got one thing wrong.  It was made by Fabbrica Italiana Automobili Torino -- a company that customers called "Fix It Again, Tony."  Without that key feature called "reliability," the Spider (and its British counterparts) were quickly wiped out by Nissan's 240z and BMWs 2000.  It's important to note that, at the time, neither Nissan nor BMW were known for sports cars (take a look at BMW's other 60's hit, the Isetta)

This month, we're not looking at branding or market timing:  it's about product design.

What's Old is New Again

Whenever innovation provides a competitive edge, great designs (and quick tweaks) will yield way more profits than you can get once a product category is mature.  In the early 80s and 90s, IT's high-innovation market was hardware.  In the late 90s, it was software and the internet.  Today, product design -- and design errors -- have come back as important issues for the latest IT wave:  hosted services, web 2.0, and open source products.   

Product Design is at the core of the Product Management function, and it permeates conversations between Marketing, Engineering, Executives and Sales.  As with the FIAT Spider, the market gives you very few points for all the things you got right, and hits you hard for the one or two things that went wrong.  So it pays to put quality time into this.

Of course, a great product design can't happen unless you know who the customer is, why they really need it, what they perceive as value, and how much they're willing to pay.  Read the linked articles to get ideas about product strategy.  Assuming you got all that under control, it's time to examine product design.

At the executive level, product design decisions manifest themselves as a series of tradeoffs -- budgetary and schedule allocations among:

• Features 

• Ease of Use  / OOBE

• Performance

• Scalability / adaptability / robustness

• Quality / fit-and-finish

The problem is, these choices usually present themselves serially, along the lines of "do you want feature X, or do you want to delay the launch?"  This is a false choice.  The trick is to look at these five as a simultaneous equation, trying to optimize the five domains of the product goals against the five corresponding cost areas (money, time, market size, team morale, and company reputation).

When Design Really Matters

I hate to sound like a New Age throwback, but upper management needs to look at product design and resource allocation decisions holistically, not hierarchically.  The whole company produces the product and the customer experience, not just one department.    

An award-winning product does not need to be best on the planet along every competitive measure (indeed, it is quite unprofitable to even attempt this).  Instead, management should be looking for the optimal tradeoff where the product is good enough for most every expected use, and world beating for at least one important use case.  As I wrote earlier, products need to be developed around a coherent thesis that evolves incrementally.  The product description must not be a requirements bible, a tome written by marketing and read by nobody.  Instead, use an evolving document where key product team members insert incremental contributions throughout the design cycle.  Three-ring binders and this stuff called paper are amazingly effective.

So how does an executive team know if this kind of iterative, flexible product development process is in place?  Here are some questions you can ask to assess the health of your product development team -- and the success of your product design -- long before problems surface:

• Product development team membership:  is someone from customer support or sales on the product development team?  They needn't attend every meeting or review every document, but they can't be out of the loop, either.  Ideally, an early customer or two acts as a design partner both for the product's features and its commercial aspects.
   

• Product development team trust:  do the members of the team actually work together, or are they adversaries?  Generally speaking, product management should have 51% of the vote on the team...but the product manager will have to earn that trust through good decisions.  Healthy debate is a good thing, but if you ask a team member why a decision was made and hear something along the lines of, "those jerks insisted," there's probably trouble.  In the extreme, engineering and marketing are at war...and the company is the loser.
   

• The customer is MIA:  is there a clear customer definition, including personas and roles?  Were outsiders brought in to review story-boards, mock-ups, and early versions?Did people actively listen and integrate feedback about value of the product, the features that needed to be perfect (and those that didn't), and the packaging?
      

• Bugs, board revs, and chip spins:  nothing is worse for a product schedule than unanticipated rework.  If the team (or management) is in denial, it's deadly.  Ask whether a lot of bugs have been re-prioritized (either their severity or priority), or testing skipped, or simulation steps deferred until after tape-out.  Any hint of these maneuvers does not bode well for your product design or its implementation schedule.
   

• Multiple realities:  for any one product, there should only be one feature list, one set of release/launch criteria, one set of benchmarks, one bug list, and one schedule.  If there are more than one of any of these items (like "the official bug list and the engineering bug list"), you've got a severe organizational disconnect.  The first thing to do is outlaw fiction and find out what's true.  Watch out for weenie behaviors.  You will rapidly uncover other problems from the overall list.  Rectifying problems here may mean a reset to the schedule or a change to your product expectations -- but not rectifying them quickly will only make things worse.
   

• Big bonus syndrome:   big incentives can improve team performance, but can distort good judgment.  If a executive personally has $100K or more on the line, he is all too likely to ship garbage.  This can kill a product, a product line, or the company reputation.  Restructure the bonus so it's contingent on product profitability, including the costs of excessive customer support.
   

• Come-from-behind syndrome:  when most companies are trying to recover from a tarnished reputation, no matter how good a job you do it's really hard for the customer to believe that your new product will pass muster.  Negative branding is in play.  This is what happened to FIAT (the Spider had good relatively good quality, but nobody would believe it) and is happening now to GM (their new designs are pretty good, but nobody notices).  There are some companies that can pull off come-from-behind product victories (think Microsoft), but it takes tenacity and real patience.
   

• Incomplete product syndrome:  engineering says the product is done, marketing says it's not so sure, and sales says they can't sell it because the product isn't complete.  This is a really common problem, and causes blatant political behaviors on all sides.  Unfortunately, the big political implication is that upper management has not been sufficiently involved with the product or its customers.  The fastest way to solve this is to involve customers in candid product reviews where upper management is present...and in listen mode. 
   

• Guess-wrong syndrome:   Guesses and assumptions are part of any innovative process, but if marketing completely misunderstood what customers meant, or if engineering misinterpreted the requirements and designed something nobody would want, you're out of tune with the customer.  Either the team is missing domain knowledge, or they are not actively listening to customers.
   

• Wild product positioning:  somebody (maybe an airhead in advertising, maybe a pointy-haired executive) has come up with product positioning or messaging that simply is not believable outside of your offices.  For political reasons, Sales may actually use the marketing message, but with poor results.  The product design is blamed for not complying with the unrealistic product positioning.  But marketing is not about making fantasies true, it's about making the truth interesting and motivating to a customer.  Bring positioning back to reality by talking with customers.
   

• In software companies, infrequent builds:  there is no substitute for doing a build of your entire software system on at least a weekly basis, with incremental builds every night.  Ask around -- if a system build takes a week or even longer, and making the system fully testable requires heroic efforts, you're on the road to big problems.  Invest in automated build infrastructure and establish real schedule expectations.
   

• In IT companies, can't eat the dog food:  sometimes, you'll find that your internal operations people won't use early releases of your software or hardware.  This means they aren't willing to bet their jobs on your quality, performance, or features.  Using the product internally in Marketing and company operations should be a hard requirement.  Fixing this means reforming both engineering quality and your internal operation's practices.
   

• In high-tech products, user interface:  whether it's a GUI, an instruction manual, or a web site, user interface mistakes are like a bad haircut.  You just can't hide them.  Nothing will make users angry more quickly or raise your product support costs more dramatically.  Do not economize on your product's installation, upgrade, or "OOBE" -- out of box experience -- if you want it to be a hit.  This can have the biggest payoff of any product investment you can make.

Future Schlock -- coming in October

Contents copyright 2006 by DOTnet Consulting, Inc., all rights reserved.
Feel free to forward this report, but you must include this copyright notice.
All trademarks and graphics are the property of their respective owners.
This newsletter was mailed to you because our records show you asked to receive it.
Click here to opt-out of future newsletters, although that will make us feel very sad.

David Taber
  www.taberconsulting.com  

Direct line:  +1-650-326-2626 Pager: 6503262626@mobile.mycingular.com
Best times to call: ICQ# 138661538
8 AM   or   7 PM PST (GMT -8) Yahoo-AIM-MSN:  TaberConsulting
555 Bryant Street, Suite 789 Skype:  TaberConsulting
Palo Alto, CA   94539    USA LinkedIN:  David Taber