By David Taber.

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.”

This month, we’re not looking at

href=”http://www.taberconsulting.com/download/dtr-18.htm”

target=”_blank” class=”offsite-link-inline”>branding or

href=”http://www.taberconsulting.com/download/dtr-42.htm”

target=”_blank” class=”offsite-link-inline”>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, the 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 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

href=”http://www.taberconsulting.com/download/dtr-15.htm”

target=”_blank” class=”offsite-link-inline”>customer is, why they really

href=”http://www.taberconsulting.com/download/dtr-13.htm”

target=”_blank” class=”offsite-link-inline”>need it, and how much they’re

href=”http://www.taberconsulting.com/download/dtr-16.htm”

target=”_blank” class=”offsite-link-inline”>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 possible cost areas (budget, 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

href=”http://www.taberconsulting.com/shared/images/newsletter/awards.gif”

target=”_blank” class=”offsite-link-inline”>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

href=”http://www.taberconsulting.com/download/dtr-13.htm#Xtreme”

target=”_blank” class=”offsite-link-inline”>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 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.

• Bugs, board revs, and chip spins: nothing is worse for a

  product schedule than

  href=”http://www.taberconsulting.com/download/dtr-22.htm”

  target=”_blank” class=”offsite-link-inline”>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 isn’t one of each of the items above, you’ve got a 

    problem with engineering or marketing maturity. Very young companies have

    an excuse. But fix this situation no matter what.

  • If, on the other hand, there are more than one of any of the 

    above 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

    href=”http://www.taberconsulting.com/download/dtr-32.htm”

    target=”_blank” class=”offsite-link-inline”>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 delay will only make things worse.

• Big bonus syndrome: big incentives can improve team 

  performance, but can distort good judgment. If an executive has $100K or

  more on the line, he is all too likely to ship garbage. This can kill a

  product, a product line, or a whole 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, 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 a

  product that 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: has marketing or engineering gotten

  something completely wrong in the product design? 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 is missing,

  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. Don’t

  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.

Contents copyright 2006 by DOTnet Consulting, Inc., all rights reserved.

From

target=”_blank” class=”offsite-link-inline”>The Taber Report.