Use better product management jargon

Towfiqu barbhuiya

When you believe that words matter, you inevitably become uncomfortable with calling things what everyone else calls them. You’ll want to modernise your product management jargon.

Opportunity > problem

Product managers love to ask what problem do you want to solve? This helps us focus on the problem space, and avoid getting sucked into premature solution design. However, products can do more than solve customer problems. Products can also delight customers, and give them new ways to succeed. Products can have a strictly positive impact.

Therefore, talk about opportunities, and include those with a positive impact, not only problems. Some people like to call them bets, but not everyone likes the gambling association. Just don’t call your product document a product requirements document (PRD), which sounds like something from 1980s corporate IT.

Customer need > problem description

We sometimes write up discovery in a problem description that describes a customer pain or annoyance. However, discovery doesn’t end when you’ve described a problem, because you can’t always assume that customers need a solution.

Therefore, go deeper and identify a customer need, the first step in mitigating demand risk. Similarly, useful solutions solve problems, and so worthwhile problems address actual needs.

Idea > feature request

Some product teams collect their customers’ feature requests, which usually results in an infinite backlog. However, unless you work in IT consulting and outsource software design to clients, you don’t get paid for implementing feature requests: they contain feedback, not commercial orders. You also get stuck trying to resolve requests for overlapping or conflicting features.

Therefore, welcome customers’ ideas, and clarify your relationship with them. This reframing makes it easier to recognise that you will receive bad ideas as well as good ones. Ideas overlap, and may reflect underlying needs in a feature abstraction layer. But take care with customers who may think that you don’t take their ‘requests’ seriously.

Solution > feature

Feature lifecycle management keeps track of software changes, and does a lot to make intangible work more concrete. However, not all software changes add features, and not all work changes the software.

Therefore, design solutions to customer needs that include non-features such as bug fixes and performance improvements, plus non-software improvements such as documentation updates. The term solution works better because it describes the work’s outcome, not its output.

Task > issue/ticket

Several popular project management tools have issues, which sometimes represent all kinds of tasks, and only sometimes represent actual reported problems. This includes newer tools that did not start as bug/issue trackers, or help desk ticket managers. They should know better, and didn’t need to inherit this obsolete naming.

Instead, call these units of work tasks, to better align with how teams use these tools. Even better: consider using a tool that you can configure to customise their names.

(Anything) > insight

Product managers, and product marketing in particular, also seem to love the term insight. However, intended meaning often remains fuzzy, or perhaps has a placeholder meaning: an insight represents whatever value you want it to have!

At least the term issue means something specific to the people who use it, even if the word entirely loses its original English meaning. Therefore, replace insight with just about anything else, as long as it actually means something.