tl;dr:
The first step for any organization adopting a product operating model or making a project to product transformation is identifying their products.
This article describes the simple product decomposition model I use to help organizations identify their digital products so that they can then organize teams around them.
Before you dive too deep into this, you’ll need to understand the essentials of product thinking by reading this article or watching this short video. You also need to understand how we describe and evaluate products outside-in, so make sure you read Everything is a product if you haven’t already.
Understand your organization’s products
To apply product thinking to software development in your organization you’ll first need to understand what its digital products are. One way to do that is to use a simple product decomposition model.
Think outside-in
For me the key to understanding products is to think outside-in. That is I start by thinking of the customers that choose the product based on the value they hope to get from it. And then the users who must use that product in order to get that value. It’s understanding those customers and users that allow us to understand where the value comes from and evaluate whether our product is giving them value. Remember:
If your customers and users don’t get value, your organization won’t see a return on its investment.
Once you understand customers and users and how they get value, then you can better make choices about the functionality your product must have to maximize that value.
We start by thinking outside-in from the outside of your company and those end customers and users that choose and use your organization’s products and services. Then, we keep breaking down those end products to find their constituent products.
Products are built from smaller products
Recently I had the pleasure of working with a large company that manufactures trucks, earthmoving equipment for construction and mining, marine equipment, and lots of other things I don’t understand. But, one thing they did understand was that every end product they sold, serviced, and supported was assembled from lots of other parts. And that each of those parts was a product in its own right.
Try this with any physical product you own. I promise if you take it apart you’ll find lots of pieces. Some of them may be made by the company who made your product. Some of them will be made by other companies. For example the tires on your car will have a visible brand name that I can almost guarantee isn’t the same as the brand of your car. We know tires are a product that are part of the car we own.
The other interesting thing is that those component products are likely used across a variety of end products. For example the braking systems used by the truck manufacturer I was working with are used across many trucks and pieces of construction equipment.
Where things get interesting is when you apply this kind of thinking to your digital products. And that’s what we’ll do to build a digital product taxonomy.
Large products are composed of smaller products. Decompose your larger products to identify the smaller products that make them up. Give teams ownership of those component products.
End Products
Start with your organization’s end-products: the things they market and sell directly to end users. For most organizations such as banks, insurance companies, retailers, and many others, these end-products are not digital products. But you can be assured that they all use digital products for part of their experience, and to create, operate, and improve their end products. That’s where other product types come in.
I just took a look at my bank’s website here’s a few of their end products:
So, if this is typical of a bank, their end products are things like:
- Checking accounts
- Savings accounts
- Home loans
- Personal loans
- Credit cards
- Insurance
- Debt consolidation loans
Stuff like that.
I’m drawing a picture as a tell this story. Here’s the first bit of it.
Look at the website for the company you work for and you’ll see its end products.
End-Customer Enabling Products
Customer enabling products support and help sell end products. They help your customers get the most out of their end product.
Ironically to figure out what my bank’s products were I needed to use their website – a customer enabling product. I don’t buy the website. I use the website to understand their products. For my bank I use their website and a mobile app.
Now, when I tell a bank their website is a product, they immediately correct me and tell me it’s not. That it’s a “channel” through which they sell their products. Some organizations get stuck on that product term and hate using it for anything that doesn’t directly generate revenue. I need them, and maybe you, to get over it.
We can operate anything like a product by paying attention to its customers and users, product outcomes, and how those outcomes generate business impact.
The bank’s website definitely has users – the people who buy and use any of the bank’s products. When those users use it it definitely creates value for them. And, what’s more, when the bank’s end customers use the website or mobile app, it helps them get more value from their banking products which results in return on investment for the bank. So, despite the fact that the website or mobile app doesn’t directly generate revenue, we still measure the use of it, the value that bank customers get, and then try to guess at the business impact it might be having.
Does your organization consider its website a product? Does someone own and manage it as a product?
Employee Enabling Products
Employee enabling products help employees support end-customers and support the efficient and effective operation of the organization.
If I keep unpacking my bank from the outside in I’ll find end customers have other points of contact. I’ll often stop in at branches to do some banking. I’ll also call customer service from time to time to ask questions about my accounts. Inside those branches and customer service call centers are employees. And, all those employees need software to do their jobs. All those pieces of software they use – those are products too!
We define those employee enabling products, owners for them, and teams that build and continuously improve them.
We know the users for a call center app are the employees that work in those call centers. We measure if they use what we build, because if they don’t we’ve wasted our time. We also measure improvements in efficiency like answering questions faster. Or, improvements in effectiveness like giving better answers, or leaving customers more satisfied.
We also know that those call center employees aren’t the customers – the choosers. The person who makes decisions about what tools these employees use will likely be someone responsible for call center operations. They’ll be concerned about a value proposition focused on making it easier to hire and train new call center employees, and keeping the call center running efficiently and effectively in order to save the bank operational expenses and improve the bank’s reputation.
If you’re the team responsible for those call center applications you’ll pay close attention to those outcomes and the business impact. You’ll measure success based on those things and not whether you’re delivering more stuff faster.
Does your organization treat the things it builds for employee use as products?
Product Team Enabling Products
Product team enabling products help product teams design, build, support, and improve their products more efficiently and effectively. They’re often APIs or shared components.
If you’re doing this stuff well you’ll identify all those end-customer enabling products and employee enabling products and organize teams around them. Those teams will own the success of their respective products. But, one thing you might quickly notice is that lots of the product teams must build the same functionality. For example the website and mobile app teams need to build functionality to let customers look up their accounts, see balances, make payments and lots of other stuff. The teams that build software for call centers and bank branches also need to build similar functionality to allow employees to do those same things on behalf of their customers.
It would be expensive to ask all those teams to build exactly the same thing. So, we build something that can be shared across all those teams. We call those things product team enabling products.
Product team enabling products generally take the form of APIs, reusable components, or services. Sometimes we call a collection of these things a platform.
Users of these components and services are the engineers in other product teams. They’ll use them to create better products for end customers and employees. So, we measure if they actually use these shared services, how quickly they can learn to use them, how efficiently they can build, support, and improve their products using them.
The customers or “choosers” for these services may be the developers on product teams, or leadership for those product teams. And, you may not think they have a choice, but I’ve worked with enough teams to know that if they hate your shared service they’ll do a lot to bypass it or work around using it.
Partner Enabling Products
Partner enabling products help partner customers create their own applications leveraging your products functionality
When we do a good job productizing our product team enabling products we end up with a pack of services or components that make it easy to build custom applications. Many companies notice that it’s super helpful to release some of those product team enabling products to partners who can build and sell their own specialized products. A great example of this is salesforce’s platform. I’m old enough to remember salesforce before this platform existed – when that platform was just a really well built set of product team enabling tools. Releasing this tools to partners created a huge and growing revenue stream for salesforce.
For the bank I’m thinking through I know they offer tools like this. I’ve never seen or used them, but I do know I’m able to connect my Quickbooks accounting software directly to my bank so that I can see bank transactions in Quickbooks. That’s handy.
For partner enabling products users are the developers who use the platform. You’ll measure if they use it, what services get most used, and if they’re efficient and effective at building customer applications. Your customers are the partners themselves that choose to use your tools to leverage your product’s functionality.
Hybrid Products
Hybrid products combine multiple product types in a single product. You’ll find that many of your org’s products are hybrids.
I recall working with a large chain of brick and mortar retailers. They had a mobile app that their end-customers used. The team building that app also built an employee enabling interface used by merchandisers to configure and set up promotions. The team also provided an API so that other product teams could get data from the mobile app. That single app was: end-customer enabling, employee enabling, and product team enabling.
Here’s where this sucks. Think of every type of product as a separate facet with its own set of customers and users that you’ll need to satisfy. That’s a lot of people to understand and a lot of outcomes to pay attention to.
It’s an onion
The first time I drew this model the person I drew it for pointed out that it looked like an onion. So, I like calling it the onion model. But, it’s not just an onion model because it has layers, it’s an onion because the more layers you peel back, the more it stinks, and the more it makes you cry. (Some of you recognize this joke)
Customers and users come from layers above
If you’re building a mobile app for a bank, you know the bank’s end-customers are both customer and user. But, since you’re inside the onion, you also know that product managers of banking products like loans and credit cards are also your customers. Without your mobile app, they can’t support their end customers.
You may call those internal customers business stakeholders. But, from a product perspective they’re one of your customers. You’ll need to be aware of their value proposition and if they’re getting it.
The deeper inside the onion you are, the more facets our product has, the more customers and users you’ll need to worry about.
Your customers would rather you just do what they tell you to
If you’re creating anything other than an end product your customers are likely employees of your company. You know that customers always come to you with ideas for what they want. And, that they always believe they’re right. But, if you are a team using a product operating model, your team is responsible for the success of the product and not just building what customers ask for.
If your product has multiple types of customers they’ll likely be asking for different things. And, one annoying thing about customers is that they care more about their needs than the needs of other customers. If you work for a bank building a mobile app, the product manager for checking accounts likely won’t be very concerned about the needs of the product manager for credit cards.
The hardest part about managing products isn’t prioritizing features, it’s prioritizing customers and needs.
If your customers are inside your organization, prioritizing customer needs can be politically challenging.
Productize COTS and Package Products
I often work with teams that explain “we don’t build software… we install and configure an off the shelf product, How does any of this apply to me?”
I recall years ago working with a team that was responsible for installing and configuring Box for use in their large corporation. But, they couldn’t just install it and be done. They needed to understand all the types of users in their organization and what they’d be using it for. They need to write training and give guidance to help those people learn how Box fit into their day to day work. They need to craft policy for sharing things with outside customers and vendors. They needed to configure the application to support all this stuff. And, to solve a few problems they needed to write some custom software using the Box API.
Using a product thinking model this team rebranded itself as the “document sharing team.” Box was they tool they used. But they paid attention to how efficiently and effectively employees of their organization were able to share and use shared documents. They took responsibility for the outcomes – the value their org got from Box.
Wrap COTS and package products with a product team that can take responsibility for your org getting value from that product.
Service as a Product
In many organizations I see teams that offer their service as a product.
For example I remember working with a research group in a large company. Product teams would come to them when they needed help with large complicated user research work. The research team would work with the product team and either:
- Do the work for them
- Coach and support them as the team did the work themselves
For this research team one of their products was the service they provided to other teams. Those other teams were responsible for identifying what they needed to learn and for the use of the research that came out.
Over time this same research team developed training to help teams get better at doing research. They developed articles and templates to help teams prepare for user interviews and organize the data they were getting back.
Your team may be a service team. And other people and teams in your organization may be your customers. You’ll need to focus on improving their experience with your service team.
Create your product topology
Use this product decomposition model to identify the digital products in your organization. Basic product types are:
- End products
- End-customer enabling products
- Employee enabling products
- Product team enabling products
- Partner enabling products
Describe each of your products. Try this simple template as a starting point for describing your products outside in.
Organize teams around these products. Give those teams the responsibility for creating, maintaining, and continuously improving their products. This is where I use my continuous product improvement model.
There’s more to add here about:
- The composition of a product team
- How teams may one a single product, multiple products, or an area of a larger product
- How teams of teams work together on large products or families of products
- How teams coordinate, collaborate, and manage dependencies when making strategic changes
Stay tuned for more on those things. Or, attend one of my upcoming workshops. I talk about it all there.