Disentangling the three languages: Customers, Product, Business

source

Using the right language for each context

Punchline first:

One team, yet 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¹.

¹ My solution to this “who is responsible for what number” problem is in this article about Product KPIs.

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 that they’ve already explained what they want. Six months later, when the feature still isn’t added, the customer thinks no one listened. The Product Manager knows that the feature wouldn’t make sense to most other customers, but a different 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 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 nine-month lag-time for both hiring and training, we have to start that process today. The product team has only planned out the next few sprints, because who knows what will happen later in the year; we’re agile!

Three Languages

The key to resolving these (apparent, not real) conflicts is to recognize that there are three distinct “languages” being spoken simultaneously.

I mean “languages” literally—people using different words, even when they’re talking about similar things, like the marketing calendar, the fiscal quarters, the sprint planning, the feature-prioritization, and the jobs-to-be-done-that-the-customers-are-doing. And beyond words: the concepts, the goals, the requirements, the specific challenges they face each day.

Conflicts happen when one party applies their language to a party that is using a different language. It doesn’t translate automatically. So it’s up to us 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 fulfills a higher-level need. This de-risks my project. This is what I will say in a case study. This is what I’m going to say on Twitter. This is what I have written in an online review.

Language of the Product

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

Language of the Business

Growth. Profitable / sustainable / maximized growth. Profitability. Sales and marketing efficiency. Product ROI. Predictable results. Annual and quarterly planning. Hiring plan. Budget-to-actual. Ratios that increase the stock price relative to current revenue.

Translation

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

Therefore, we need translations to bridge the languages. And often in a high-tech company, it’s Product’s job to do that.

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.”

Customers can completely describe their own pain or requests. They often have ideas for features but lack the context and expertise to integrate their desires with the constraints of development, in capacity and against architectural evolution and other customers’ desires. Product work requires definition—requirements, requests, and enough of a description that everyone can decide what work might result in the desired outcome.

The high-level translation of the customer’s life into product language is the JTBD, in which you project their world onto internal language of your company. For example, in WP Engine’s case², customers who are 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 the percent of the highest-traffic ten million domains.

• Context: Marketers are scared of security breaches that (a) hurt their brand, (b) cost them time and money.
• Inciting Event: After getting hacked once, marketers become highly motivated to move their website to a secure platform, even at increased cost.
• Job-to-be-done: My website is fast, scalable, and secure.

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 forms such as:

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

Applying to the security sample, 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 still hacked, my job is still secure].

Now we can do the work.

(And we can write the sales and marketing copy; this is exactly the bones needed for a sales person to explain both what the product does, and why it matters, from the point of view of the customer.)

Translating from “Product” to “Business”

The bridge between product language and business language, shows how the activities of product advance the strategy and goals 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 made 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 stay forever, growth with us, and advocate for us with word-of-mouth and great reviews?
• Are we expanding into adjacent segments and products, at the right time?

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 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 the total impact on the business’s goals.

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

The first step in resolving these apparent conflicts is to recognize that everyone is doing what they think is best, operating from their own area of excellence. The second step is to translate.

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