Effective Engineering e-Newsletter – 7/3/2003
This is your bi-weekly e-Newsletter from Effective Engineering Consulting
If you would like to receive Effective Engineering e-newsletters as
they are published, please send an email to firstname.lastname@example.org,
and we will add you to our distribution list.
Product Definition: Define What
It Is and What It Isn’t!
Tom Dennis – President, Effective Engineering [email@example.com]
Have you ever worked on a development project that has
seemed doomed from the very outset, almost like one out of a Dilbert cartoon?
One where features and functions are vague and seem to change from one
day to the next? One where
decisions are made and then are repeatedly overturned, and where work is done
and then undone? One where what
is being worked on at any given moment is questioned continuously and where
people are shifted from one “priority task” to another and then to
another? Such a project is
incredibly frustrating to be associated with, and generally stems from a poor
product definition and poor change control procedures.
As the saying goes, “Well begun is half done”; the counter to that
saying is “Poorly begun is never done”.
The importance of a strong foundation when starting a project cannot be
In order to build the right product, you have to know what you’re building.
The initial document that spells this out, or is at least supposed to,
is a Marketing Product Definition document, or one with a similar name.
The intent of such a document is to define the features and functions
of the product to be built. At
the early stage of a project, this is generally a fairly high-level
definition, specifying in fairly broad terms what the product is and does.
It’s intent is to provide sufficient information for the requirements
to be taken to the next level of specification.
When not done at all, a project will proceed with no real sense of
direction. When done poorly
(which happens all too often), it gives only a vague sense of definition
and/or direction, leaving what the product really is open to individual
interpretation (a dangerous proposition).
When done reasonably, this document gives a clear definition to all of
what the product is. When done
really well, it not only defines what the product is, but also what it
isn’t. By defining what a
product isn’t as well as what it is, it prevents people from heading
off-track in directions that were not intended.
All efforts should be made to provide a really excellent product
definition document, clearly defining what the product is, and what the
product is not.
This product definition document sets the foundation upon which the product
will be based. A firm foundation
provides a stable platform to build upon; a flimsy foundation leads to a
platform that can later collapse. While
this document is typically called the Marketing Product Definition document,
this does not mean that Marketing should prepare such a document in a vacuum.
Quite the contrary, it is critical that many viewpoints be represented
in coming up with the product definition.
Most critical is to properly define what the customers really want (see
eN-030619 – What Do Your Customers Really
Want?). Make sure
that current and prospective customers are asked, and asked in the right way;
ask what they will want in the timeframe when the product will actually be
available. Once the customers’
needs are properly represented, then other organizations need to be involved.
Marketing (including product management), yes, but also sales,
engineering (including development, test/quality assurance, usability,
performance, technical documentation, etc.), customer support, field
engineering, business development, manufacturing, finance, and others should
be involved to ensure their unique viewpoints are properly represented.
Marketing then controls the drafting of this document, appropriately
incorporating the diverse viewpoints, with the greatest weight given to the
customer viewpoint. However, it
must be a sensible and coherent document that will satisfy customers.
Trying to make the document be all things to all people seldom works.
Once drafted, this document should be sent out for review, to get the
comments from others involved and to reach consensus.
As stated above, this document should cover not only what the product
is and does, but also what it isn’t and doesn’t do.
Clear expectations are essential; everyone needs to be singing off the
same sheet of music. The document
should be a crisp, concise, and complete as possible. After comments have been reviewed and discussed, and
consensus has been reached, this document should be formally signed off by all
relevant parties. This ensures
everyone has formally bought-in and establishes a written baseline.
Once completed and signed-off, the next stages of the development
process can proceed.
How are the inevitable changes that come along to be handled?
It cannot be a haphazard, ad-hoc process to accept some and reject
other changes. A formal change
control process is essential. Feature
creep can be deadly to projects, particularly if timely delivery is important,
and it is always important! [see eN-021121
– Late Projects Kill Companies!]
The typical request for a new feature is, “But it’s only a minor
change to add this, and it won’t take any time, really.”
While this may or may not be true for one isolated feature, the impact
of many “minor features/changes” can add up to a very major impact.
“There is no such thing as a small change” is generally as true a
statement as “There is no such thing as a free lunch.”
This is where the baselined Marketing Product Definition document comes
in. Impedance must be added to
any change. A
“costs/benefits” analysis should be mandatory for any requested change or
feature, minor or not. A change
committee must then weigh carefully and sign-off on accepting the “cost”
of the change in order to get the “benefit” of the change.
Usually the “cost” means more time, more people, or reducing or
eliminating features already included in the baselined document, all very
significant things to consider.
If the product definition is solid, and proper change control procedures are
followed, then the odds of a successful project and a successful product are
Copyright © 2002-2003
Effective Engineering Consulting Services, All Rights Reserved