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.
Different parts of the business have completely different viewpoints
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.
Incompatible viewpoints lead to increasing costs, time delays, difficulties growing teams, poor customer experience
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:
When different parts of the business can’t communicate with each other…
- The marketing team are given a list of upcoming product improvements by the development team, but they don’t understand what they mean
- The sales team sell something that’s not technically viable
- The support team report a bug, only to be told by the development team that in fact this is just how the product works
- The support team don’t make use of carefully crafted and reviewed technical product information from the development team, but instead create near duplications from their own viewpoint
When different parts of the business try to communicate with the same customers…
- Customers read the marketing blurb and the technical product description, and end up more and more confused
- Customers are trying to troubleshoot an issue, but they find conflicting information about what to do – often on what seem to be entirely different websites from the same company
- Customers buy a product, but when they come to install it they struggle to make sense of which parts modules or options match up with the product features they think they’ve bought
Want to find out more?
A single, accessible product description is an essential foundation for a business to communicate about its product effectively
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