by Founding Partners Susan Loconto Penta and Michael Goldberger,
the MIDIOR team is focused on the discipline of product
development and management, helping clients seize new opportunities and
respond to changing markets.
Changing the way you think about products
HIT THE MARK FOR REQUIREMENTS
Part One. Begin at the Beginning:
Establish Context First
of the questions we get from clients relate to the challenge of
defining requirements. Studies suggest that the overall success rate for
new products and services is well below 50% which means that at least
half of your investment in product development will be lost. Getting
the right requirements can make all of the difference in the world and
we are often asked to recommend a structured process that will help
product teams design the functionality that is most important to their
year our series of MIDIOR Mailbox newsletters will focus on this
important topic and offer a step-by-step approach that is actionable for
both products and services. We'll
share what we have learned in our former lives as product managers and
developers as well as from our day-to-day work with clients. In addition, we'll
bring in some of the issues we encounter in our one-day Requirements
Workshop. This interactive forum is where we work with product teams to
build their requirements analysis skills by working with them to define
requirements for a specific product development initiative challenging
How can we get better at defining requirements so that our products and services consistently delight our customers? We often get stuck on debating features that, in the long run, don't make a material difference to the product's success.
This question happens to come from the leader of a product team at a technology solutions provider but it is
typical of almost every client engagement where we get into a
discussion about requirements. Defining and prioritizing features and
functions is hard work, made even harder by the fact that it is a
collaborative effort that depends on a fuzzy combination of facts,
opinions, projections and guesses about the future. In
this instance, where there is a services component to the offering, it
can be difficult to see where the product starts and stops, making the
requirements definition process even more challenging. But let's
start at the beginning. A critical mistake many product teams make is
that they attempt to define detailed requirements without first
We feel this step is so important that the rest of this newsletter will
focus on context. If the product team takes a disciplined approach and
actually works through this step, we're confident the result will be more accurate requirements and more relevant products.
Ask the Right Questions
We say that every requirements discussion has to begin at the beginning - which to us means starting with the "why" of the product in order to establish context. A
product manager needs to ask a lot of questions and unearth the details
in terms of what he doesn't know AND what he doesn't know he doesn't
know (those unknown unknowns!) Asking the right questions to get to
meaningful answers takes persistence and courage and is not always easy
to do, particularly if development has started or you are dealing with
commitments that have already been made. Consider how rare it is to
start with a completely blank sheet of paper - the enviable
position of an entrepreneur starting a company. We suggest you begin every requirements discussion with three critical questions:
1. Why is the company doing it?
2. Why does the customer want it?
3. Why does this opportunity make sense?
The first question deals with how the product or service aligns with overall corporate goals. You need to assess how important this initiative will be to business success and if it doesn't matter, you should quit while you're ahead and focus your precious resources elsewhere. We
are continually surprised by how many product teams simply neglect to
ask this question, only to find themselves, months later, unable to
secure funding or executive support.
The second question
ensures you truly understand who will use the product and more
importantly, why they will use it over what they are doing today. Will
this product or service be useful to a broad spectrum of customers or
are you relying on input from a narrow slice? Context helps you apply a
filter to the target universe and carefully evaluate who falls into it
and who does not.
The third question deals with why the opportunity actually makes sense. Sometimes
the answers are surprising. You might find, for example, that a product
aligns with company objectives and will fulfill customer needs yet
make sense because a competitor already has a strong position in this
space and the investment required to succeed is too steep. On the other
end of the spectrum, you may experience support for a product that does
not have the strongest financial business case but because the company
is already too far down the road in terms of expectations set with
customers so the decision is made to proceed. Regardless,
ensuring the team understands why the opportunity makes sense is
critical and although you may not always agree with the reason, it will enable you to move forward. Knowing the answers to all three "why"questions
paints the true picture. Many companies overlook context and shy away
from the hard questions, but they need to be answered in order to make
the right product decisions.
Why is context important?
Without a clear understanding of the context, product managers will be launching a product into a world they don't understand. No wonder that products fail to meet the needs of customers or fall short of expectations. So
often we see the product manager forced into a defensive mode, stuck in
the middle between engineering and sales. Consider this all too
familiar scenario. The head of engineering comes to the product manager
with a product or capability that already has resources allocated to it
and says, "here's the product, go document the requirements". Or conversely, a sales rep comes back from a customer visit with the directive, "here's what the customer wants, now we have to spec this into the product". Without having established context, the product manager has no foundation to properly assess the request or meet the challenge.
A good analog for asking the right questions and "beginning at the beginning" can be found right in your doctor's office. Before
attempting a diagnosis or prescribing a plan of action, a physician
first takes a detailed medical history to establish context. The why
questions will include a thorough understanding of the genetic landscape
of a patient, previous illnesses and surgeries, significant life events
and so on. Only then will the doctor turn to the immediate symptoms that bring you to the office, offer a diagnosis and prescriptive plan.
conclusion, being disciplined about understanding context before you
define requirements will make it easier for you to stick to priorities,
say no to requests that are out of scope and allocate resources more
For more information about defining product requirements and how the one-day MIDIOR Requirements Workshop can help your product teams establish context and build the skills to be more successful, contact MIDIOR.
|A New MIDIOR Workshop|
your product initiative to this one-day requirements workshop and build
your team's knowledge and skills to generate accurate requirements, the
first time and every time...get agenda.|
Get the latest
insights to how financial services and technology firms are practicing
product development and management in their organizations. Priorities, investments, metrics and hiring in 2010. Get the report.
|Go to The Product Line Blog|
|What does Johnny Carson have to do with product development? It turns out, he's still an innovator. Find out why...|
|In the Next Issue|
next step is defining requirements. We look at different approaches to
getting true customer insight and recommend what we have found works
|Ask a Question|
If you have a product development or product management question for the MIDIOR team,
send it to us.
|Share a Copy
|If you would like to share this newsletter with a colleague, click here