| In
this issue we visit the scene of a perfect crime that takes place every
day at high-tech country. No, it has nothing to do with bad accounting
(which fortunately is starting to prove not so perfect for many of the
criminals).
It is a crime committed by people like you and me, who are actually
out to do good. What we're talking about is nothing less than what
symbolizes high-tech - new product development.
We present a number of takes on the crime scene, with a bit of drama,
a bit of humor, and even some happy ending. We also want to know what
your take is, which you can do by participating in our historic first-
ever reader poll. Results will be published in our next issue.
Enjoy this issue and have a great summer!
| in
this issue |
 |
 |
|
| The
Perfect Crime |
 |
| "Almost
every company is set up for the convenience of the people who
work at it, and not for the convenience of the customers,"
said John Brandt, publisher of Chief Executive magazine in an
interview to CRMDaily. Sad, but true. While we all try to
satisfy our customers (I'll give us as much as that!), we tend
to naturally gravitate towards what we know best; and we all
know a whole lot more about what's best for us than about what's
best for our customers.
One opportunity to turn this situation around and satisfy
customer needs is during new product introduction. With the
mindset of being customer- driven, you start with a market
research, and you actually ask your prospects and customers what
they would like to see in the new product. You even have a
product manager who writes detailed requirements. Looks like
you're going to get it right this time! But can you really defy
the law of gravity?
Now close your eyes and fast forward 24 months. Your new
product has just been released (6 months later than expected;
for some odd reason it seems like these numbers never change).
The product gets some decent press coverage and reviews, but
customer reaction is lukewarm. The product is not bad, but it's
not great either.
The CEO invites the Product Manager and VP Engineering to
discuss the product release. While avoiding eye contact, they
each mutter their version of "the state of the
product". The VP Engineering has an easy answer: "This
is just version 1.0, what do you expect?" The Product
Manager has a different line: "The product is not what we
asked for", he says, "if it were, customers would be
happier, but engineering did not deliver what we asked
for". "But you did write requirements?" asks the
surprised CEO. "Yes, and we developed according to the
requirements", jumps in the VP Engineering. Two hours
later, the meeting is still on... What happened, the CEO
wonders? Where did we go wrong, after all the market research
and the elaborate product requirement process?
The company had a perfect process to get market- driven
requirements to development. But it was a process built for the
convenience of the people who work at it, not for the
convenience of the customers. With each function of the
organization being able to claim that it did its part of the
process, there is no one to blame for the product failure. The
perfect alibi. The perfect crime.
So what can you do to prevent the perfect crime?
- Clearly define product goals. What will it do for
the company? What value will it deliver to the customer? It
is important to get these in writing and get everybody
signed on them early in the process. When I say everybody I
mean everybody, from the engineers to the CEO. Once agreed
upon, these goals serve as the measuring stick for every
product decision and evaluation. To make sure they do, get
them down to no more than ten bullet points, and make them
visible everywhere: they should be hanging in each cubical,
they should be the first page of every product document, and
they should be on the first slide of every product
presentation from here on.
- Put ONE person in charge. Presented in the most
brutal language, someone should be fired if the product
fails to meet the set goals. Since you cannot fire too many
people, you need one person to bear the consequences...
Macabre humor aside, you do need someone who cannot have an
alibi. This Chief Product Officer must have the ultimate responsibility
for delivering on the product goals and the ultimate authority
over every product decision. Sounds extreme? Maybe, but
a new product is extremely important, and extreme situations
call for extreme measures.
- Conduct frequent product reviews. Engineers tend to
build products from the inside out. The inside is important,
since you want a product with solid foundations. For your
customers, though, this is something they take for granted.
What is important to them is how they work with the product,
how the product works for them. That's why you want to see
mockups, prototypes, anything that will give you idea how
the final product will look like early on in the process.
These will require some extra work from your engineers, so
make sure to build them into the product release schedule.
- Get customers involved early and often. Get
potential users to serve as your Product Review Board. You
want to have 20-30 users on board, since not all of them
will be available at all times. You can easily recruit them
as you conduct your market research - customers like to be
heard! Don't be afraid to show them early prototypes; this
is when their feedback can make the biggest difference. To
make the most out of this precious resource, use it
frequently and make it formal. Establishing regular meetings
(in person or over the web) will force you to keep showing
them new stuff - nothing better to keep you honest and get a
step closer to a process that actually serves the customer!
Taking some of these measures will not be enough to stop the
crime. Doing them all will get you closer. If nothing else,
you'll know who committed it...
|
| A
Structural Flaw |
 |
| Chris
Maher is an absolute favorite when it comes to B2B copywriting.
In this masterpiece, Chris takes a poke from a different angle
at the product introduction process. I guarantee it will make
you laugh!
The
Introduction of Snorgletux 1.0 »
|
| Case
Study: Don't Listen to Your Customer, Unless... |
 |
| As
this case study shows, listening to your customer can be a huge
mistake, if you don't have the process to appropriately handle
what you hear. It's a lesson in product management at its worst
and at its best.
How
to Get the Geeks and the Suits to Play Nice »
|
| Requirements
- Problem or Solution? |
 |
| What
are the chances of getting a good product out of the door if we
don't even speak the same language?
This article from ProductMarketing.com, a resource site for
product managers in high-tech, tries to make sense out of
requirements, specification, design, and other elements of the
product definition process.
Read
the article and access additional ProductMarketing.com resources
»
|
|
 |
 |
 |
 |
 |
Reader
Survey - Make Your Vote Count!
Tell us what you think about our feature article by
selecting the link of your choice. Results will be published in
the next issue.
A.
You are right on the money. Products fail because the process is
flawed and there is no one accountable.
B.
It's all the fault of the engineers. They think they know it all
and never listen to product management.
C.
No way. The reason products fail is because product managers
think they can tell developers how to make products.
D.
This is a bunch of hogwash. Products are lousy because there is
never enough time to get them done right.
Give
us your own version
|
 |
 |
 |
Forward
this Newsletter
to a Colleague
|