Three languages: Disentangling our desires, needs, values, and work

source

Using the right language for each context

On the same team, yet at cross-purposes

The CEO asks “Why isn’t ‘grow revenue’ your main goal for the quarter?” She’s not wrong; revenue is the reason we’re all here. The Product Manager says “My goal is delivering value to the customer, as quickly as possible. Revenue reflects more than that—sales effectiveness, marketing effectiveness, and market swings from things like COVID or inflation or economic pull-back.” He’s not wrong: “Revenue” is a shared goal and might not be correlated with product development or even customer satisfaction.

The customer says “of course everyone needs [feature], so it’s crazy that you don’t have it.” The Product Manager tries to understand the underlying pain, the core “job that is being done.” The customer feels like they’ve already explained what they want. When the feature isn’t added in the next release, the customer thinks no one listened to them. The Product Manager knows that the feature wouldn’t make sense to the other customers, but an update later in the year will solve the use-case in question.

The marketing department asks what features will be delivered by September 17th, because that’s when the big global event is happening. The finance team wants projections for the next twelve months, not just because they’re filling in spreadsheets (although that too), but because projected revenue informs hiring plans in sales and support, and investment plans in marketing, and with a six-to-nine-month lag time for hiring and training, we have to take that action today. The product team has a firm plan only for the next two-week sprint; who knows what will happen next year?

Three Languages

The solution to resolving these conflicts is to recognize that there are three distinct “languages” in the business.

I mean “languages” literally—people using different words, even when they’re talking about similar things, like the marketing calendar, the fiscal quarters, and the sprint planning. But more than words are the concepts, the goals, the requirements, the challenges they face every day.

Conflicts happen when one party applies their “language” (and concepts, goals, and needs) to a party that uses a different language. It doesn’t work. And it’s up to both sides to create systems that not only translate, but that help achieve each others’ goals.

Language of the Customer

This is what I’m trying to accomplish. This is what’s preventing me from doing my job. This would make me a hero in the eyes of my boss or client. This would make me more money. This would increase my reputation. This de-risks my project. This is what I agree to say in a case study. This is what I’m going to say on Twitter. This is what I’m putting in an online review.

Language of the Product

Strategy: How we will win. Competitive and market analysis. Long-term versus short-term competitive advantages. Defining the ideal customer. Creating value for the customer. Scrum and kanban. Sprints and frequent delivery. Epics and stories and cards. Tasks and bugs and features. Delivering “customer value” (whatever that means). Retros. Sequencing. Feature-usage and abandonment.

Language of the Business

Growth. Profitable / sustainable / maximized growth. Profitability. Sales and marketing efficiency. Product ROI. Predictable results. Annual planning. Hiring plan. Budget-to-actual.

Translation

Of course, everyone is “correct,” in the sense that everyone’s needs are critical for the success of the business, and they are using appropriate language for their universe.

Therefore, we need translations to bridge the languages. And generally it’s Product’s job to do it.

source

Translating from “Customer” to “Product”

The bridge between customer language and product language, in modern terms, is the JTBD (Job To Be Done), further broken down into the “story.”

The customer can completely describe their own pain or requests, and often has ideas for features but lacks the context (and often the expertise) to combine the desire with the constraints of development, in general and vis a vis future architecture and other customers’ feature requests. Product work requires definition—requirements, requests, enough of a description so you’d know whether a given result was what is being requested.

The high-level translation of the customer’s life into product language is JTBD, in which you recast their world in the internal language of your company. For example, in WP Engine’s case¹, customers worried about “hackers,” or scared that getting hacked will hit the news, or will cause expensive damage (their language), would be translated into JTBD concepts like:

¹ Top ten public website platform, as measured by domains in the top ten million, ordered by traffic

• Context: Marketers don’t want a security breach to (a) hurt brand, (b) cost them money/time.
• Inciting Event: After getting hacked once, marketers become highly motivated to move their website to a secure platform, even at a significantly greater cost.
• “Job” to be done: Make my website fast, scalable, and secure, while I never have to think about it.

While that characterizes the customer’s life in company- and product-centric terms, it’s not yet a list of things to actually do, which is another role of product. Here we use the language of work. A common tool is the “user story,” which often comes in a form such as:

• As a [who], I want [feature] so that I [benefit] because [why].

Applying to security, we might have:

• As a [non-technical marketer], I want [a report about how many nefarious attacks were thwarted in the past week] so that I [can show my boss] because [it proves I’m proactive and intelligent about security; if we get hacked, my job is secure].

Now we can do the work.

Translating from “Product” to “Business”

The bridge between product language and business language is a matter of using the same language for high-level strategy and goals, and an understanding by both parties that Product is one of several inputs into the needs of the business.

Often the most critical thing the business wants to know is “how much will we grow?” Of course much of this comes from Product:

• Are we positioned intelligently and competitively?
• Are we targeting the right market segment?
• Is our product paying off the promise we make on the website?
• Are we building the right features?
• Do we have the right pricing?
• Are customers delighted by our product, so much that they advocate for us with word-of-mouth and great reviews?

But much doesn’t:

• Are our marketing campaigns effective?
• Is our sales pitch and sales organization effective?
• Is our white-glove on-boarding team being effective?
• Is our support team increasing retention?
• Is our account management team building high quality relationships?
• Is our corporate development team building high quality partnerships?
• Are we expanding well into new geographies?
• Are we budgeted properly across the company?

Therefore, it’s Product’s job to clearly articulate how they are contributing, without having full responsibility for all of the impact to the business’s desires.

A good way to do this is with this metrics framework, in which everyone’s KPIs are represented as being important, but with the right context and areas of responsibility and accountability.

Using the right language for the right things creates clarity and insight and helps us work better together.

Printed from: A Smart Bear
https://longform.asmartbear.com/three-languages/
© 2007-2024 Jason Cohen      @asmartbear