If you participated in Easter egg hunts as a kid, you no doubt remember the experience. You ran from spot to spot in the back yard or at the park, looking for (artificially) colored eggs, especially the plastic ones--because they were the ones filled with candy. Little-kid screaming, parental helping, kids with baskets running every which way... it was a period of delightful chaos.
Looking for Easter eggs is great as a kid, but it's not so fun in the business world. If you want me to launch your product, and provide the kind of Marketing support needed to make it successful, I need to know certain bits of information:
- What is it?
- What does it do?
- How does it do it?
- Why does it do it; i.e., what's the value?
- Who is a prospective buyer of it?
and so on. Actually, I need to know what the salesperson needs to know; I wrote about this in a post some time back.
The problem that often arises is that Product Managers write documents that don't address these kinds of questions. Product Managers generate a lot of documents: a Product Requirements Document, maybe a set of use cases, sometimes test cases, and so on. So when Marketing Guy drops by to say, "I need answers to these questions" the Product Manager's reflex is to hand Marketing Guy some or all of those documents. "It's all in there" is the last thing Marketing Guy hears before the Product Manager rushes off to a bug review.
So now Marketing Guy has two problems.
- He has to search through a stack of documents to find answers to his questions.
- Having completed step (1), he still has no answers, and has to go back to the Product Manager again.
What compounds the problem is that some Product Managers may not have stopped to think about the answers to Marketing Guy's questions. So the answers are not there, no matter how many pages of documentation exist. This is like searching for that plastic egg, only to find that there's no candy inside. So how to move forward?
Complete This Form
Our Product Management group at iPass was working on a product that amounted to a cloud-hosted version of an enterprise firewall. As we approached the time for market launch preparations, the Product Marketing team was getting increasingly frustrated. The Product Manager thought that the answers to the launch team's questions were in previous documentation, and kept referring the Product Marketing team to that documentation--which was voluminous. (It didn't help that different documents described different products, since the product
concept seemed to be constantly evolving, but that's another tale). Although I was in Channel Marketing at that time, I volunteered to help, since I had previously run Product Management... I could feel everyone's pain.
My first step was to meet with the Product Manager and offer my help. Fortunately, he saw that I could help him out and readily agreed to work with me. We "story-boarded" the product concept for a while, to develop the overall message. There were some pieces of the product puzzle that were well-defined, and others that were missing or overly vague.
Next I wrote up a document I called "Questions for Understanding"--the point being that answering the questions would amount to providing the market launch people with the answers they needed... without all the non-essential information to wade through. I had thought (perhaps hoped) that the Product Manager now understood enough of my method to go off and answer the questions... problem solved!
Of course, it wasn't so simple. The Product Manager (like all Product Managers) was crazy-busy, and (like nearly all Product Managers) lived what I call an "interrupt-driven" life that left little opportunity for the kind of reflection and thoughtfulness that was needed to answer my series of questions. And, as I said before, different people had different ideas about what the product was, so that confusion came through in the answers.
We Need to Talk
OK. Since this wouldn't be as simple as answering some questions, I took the document and met with the Product Manager a number of times. We took each question in turn and discussed it until I felt that we had a clear, unambiguous answer. If I sensed confusion or lack of clarity about some aspect of the product, we noted it and took the action to get some resolution. Within a week we were able to circulate a draft "this is what it is" document. After reviewing and finalizing that draft, Product Marketing had what it needed.
Rinse and Repeat
We institutionalized this method by creating something we called a "Product Launch Form". More important than the form itself were the rules that went with it:
- No referring to other documents in your answer.
- You're only allowed to use simple, declarative sentences... no subordinate clauses allowed!
- "I don't know" is OK to use as a placeholder (better to deliver most of the information than wait for all of it to be ready). But "I don't know" has to be resolved.
The most important rule was this: the form was to be filled out in the same kind of "interview" style I had used. This was done in part out of necessity--we had to be one of the Product Manager's "interrupts" in order to get some time--and in part to allow for a give-and-take that would short-cut the time needed for arriving at clear answers.
So the next time you're holding a metaphorical basket of questions and your Product Manager tell you, "it's all in the documentation", hand them one of those plastic Easter eggs--and make sure the candy's gone.