Empower Others with a Product Brief

In my first sit-down with a marketing agency, they peppered me with questions about the product and the market. They wanted to know about clients, their problems, our solution, and why our product was better than alternatives. After a few minutes it finally hit me: “Do you want my product positioning?” And I pulled a product brief document out of my case with all their questions already answered.

Over the years I’ve learned to empower teams with the information they need about the product as well as the context of the product: the personas and their problems, the product vision, the roadmap, and the product status.

A product brief can be used with executives and investors, developers and support staff, marketing and sales people, and anyone who needs to be kept in the loop about your product.

Personas

First and foremost, your teams need to know about the market you serve. The favored technique today is to define and share your market and product personas—those who buy your product and those who use it. For me, personas are the embodiment of a market segment. Understanding these personas empowers both marketing folks and developers.

Marketing teams will want to know about all the buyers who influence the purchase of your product, their typical approach when making purchasing decision, and the demographics necessary to target them with marketing programs. Developers need to know the working environment and skillset of the people who use the product. It’s likely you’ll provide different information about those who buy the product (market personas) and about those who use the product (product personas).

Remember, we market to buyers; we develop to users. Remember, we market to buyers; we develop to users.[tweet this]

Product vision

A product vision document explains the product basics. What does it do? How does it solve persona problems? What are the key features? And of course, all of this is written in the language of the buyer, not the language of a developer. Some marketing teams use the term “positioning” for their product vision.

The easiest way to share your product vision is to use a reference: “it’s like __ for __.” It’s like [something they already know] for [new market or application]. For example, the Amazon Kindle is like an iPod for books.

The product vision is where you’ll use your traditional feature/function/benefit language. Different personas value different features so I try to find three or four key features that benefit each. I’ll typically have a positioning section for each persona: for instance, the user might want to know about 24/7 support while the buyer might care more for implementation assistance.

Product roadmap

Although your sales and promotional materials shouldn’t talk about futures, you’ll find a product roadmap is appreciated by most teams.

The CTO of a software vendor complained that his people had just completed two projects that did roughly the same thing. If he’d seen the product roadmaps, he’d have known to combine these two projects into one. Ideally, the product leaders should be sharing their plans and considering the overall portfolio before tasking the product teams to build duplicate functionality.

A roadmap helps the developers see the next few product phases so they don’t make decisions now that cause technical debt later. A roadmap helps your marketing and sales teams to know where the product is headed over the next few releases. An roadmap shows the current set of core capabilities, what’s planned next, and what’s beyond.

Of course you’ll want to make sure your teams know that roadmaps are plans, not commitments. Of course you’ll want to make sure your teams know that roadmaps are plans, not commitments. [Tweet this]

Product vision drives messaging

Before I create a conference presentation, I develop the messaging—in this case, the blurb with an abstract, target audience, learning objectives, and key takeaways. It’s best to author this when I don’t have a deadline. And once it’s complete, I can copy the information to paste into an email to a client or into a conference submission system.

Shouldn’t you do the same for your products?

Your product vision and your roadmap should be all your marketing team needs to develop market messaging.

Today’s product managers are often tasked with writing technical copy for their marketing teams. After all, product managers and product owners have technical knowledge, domain knowledge, and market knowledge. Put what you know into a product brief. It’s certainly easier to write it once well and then use it again and again.

Your marketing team will appreciate the context and the written blurbs that they can re-use. And with some wordsmithing a good marketing writer can make your text even better. Even if they don’t change it, if you’ve done a good job of writing, they can use it as-is on websites, product brochures, ebooks, and so on.

Stay in sync

Each month (and perhaps more frequently as a product launch approaches) you’ll have a status meeting with different departments. The product brief is a good tool to get and keep everyone on the same page.

A product brief is a key part of your product playbook—a collection of workshops, tools, and templates to ensure your team is systematic in their methods and consistent in their deliverables.