The essential foundation for effective product communication
by Rachel Potts
by Rachel Potts
Over the last few years, I’ve run consultancy projects with a wide range of different technology companies. There have been quite a few projects where my role is to recommend a strategy to ensure that technical information about the project is available to the people who need it. Or to look at it from a slightly different angle, that people who know stuff about the product or service communicate it effectively to people who need to know.
I start by interviewing a range of people in the business (and often outside it too), and getting them to show me the information they create about the product. As they show me their different sources, I find I’m not just looking at one company and one product … in fact it’s more like there’s a range of related products. Or at least, that’s how it seems. The reality is that there is at just one product after all, but the ways different parts of the business are describing it are so different that they might as well be talking about different products.
Here is how people from across a business describe their product:
Development: split the product into modules or areas that relate to how the product is made. For example, in software it’s common to talk about Core or Back-End, UI, and integration modules.
Marketing: talk about the product in terms of its features – particularly its unique or more saleable features. They don’t care what components an application is made of; only that it can run on a range of common browsers and can perform a range of dazzling feats of technological wizardry.
Implementation: describe the product in terms of the set-up options. This often includes core components (not the same as Development’s “Core”, though), plug-ins or add-ons, and configurable features.
Sales: often talk about the product in terms of what you can buy: the basic version plus optional upgrades; numbers of concurrent users.
Support: often describe the product in terms of specific customer installations, and which features or plug-ins they’re using.
And so on…(sorry if I’ve missed your part of the business, but hopefully you get the picture)
It’s a bit like the “Blind men and the elephant” tale: each person approaches the product from their own direction, and therefore is unable to relate what they encounter to what their colleagues encounter.
In many cases, businesses can function effectively around these different viewpoints for some time… But then circumstances arise where they start to create issues for the business, and of course that’s usually why someone like me is brought in.
The problem of multiple ways of viewing the product starts to become an issue when different parts of the business need to communicate with each other, and when different parts of the business try to communicate with the same customer. The result: rapidly increasing costs, time delays, difficulties growing the team, customer complaints.
Some examples of the kinds of issue each of these communication mismatches can cause:
A clear definition and description of the product which is used as a reference point by everyone across the business is an effective way to start solving a lot of the issues I’ve described. If a business I’m working with doesn’t have one of these, or has competing ones, it pretty much always struggles to implement and support products eventually, and the customer experience is poor.
Just to be clear, I’m not necessarily talking about a detailed product specification. In fact, in most cases that’s the wrong thing to use because the level of detail will make it inaccessible to parts of the business. The product description can be as simple as a diagram plus a few paragraphs of explanation…what matters most is that it that it’s easy to understand, well-structured and formatted and easily accessible.
I also don’t have strong feelings about where in the business this product description should come from. Some companies base it on their technical product specification; others on their marketing materials; or anywhere in between. Whichever approach the business takes, the result is not going to be a complete description that encapsulates every departments’ viewpoint. But the key thing is that the same product description is referred to by everyone within the business as a reference point. Everyone in the business still encounters a different part of the elephant, but at least they can now see the elephant, and they know which direction they’re encountering it from.
For example, when marketing write their feature lists, they understand how those features relate to the product description (note that this doesn’t necessarily mean they use any of the words from the product description in the content they create); when development add a new feature, they understand how the affected component relates to the product description. And so on.
The process of creating this product description is powerful in itself, and providing the resulting product description is well written and has backing from the right parts of the management team, it is often quite rapidly instrumental in transforming internal communications, with the resulting impact on customer communications too.
Originally published 11.08.14
Rachel is our Lead Consultant, advising customers on documentation strategy, and helping our growing team of technical writers to develop their skills and hone their insights. She is a Member of the Institute of Scientific and Technical Communicators and also contributes to the ISTC’s award-winning journal.