Drowning in product documentation? Start swimming – Part 1

(Updated from the original on 3 December 2015)

Do you spend more time writing documents about your product than actually managing it?

Many companies with a product management function become all caught up in the process, drowning themselves in increasing numbers of documents. These rapidly become overwhelming to manage, contain duplicated detail and ultimately obscure the real goal of product management, namely to create successful products.

Every product has its own story, a narrative that takes it from idea to creation to update to end of life.  However, we have a tendency to obscure this story with a plethora of product concept documents, business cases, project briefs, market, product and commercial requirements documents, technical specifications and so on, many of which can duplicate information.  To compound the confusion, each organisation seems to use them in different ways!

So let’s get away from the labels for these documents and consider what purpose they serve by identifying the questions they answer and who needs to know the answers.  If you can answer the relevant questions on a single sheet of paper, great!  That is likely the right level of detail for your needs.

Concept stage: what’s the big idea? #

Objective: to pass the ‘sniff test’
Audience: peers, potential customers

First of all, we need to describe what the big idea is.  This could be a whole new product or service, a new feature or even a different way of doing business. Many people think of this as the elevator pitch – essentially distilling the idea into a 60-second summary you could deliver to someone while travelling with them between floors in a lift.

At this stage we don’t have or need all the detail quite yet.  The reason for this is that you’ve not yet conducted the research and experimentation you need to truly understand your potential users’ needs and problems, nor to envisage and test out the solution to those user problems.  We don’t want to go to all that effort for every half-baked idea that comes in, so we want to filter out the concepts that don’t cut the mustard before we’ve spent too much time on them, so that we can devote time to the better ideas.

The ‘sniff test’ is pretty simple: if it smells bad, it probably is bad.

Questions to ask at the concept stage: #

  • What’s the back-story or context?
  • What’s the problem, who’s got it and why is it a big deal?
  • What’s the potential solution to the problem?

Fleshing out the detail: what else do we need to know? #

Objective: to discover the right solution to the problem
Audience: your boss and his or her peers, potential customers

Okay, we’ve made a good start on describing what we want to do and why it’s worth doing.  Now we need some more detail to see if we’re missing something obvious.

We don’t want to go rushing into something unless we’ve got a reasonable idea that we’ve identified a real problem needing to be solved, as opposed to creating a solution in search of a problem.  It’s also helpful to figure out early whether we stand a chance of being successful and to adapt our approach to increase that chance.

This is where you get out of the building to really understand:

  1. Much more detail about the people with the problem, when they have it, how often, why they care
  2. Whether the people you think have the problem are in fact the ones with the problem
  3. Nuances or differences between different groups of people (segmentation)
  4. What possible solutions to that problem might be
  5. Which possible solutions are going to work better or worse with the target users

Questions to ask when fleshing out the detail: #

  • Who’s doing this already?
  • If no-one is, why not (and are you sure)?
  • If someone already is, why will the people with the problem think our way is any better or different?
  • What experiments can we run to figure out how it’s going to work?
  • Are the people with the problem able to solve it easily with your proposed solution? (tip: check with mockups and prototypes)
  • What skills / technologies / approaches does it look like we’ll need to implement the solution in a product or service?

Investment stage: why should we spend cash doing this?

Objective: to avoid a costly error
Audience: whoever holds the purse-strings

At this point, we need to go cap-in-hand to the people with the cash.  Depending on whether you’re speaking to a managing director or CEO (read: Sales guy), a financial director or CFO, or investors, it all boils down to:

“If I give you £10,000, I want you to make me or save me £100,000 in return”

Questions to ask at the investment stage: #

  • All of the previous questions, plus the following (roughly – you only know so much at this stage)
  • How much do we reckon this will cost to build and operate?
  • Given a suitably-skilled team, how long do we reckon it will be before we can start selling it?
  • How much is it going to cost to tell the people with the problem that we’ve solved it?
  • How much is it going to cost to keep the product going (support, maintain and extend)?
  • Given market size, competitive forces and what we know of sales cycles so far, how many are we going to sell and how often – realistically?
  • How much will the customer agree to pay for them?
  • How much do other companies charge for the same thing?
  • How quickly do we think we’ll cover our costs and reach profitability?
  • How many do we have to keep selling to keep turning a profit?
  • How much is it going to save us or make us?

And possibly the most crucial one, because after all we can’t predict the future with any accuracy:

  • If I’ve been guessing wildly for each of these answers, what hard evidence would I need to see to convince me and others that this is worth investing in?

That’s a good place to leave things for now.  Next time we’ll look at the information you need to gather to build and launch successfully.


Read more from Jock

The Practitioner's Guide to Product Management by Jock Busuttil

“This book has been a genuine game changer for me”
– pb (Amazon)

“I wish this book was published when I started out in product management”
– KejiA (Amazon)

One thought on “Drowning in product documentation? Start swimming – Part 1

  1. Pingback: Cycles within cycles | I Manage Products

Agree? Disagree? Join the conversation: