Leading Product Edition 4

Hello, again | Your Product is not a Service | The Metrics-Driven PM | Product Function Maturity | Product Thinking | Contemplation and Sign Off = 11 minutes

May 10, 2021

🤗 Hi

Welcome or welcome back. Thanks for signing it up and please share LP with product people in your life, if you think they would enjoy it! A long product newsletter follows…

👕✨ Your Product is Not a Service (Unless you make it one)

Products and services. Services and products. This is Part 1 of n, the first foray into a fundamental product area that’s vast, so I don’t know when it will end.

I think about this a lot - when is a product a service, and how does the service make it successful? It can be anything: a car, some note-taking application, your favourite speakers. Is it the product, or the service dimensions that makes it something worth having? It’s both.

The rise of Everything-as-a-Service (XaaS) model has come to define the way in which companies have been able to scale offerings that traditionally relied on a tangible good, but what could be sold as a service-only (rides, places to sleep, etc.). For the purpose of this essay, I’m less interested in the so-called marketplace trend. (Pls consider reading Kevin LaBuz’s “Marketplace Existential Threats” for a great take.)

This is about “traditional” products - physical or digital - and how much the associated service layer is make or break. There are lots of services with no tangible product; but products cannot be successful without elements of service.

When constructing your product and its ecosystem (suppliers, channel partners, distributors, customers, agencies, etc.) the service dimensions must be defined and accounted for. Some (or most) of the service delivery counts as SG&A and we hate SG&A, as we should minimize it. But we can’t minimize it if we can’t see it and understand how to parse the critical from the fluff. Over time, a system will accrue fluff.

What do I mean by service dimensions? Do all products have them? Probably not. A t-shirt isn’t really interoperable; but the t-shirt retailer might consider how the service dimensions discussed impact a distributor’s decision to buy. On second thought, maybe interoperability does apply. The shirt has to match an outfit. It has to be easy to wash (dry clean only is fine for some stuff, but not all). And clothing needs to fit into a certain cultural context, depending on the wearer’s preference. So there.

Some (but probably not all) service dimensions that could / should apply to almost any product.

Let’s dive into five service dimensions I consider to be especially important. This is drawn from my experience working in Business-to-Business (B2B) SaaS. Someone in the Business-to-Consumer (B2C) space might consider other dimensions or weigh them differently. Totally cool. Please weigh in with service dimensions you consider critical to the success of your product!

Customer support

Users will encounter issues and need help after a purchase or during the lifetime of a subscription. To what extent have you oriented your customer support (CS) to product success, and designed the product to reduce the burden on CS such that common issues are resolved in-product, or automated to the extent possible. It makes a huge difference, and a cursory search of social media will showcase when a product might be lacking in CS investment. Support is expensive, and all aspects should be measured with a view to reduce cost and increase customer satisfaction over time.

Brand recognition

Shared with marketing, the brand’s reputation and recognition are important service dimensions that shape not only a person’s decision to purchase, but to remain affiliated as a user. For example, if the brand is built on sustainability with a strong ESG component, significant shifts to those tenets will resonate in the customer base.

Ability to co-create

Are customers involved in the direction of your products? Do they have a say in the development process? This can be as simple as an AMA online, like the one IFTTT’s founder CEO did the other day.

Updates and relevance

Does the product receive updates and does it remain relevant as technologies evolve and preferences shift? Is the product ‘timeless’ to the extent that customers benefit from innovation in a platform and product family. For example, a firm ships a better, longer-lasting battery for the same appliance. Or, a software avoids obsolescence by receiving regular updates and security patches. Believe me, it doesn’t always happen.

Interoperability

How well does the product fit in with the customer’s life and other products used in the course of a day or for a given task. This is why protocols are powerful and Bluetooth-enabled devices are prevalent; proprietary and one-off interfaces are not likely to be very useful. The user gets more out of your product in combination with other ‘things’ than on its own.

In closing

I’ll reserve a conclusion for now. This is a series, probably. I want to continue to explore the idea of service dimensions and how products - especially commodities - can distinguish themselves. It’s bugged me for a long time. Just because a product is sold on a subscription / consumption basis, doesn’t make it a service!!

🔢 Metrics Drive Us

Each edition we deep dive on a key skill or term. It would be hard to find a job post that didn’t mention metrics…

At your next interview, you’re asked: “Are you a metrics-driven product manager? How?” Your prospective employer wants to know how you measure what matters to ship good product. Metrics - things we quantify and track - lead to good decision making. At least, that’s the hope.

In the realm of product (and services!) there seems to be no end to the things that can be counted: downloads, purchases, conversions, support tickets, churn, DAU:MAU ratio, and so on. Metrics typically fall into three categories: financial (performance in the marketplace, as well as costs); operational (throughput and output, THE WORK); and, user-centric (everything to do with engagement and the customer experience). Yes, there is overlap.

It’s never too late to start counting; if a metric went uncollected for a long time, it might be hard to propose it (there’s nothing to compare it to!) but it’s important to start to count before deciding if it will or won’t be useful. A lot of metric collection is automated these days. Consider Jira and the ability to see the issue lifecycle: when was it made, how long in the backlog, how long it take to resolve, etc.?

That’s great. But metrics won’t often tell you why; that’s where you come in. Product people need to take the metrics and make an inference about their meaning, in order to drive change. It’s not enough to simply count the countable; you need to have a sense of what the metrics drive. You need to do something with all the data. Seeing more churn? When did it start? What’s changed? Metrics make sense in context.

It’s hard to measure in a vacuum. If you’re the only one counting, does it matter? Some firms are very metric-oriented and will have processes and established norms related to the collection and aggregation of the quantifiable. This is typically a sign of maturity (pssst see below). In other cases, you need to lead the way.

Action

⭐ Write down two north star metrics, one for self, and one for your product.

🐵 Product Function Maturity

Found in scholarship

In a recent article, Marina Brunner and Christian Schieder offer a maturity model for product management. It’s rigorous and merits consideration. Any firm that wants to know if the product function is mature could leverage this kind of framing to critically understand where they are, and what needs work.

Objects of the maturity model described by Brunner and Schieder in their article. The objects (or tasks) are arrayed in accordance with product lifecycle phases.

The study validates the proposed maturity model, which is comprised of 22 different tasks (or objects) and five maturity levels characterized by the degree to which a person or team has implemented various dimensions, such as frequency of execution and Key Performance Indicator (are metrics used and are they of good quality?).

Check out the entire article for the model and how it was applied for various firms.

Share Leading Product

🛣️ Product Thinking: Journey Not Destination

Found online, a great post by Eduardo Da Silva, who writes prolifically about socio-technical systems, Domain-Driven Design, and scaling effective teams to operate products and services.

As a student of systems thinking, I follow Eduardo Da Silva and (try to) read all of his work, along with similar explorers like Nick Tune and Ruth Malan. Eduardo’s most recent article is summarized below, and please read it for the complete picture (summaries are meant to give you a sense if you want to go read the piece in its entirety, and not to act as a complete substitute).

I've been exploring socio-technical systems recently, and the value of Domain Driven Design, which isn't new but may be in a bit of a renaissance. To that end I wanted to share a recent article by a key proponent of both concepts, Eduardo Da Silva.

Eduardo goes over the traits necessary for a system to effectively ship customer-centric products: organizational shape, understanding of context, recognizing the interconnected value streams, and empowerment to discover what to build. The ultimate goal is to ensure the system can evolve (scale) and implement product thinking to achieve high velocity value delivery.

New or well established firms will benefit from framing their work in this way. Leaders need to maintain a holistic perspective such that optimizations aren't overly localized or imbalanced; the whole system needs to support an orientation to .

Eduardo connects the teams, technology, and customers / market: they all affect each other; the way they affect each other changes constantly (product-market-context-fit isn't static).

To try to make it practical for the reader, questions that product people and firm leaders can ask from time to time:

Have we done value stream mapping across our teams, and do we understand how they intersect and support each other to deliver?
How do we need to evolve the team (hiring, acquiring, upskilling) to get the most of a new technology we're implementing?
Are we gathering all possible signals from our user base to shape the roadmap and remain relevant? What expectations are unmet, and what needs to change to meet them?

🙋 What other questions would you pose based on Eduardo’s article?

🦊 Contemplation

What’s a north star metric for self, and how can you track and measure it?

❤️ See ya

Thanks for reading. Have an awesome week.

Leading Product