Writing for your audience

What does that last post about the Forrester writing style have to do with product management? Quite a lot, actually.

One of the toughest challenges I've seen for product managers is writing for your audiences. Let's expand on that last sentence:

• You are not writing for yourself. Many requirements documents make a case that convinces the product manager writing it. But, of course, you're already convinced, so convincing yourself further is pointless.
• You are writing to help someone else make a decision or perform a task. Therefore, you need to provide the right type and amount of information, in the right structure and medium, for that audience. The CEO approving the contents of a release needs different information than the developer implementing a feature.
• You have more than one audience. You'll be able to recycle information, but realistically, you'll be tailoring and adding to that information for each audience.

Therefore, nearly every successful product manager I've known has taken the initiative, early in their job at a particular company, to find out what type of information needs to be in a PM deliverable for a specific group. Sometimes, this discussion turns into a negotiation over what information is really important, or who really provides it. Do personas help make feature decisions? Does the PM storyboard a feature, or someone on the development team?

Clearly, this conversation is about more than just style--which is yet another reason to take the initiative. Inventing these deliverables as you go will only befuddle, frustrate, and antagonize the people depending on them. As Oscar Wilde said, "In matters of utmost importance, style, not sincerity, is the vital thing."

Writing with a capital W

I've taken a brief leave from blogging to focus on getting the next research document done. (Plus, I took a few days off.) I didn't feel that I could afford the luxury of blogging until, with God as my witness, I finished the next draft.

Writing in the Forrester style is a lot different than writing a blog. In fact, they're almost completely different animals.

Learning a new style can be tough...
Every new analyst at Forrester has to learn how to fit his or her thoughts into a framework designed for a specific purpose: make the document easy to read, at whatever level of attention the reader wants to give it. It's a foreign concept for people who learned, way back in our school days, a more linear writing technique.

Take this blog post, for example. I'm going from point A to point B, which connects to point C. You have to follow the chain of argument, if you want to understand why the author has reached a particular conclusion, foreshadowed in the introduction, and proclaimed with confidence at the end.

The Forrester style has a logical structure, of course, but it's designed so that I won't be mystified if I skim parts of the document. In fact, you can get the basic argument just from reading the headings. The text under these headings provides the explanation and justification.

The Forrester style has other dimensions, too. For example, every document tells a story, so the narrative follows particular dramatic conventions. If a document doesn't have a real story to tell, you'll never see it on the Forrester web site.

...But it's worth the effort
These conventions definitely apply outside Forrester. For example, back in my grad school days, I remember cringing while a professor got eviscerated by his peers. To paraphrase one of them: "You have a lot of interesting facts, but no interesting conclusions." Which is the academic equivalent of Truman Capote's famous quote, "That's not writing, that's typing."

Learning the Forrester style feels like moving from songwriting to screenwriting: both are equally good, but designed for different purposes and audiences. (And all props to people like Nick Cave, who successfully span fundamentally different media.)

The tyranny of the tactical

Jeff Lash muses at length about the importance of rising above tactical product management work in this excellent post. Here's a juicy quote:

Think about all of the tactical activities in which you engage — documenting details, answering questions, describing functionality, responding to feedback, tracking down responses, and the like. How much of your time is taken up by these activities?

The aggregate answer we received from our recent survey (publication pending) is, "Way more than we should." Although every job imposes some time spent on seemingly unproductive or counterproductive tasks, the degree to which product managers feel misused is striking.

One major struggle may be the difference between how product managers see their jobs, and how other people in the company (including their own management) view product management. Jeff touches on this problem indirectly, and perhaps accidentally, in the following section of his post:

Every time you as a product manager are presented with a task, ask yourself these questions:

• Is this helping to advance the product strategy?
• Does this support one of the high-level goals for my product?
• Is there anyone else within the company besides me who can accomplish this task (e.g. answer this question, investigate this problem)?
• Is this something that has come up before or is likely to come up again?
• Is this a valuable use of my time?

Of course, not everyone else in the company assumes that the core task of product management is advancing product strategy or supporting the high-level goals for a product. Alternately, they might agree that these are the core job functions, but they have no idea how product managers actually carry them out.

As long as there's this mismatch between perceptions, product managers are going to be swimming upstream against a flood of requests that they don't see as necessary. For example, does booth duty at trade shows help product managers achieve their goals? Maybe.

The answer is nowhere near as obvious as, "Asking developers to man the booth does not help us make our release dates." Therefore, product managers may try to build barriers against requests to help Marketing, but the cracks of ambiguity and misunderstanding weaken the dam.

During any interviews with product managers, Ive asked how Forrester can help them. The same answer has appeared in close to 100% of the responses: "Help my company understand what I do." Until this perception gap closes, product management will remain focused on tactical activities--because that's what many other groups want from product managers.

The company is not totally to blame. Jeff Lash's post has an important subtext that every product manager should heed: You don't have to be involved in everything because you might add some value.

Leadership Board for product managers

Forrester is planning on creating a Leadership Board for product managers. What does that mean?

Here's an official description:

The Forrester Tech Industry (TI) Leadership Boards bring senior executives together to stimulate new thinking & encourage business growth. Each is a knowledge community, layered on top of Forrester’s research services, tailored to a specific role. The Forrester Leadership Boards (FLBs) help members succeed by offering member-driven content, unique deliverables, community interactions and a dedicated relationship team.

In other words, above and beyond the normal research and consulting, the FLB for product management may provide things like..

• Regular contacts with your peers in other organizations, plus the Forrester TI analysts who serve product managers.
• Access to research that the FLB members specifically request.
• Special events for FLB members, including mini-events at Forrester conferences like the upcoming IT forum.
• A little extra attention as a Forrester client, since there's an official FLB staff.
• Information about the questions clients are asking us, through the regular inquiry process.

Since we're a role-based company, we have to be sensitive to the needs of each role. Therefore, you tell us: What would you like to see, in a Forrester Leadership Board (FLB) for product managers? You can respond in the Comments section here, or send me an e-mail.

Product manager or evil overlord?

I had a good chuckle at this paragraph on the SugarCRM web site:

The Sugar Open Source Project and Community are at the heart of our mission. Creating an ‘architecture of participation’ where users from around the world can help to build a higher quality, more useful product is a superior form of development than the traditional Silicon Valley model of a few product managers dictating what features the world needs. The open source model embraces the world outside of Silicon Valley instead of keeping it at arm’s length.

If you ever doubted that there's a difference between product management and marketing, doubt no more. Memo to the marketing person who wrote this copy: some product managers might dream of having dictatorial powers, but, honestly...

[On the off chance that you have the power to mold people's wills to your own, call me. I might get you a part as the villain in the next Bond movie.]

PMs promptly pithed

John Mansour puts his finger on an issue facing successful product managers: product knowledge is a double-edged sword.

Okay product managers, what has all your down-in-the-weeds detailed product knowledge done for you and your company lately?  Entitled you to more phone calls and emails?  Turned you into first line customer support?  Allowed you to write endless pages of detailed specifications that are more painful than a root canal minus the Novocain?  It doesn't sound like product management.

Mansour argues that, for many core aspects of product management, product knowledge can be a liability for the product manager. Here's an example:

3.  Defining Business/Market Requirements & Business Cases - It's all about defining problems first, and product knowledge is not required to define a business problem.  Your target customers have the same problems today they had 100 years ago.  They just have them for different reasons.  Product knowledge is only required to suggest the most appropriate features for creating the solution. Detailed product knowledge = liability because it forces you more into "how" features should work instead of  "what's needed and why" from a business perspective.

There's one small problem here: your credibility as a product manager depends on your product knowledge. Developers and engineers can smell when someone doesn't know how the current product works, or what is technically feasible. Before you can convince them to take on work, or make mid-course adjustments to what they're building, you have to appear that you know what you're talking about.

Once you've established your cred, the company is happy for the PM to talk about features and functions, instead of the business perspective, for reasons far too lengthy to discuss here. Suffice it to say, your product knowledge is always going to be useful for sales, support, training, and other important activities. Getting strategic, when your daily schedule is filled with tactical responsibilities, is pretty tough.

Short of finding something in your high school biology notes that could tell you how to pith yourself,  PMs have only a limited ability to say no. You can't keep refusing to help with big sales opportunities and keynote demos.

Unfortunately, I don't know what the alternative could be. I've had my moments when my willingness to be an uncompensated sales engineer or documentation writer snapped. Until management understands the price everyone pays for this misuse of product management, it's a situation that's likely to continue.

Here's another reason why I wanted to study product management: no one doing product management can accurately depict these sorts of problems, across the industry, and calculate the costs to the company, not just the PMs. Companies have to reach the realization that misusing product management is like strapping a Saturn rocket to your minivan: Sure, it'll get you where you want to go, but there are far better ways to use these resources.

Sneak peek of the PM tools document

Many thanks to the good people at The Product Management View for the opportunity to talk about the tools product managers use. The presentation was a sneak peek of my upcoming research article about this topic. The View is a good forum for discussions of product management, so we had many good questions during the webinar. Thanks, too, to everyone who attended.

If you're interested (and you can brave seeing my picture again), the presentation is available in both Flash and MP3 format.

Brace yourself

My first official Forrester publication is on the web site. I thought I'd start humbly, with something titled, "The End of Product Development." Then we could fast forward a million years, when human beings are gone and cockroaches rule the world. Before we go there, it's worth pausing to note what the IT to BT transition means for product development in the technology industry.

As a friend and colleague said when I sent him the link, "Gosh, it's weird to see your picture there!" If you can get past the picture, I hope you find it useful.

Postscript: In case you're wondering about the research article about tools for product managers, it's making its way through the editing and production process.

The end of roadmap secrecy?

A long time ago, in a much different job in a galaxy far, far, away, we used to joke that there were three product roadmaps: (1) the customer-facing one, which was laconic to the point of uselessness; (2) the official roadmap for the product team; and (3) the architect's super-double-secret roadmap.

On the other end of the continuum, you have companies like Salesforce, which is willing to make its roadmap visible, to a very substantial extent, to anyone browsing the corporate web site. Salesforce won't tell you everything they're doing, like potential acquisitions or partnerships. However, the IdeaExchange drives product enhancements in a very transparent way.

Most technology companies aren't willing to make their roadmaps as visible as Salesforce's, but the percentage that are increases daily. Open source may have given a cultural boost: anyone with strong enough motivation could add new functionality to the project. However, the open source community won't convince a CEO that it's a good idea to make a commercial product's direction visible to everyone--including competitors.

I can't think of any product, including security tools, that have a good reason to hide every part of their roadmap. Both customer and vendor benefit from openness. For some executives, however, it may feel like they're walking around naked for a little while.

Requirements, shmequirements

Working on the PM tools research (drafted, in editing) has led to a recurrent question: what sort of requirements tool? Requirements definition? Requirements management? Something else?

Does it matter? The distinctions seem a bit arbitrary. The raw data is the same, regardless of the immediate task (collecting, analyzing, using them in a product plan, using them in feature or use case documents, tracking the progress of a release towards meeting these requirements, etc.). Why should these different bits of information be stored and managed in separate systems?

If you don't believe that having a shared repository of dynamically assembled requirements information, go work for a PM group for six months, and count the number of times you type the same information into multiple formats. For example, let's assume Friendly Customer Inc. wants a particular enhancement. A short version of that enhancement request may appear in a list of possible features for the next release. Friendly's use case might be important supporting documentation for the feature write-up. When the CEO demands to know how the company is responding to Friendly, one of the firm's best customer, the enhancement will appear in a slide. And son on.

While you might not want to try tackling every possible use of requirements data in the original application, the natural gravity of product management certainly tugs in that direction. Otherwise, why not just go back to using Microsoft Office, manually re-purposing the same information in new documents for different audiences?

You have to set some boundaries. Still, the borders are pretty wide. Atlassian, for example, has a product strategy that tries to pull all members of a technical teams--developers, QA engineers, product managers, and project managers--into the same suite of integrated tools. They're not requirements tools, in the strictest sense that some people prefer, but certainly the issue tracking part of the Atlassian suite, JIRA, has direct relevance to customer needs that may turn into features. Makes sense, just as much as automated test case generation from a requirements tool like Borland's Caliber DefineIt is a necessary byproduct of what PMs do when writing requirements.

Rather than worrying about how finely you can slice the requirements tools market, the real question might be, How big a collection of functionality should a requirements tool embrace?