You want to make your teams more effective and you want to make sure everyone in your organization is focused on the right things. A sure fire way to do that is to change the model to organize your work from project based to product based.
That seems easy to say, but it can be difficult in practice. You need to make sure everyone understands what that means, and what the implications are for them. To make that transition especially important, you need to make sure the leaders in your organization support the move and have your back.
Convincing some of your leaders, especially those that naturally work in a product fashion, is easy. For others, the sales job is a bit more involved. You’ll find that you need to help them understand what moving from product to project means. Then, you need to explain how it will benefit them.
Here’s some suggestions on how to explain product management to non-product leaders in the hopes that they become some of the most fervent supporters of your product transformation.
What is Product Management?
As a starting point, you want to make sure you have a shared understanding of what product management actually is. Product management is helping your customers solve problems in a way that is beneficial for your organization.
Effective product management involves working with a stable, durable cross functional team to address four main risks as identified by Marty Cagan.
- Identify problems that your customers find value in having solved.
- Solve those customer problems when it’s viable for your organization
- Create a solution that’s usable for your customers.
- Identify a solution that’s feasible for you to deliver given the time, skills, and technology you have available.
Product management applies to external and internal products
That definition is intended for products that you sell to your customers. It also can apply to the systems and applications that you use, but don’t actually sell to customers.
In some cases your customers interact directly with those systems. For example, if you’re a retailer, your customers interact with your website to order products online to get support for products that they have already purchased.
In other cases, your customers do not interact directly with your systems, but the systems enable your interactions with customers. For example, if you’re a retailer, you probably have a system to manage your supply chain. Your customers don’t interact with that directly, but it does enable your interactions with customers.
Product management keeps the focus on the customer
There is value in viewing all of those systems as products in their own right. This product management perspective encourages you to consider your customer in all decisions about your organization’s systems. For some systems – those that customers directly interact with – the thought of considering customers is a no brainer. Considering the impact on customers when you look to change an internal facing system may initially seem a little counter intuitive.
Let’s say you’re an insurance company and you’re considering a change in the system you use to manage your HR data. It may seem at first as though your choice of HR system has no impact on your customers. If you think about it a little more, there can be some indirect impact. If you spend time and money on updating your HR system, does that preclude you from improving systems that your customers do interact with. Also, are there aspects of the HR system that impact your employees ability, or willingness, to ensure excellent interactions with your customers.
Why should I move from project based to product based organization?
Most organizations organize the work they do to update existing systems and processes or implement new systems and processes using a project based approach. That approach to project based work influences:
- How your organization decides what work gets done
- How you fund the work you decide to do
- How you structure the teams that do the work
- How those teams perform that work.
The move from project management to product management drives changes in those four items that ultimately will make your organization more effective,
How you decide what work gets done
A project management based approach requires that you put a business case together that sells the case for doing the work required for the project. In order to craft the business case, you need to know how much it will cost, which means that you feel the need to craft a solution. The unfortunate thing is, you’re crafting that solution without the knowledge you can gain from working on the problem.
In contrast, A product management approach identifies specific problems that you want to have your teams work through. Instead of determining how much a solution costs, you instead indicate how much you’re willing to solve the problem.
The product management approach doesn’t require you to develop a solution that may or may not produce the outcome you seek. You aren’t forced to make decisions based on estimates crafted with limited information. Instead of assuming certainty, you accept uncertainty.
How you fund the work you decide to do
The approach to funding projects ties closely to how you decide which projects you undertake. When you make decisions about the projects that will happen, they often get funded for the amount contained in the estimate. Keep in mind that those estimates are based on limited information and usually end up being inaccurate.
In a product based approach, you don’t fund a project to produce a specific solution, you fund a team to accomplish a specific outcome. Instead of relying on estimates for producing a solution you really don’t understand, you indicate how much money you’re willing to spend to accomplish an outcome. You may find that the team can reach an outcome for less than you budgeted in which case they can then tackle an additional problem.
The product based approach to funding avoids the endless cycles of estimates and reviews which inherently get to a number that you’re willing to spend anyway. Think about past funding discussions. How many times did you provide an estimate to accomplish something and were told to “work harder” to get to a specified number that was 30% less. Why not just cut to the chase and set that number as the starting point and provide your team with the flexibility to figure out the best way to solve a problem by actively trying to solve the problem.
How you structure teams that do the work
When you form a project team, you typically pull people from several different departments to work together over a limited time to complete the project. It’s possible that your project is not the only thing they’re working on. In some cases you may find that everyone on your project team is also on three to four (or more) other project teams at the same time.
Even if everyone on the project team is focused on one project, the team is not permanent. Once the project is over, everyone goes their separate ways, even if there are still several things that need to change with the system that the project team couldn’t get to.
In the product based approach a dedicated, stable product team owns responsibility for that product. That means that the team is focused on work for that product and that they will stay together even after they achieve their desired outcome. That means if there are other changes that could be made to the product in order to exploit new opportunities or solve a problem that comes up, you have a team available to do that work.
When you have a long standing stable team, you reduce the risk of losing the knowledge that the team formed when working on the product. All attempts at knowledge management aside, when you have people familiar with a product working on it, you’ll be able to make changes more effectively and efficiently.
How those teams perform that work
In a project based approach, once you form the team you ask them to deliver a result based on a certain set of constraints:
- A scope defined as the outputs deemed necessary to deliver the solution identified in the business case
- A budget based on the (often revised) estimate from the business case
- A timeline based on the (often revised) estimate from the business case
When you consider that the solution was identified without too much information, it’s likely that the scope contains either more items than are really necessary to solve the problem, or it details a solution that won’t often solve the problem.
As a team starts work on a project and gathers a better understanding of the problem, they may want to adjust their solution. At that point they’ll incur overhead as they have to work through change control processes. These processes exist based on the assumption that the original constraints are correct and you don’t really want to have changes to the plan without a really good reason.
In a product management based approach the scope of a team’s effort is more broadly defined as the outcome you’re trying to reach. That provides your team with much greater flexibility to adjust what they actually deliver based on what they learn as they start work to solve their problem.
You may still work with time and budget constraints, but these are based on your appetite for solving the problem. In effect, what it’s worth to you to reach a specific outcome.
What should the C-Suite know about a product based approach?
To successfully adopt a product based strategy, you’re going to need support from all levels of leadership in the organization including the CSuite. If you want their support, you’re going to have to be able to explain a product based approach in terms meaningful to them. Here are some key points you’ll want to hit on for the different members of the CSuite.
Chief Executive Officer
The CEO sets the direction for the entire business which includes the outcomes they want to achieve in the next quarter and year. Hopefully those outcomes are expressed in terms of meaningful metrics.
When talking to a CEO about management, you’ll want to speak to how a properly formulated product strategy is directly lined up with business outcomes. You’ll also want to point out the customer focus aspect of product management.
Chief Operating Officer
The COO is concerned about the day to day operations of your organization and is often concerned with many “back office” functions such as recruitment, training, payroll, legal, and administrative services.
When explaining product management to the COO, talk about how product management ensures that efforts on products used for operations still has a tie to the impact on a customer. You’ll also want to remind the COO that the long standing nature of product teams will ensure that when changes to operational systems are warranted, there will be teams available to do that work.
Chief Financial Officer
The CFO is responsible for your organization’s financial affairs, including annual budgets, managing cash flow, and overseeing finance finance reporting and compliance.
The main thing about product management that the CFO will be concerned about how work is funded and how you track progress. In this case, you’ll want to talk to the CFO about funding products, not projects – meaning that you’re funding a team to work on delivering specific outcomes. You’ll also want to explain how to measure progress and success in a way that provides faster feedback than simply ROI.
Chief Revenue Officer
The CRO is responsible for all the revenue related functions including marketing, sales, customer support, pricing, and revenue management.
The CRO is definitely going to have interest in product management when it comes to your organization’s actual products. In that case it’s important to establish clear agreements on the rules of engagement between sales, marketing and product teams. Ideally, for those teams working on external products, you’ll incorporate sales and marketing people on those teams.
When talking to the CRO about product management in general you’ll want to stress the customer focus aspect of product management and make sure you have a productive relationship in how you work with the sales and marketing organization.
Chief Information Officer or Chief Technology Officer
Both of these CSuite occupants are responsible for the technology of your organization. The main difference is the CIO is responsible for the internal technologies of the business. The CTO is responsible for technologies that a company offers externally to grow.
In both cases your discussion points about product management surround how the teams are structured and how they work. You may find that the CIO or CTO are already highly supportive of having standing product teams.
Where you may have some convincing to do is where it comes to incorporating people from the operational parts of the organization into the product teams. Afterall it may make sense to include someone from the Claims Administration department on a team that’s working on a claims system.
Why you should undertake a product transformation
A product transformation is when your organization decides to adopt a product management approach to managing work that makes changes in systems or processes. That also means that you explicitly treat all your systems and applications – whether external or internal facing – as products.
It’s best to refer to this change in how you work as a transformation, because it’s not something you’re going to change overnight. To run your organization in a truly product based fashion requires changes in many different parts of the business. It requires changes in how your development teams work and how they interact with different parts of the organization.
Your organization should undertake a product transformation so that you can gain the advantages described above as a result of leaving the project based way of work behind. Your organization will be more effective because it’s working on the right things, and you’re not basing your plans off under informed assumptions. Rather, you’re positioning your organization to learn about the outcomes you’re trying to reach and the best solutions to achieve those outcomes.
