The Product Model in Traditional IT
By Marty Cagan and Chris Jones
Taking The Product Model Beyond Product Organizations
Since the new book TRANSFORMED launched three months ago, we have been both thrilled and humbled to see the book spread, primarily through word of mouth, to places we would never have imagined.
We were very intentional in the book to try to be clear that the product model is not for everyone.
We think that’s where so many other models have gone wrong – over-promising and under-delivering. So we explained in the book that the product model is for companies that are building technology-based products and services. If you’re not working with a team of engineers to build something new, it’s not for you.
Furthermore, we emphasized that we did not invent the product model. We were simply sharing the principles that we found in the leading product organizations.
So the product model is from product organizations, and for product organizations.
However, since the book has been out, we have had a number of inquiries asking if we think the product model applies to other types of organizations that also build, but are not typical product organizations?
So far, we have had inquiries from three other types of organizations: the first is from Traditional IT departments, and that’s what we’ll discuss here. The second is from Governments, and the third is from Outsourcing Agencies, and we’ll discuss these situations in upcoming articles.
Traditional IT
It’s not really a surprise that several traditional IT organizations have reached out to us to help them transform to the product operating model. First, many of them are trying to shift their focus to outcomes, and second, many of them are doing much more building than ever before.
These organizations, typically led by someone with a CIO title, have usually been asked to expand their charter to provide solutions that go well beyond the scope of traditional IT. This can include customer-facing and customer-enabling solutions that power the revenue of the business, but also can include internal tools and systems to increase the productivity of the company’s employees.
For these organizations, transformation means not just moving to the product model, but also embracing the responsibilities of a product organization.
But moving to the product model does not mean that the former traditional IT responsibilities somehow disappear or are less important. Many of these systems are what keep the company running, the employees and suppliers paid, and the company in compliance with reporting and regulatory requirements.
But this begs the question, how much of the product model applies to traditional IT systems?
In this article, we discuss this topic, and also address some common confusions that can arise due to differences in nomenclature in traditional IT organizations versus product organizations, which again is where the product model originates from.
Build vs Buy
It’s important to clear up one of the common misconceptions, and that’s the difference between organizations that primarily build, versus those that primarily buy.
It is true that traditional IT may have a bias towards buying, because many companies have similar needs for operating their business, which is why there are so many vendors offering solutions aimed at traditional IT.
On the other hand, the product organization is a function of the particular types of products and services the company offers, which is why it’s more common to find a bias towards building in the product organization.
Can the product model be used in cases where the organization is not actually building a solution, such as where a company decides to purchase a third-party solution rather than build their own solutions?
While there are definitely elements of the product model that might be helpful, we intentionally do not emphasize this because the highest order objective of the product model is to deliver outcomes, and if the organization is not building the solution, they likely have far less ability to impact those outcomes.
To be clear, this situation is not limited to traditional IT.
For example, if the product organization decides to purchase a tool, such as for version control and configuration management, or issue tracking, or cloud-based platform services, they do not manage those tools like they manage the products they build. They administer those systems, and they might do various levels of customization and integration of those systems, but they are unlikely to consider this product work, in the same sense they have teams of engineers building their own products.
We highlight this example to point out that everywhere in the company faces the build/buy decision, and not just traditional IT.
Building in IT
That said, large companies are very complex, and it is not unusual for traditional IT departments to spend substantial resources on building their own solutions; often very comprehensive solutions built on top of various third-party offerings.
Sometimes the traditional IT organization hires its own engineers for this work; sometimes they hire specialty contractors; and sometimes they hire a custom solutions firm like Accenture to build these complex systems.
In these cases, the traditional IT department does have the ability to impact outcomes, and the product model can apply and provide real value (especially in the case where the company hires its own engineers).
Outcomes vs Output
There is a rapidly growing appreciation across the industry of the importance of focusing on outcomes, rather than just delivering output (features, projects and initiatives), and we applaud any organization that is striving to deliver outcomes.
However, traditional IT departments often face additional challenges in delivering on outcomes.
There are multiple reasons for this, not least because when there is a buy decision, there is limited control over whether the vendor product can deliver the necessary outcomes.
But more generally, traditional IT has historically been run as a cost center, yet the product model is designed for technology as a profit center.
These differences usually manifest in three important areas:
- Funding Models: project-based funding models are designed for predictability, but undermine outcomes.
- Staffing Models: project-based staffing models, and especially outsourced engineers, are flexible, but considerably more limited when it comes to delivering outcomes.
- Governance Models: every organization wants both predictability and outcomes; the key is what takes precedence. In traditional IT departments, established to “serve the business,” the governance models are designed for predictability of delivery. The processes and oversight are there to plan, monitor and enforce that predictability.
Some of the less obvious – but very significant – consequences of the above is that traditional IT departments often have cultural norms that can make it difficult to truly empower teams to move from “serving the business” to “collaborating with the business to serve customers.” We plan to write more in the future about these cultural issues.
Common Confusions
Because the product model originated in the product organization context, there are some nomenclature differences that often cause confusion, so it may be important to clarify these:
Outcomes vs Predictability
In product organizations, the company lives or dies based on their ability to consistently innovate on behalf of their customers. So you will often hear the principle expressed as “Innovation over Predictability.”
The implicit assumption is that innovation is the key to the outcomes they are seeking, which is often the case, but not always. More importantly, innovation is not typically the focus for traditional IT. Most traditional IT organizations strive to reliably and rapidly meet the needs of the business.
Note that predictability is also important to product organizations, but for them, shipping something on time that does not deliver the necessary outcome is rarely helpful.
Even very strong product model companies have dates that can be absolutely essential.
The irony is that product model companies have the techniques to deliver high-integrity commitments, which are dates that the company and partners can truly count on. Something that many traditional IT Agile people will try to tell you isn’t even possible.
Features, Projects and Initiatives vs Products
We talk a great deal about the limitations of “feature teams,” the risks of funding and staffing “project teams,” and the dangers of a Program Management Office (PMO) and the “initiatives” they govern.
But to be very clear: product teams in product organizations work on features, projects and initiatives every day.
There is absolutely nothing wrong with building features, projects and initiatives. It is simply a question of what is the best way to plan, discover and deliver this work such that they result in the desired outcomes? The product model is designed to optimize for outcomes.
We use the terms “features,” “projects,” and “initiatives” simply to refer to the size and complexity of the work involved. And it’s not a precise science. Small items are generally considered features. Bigger items that are covered primarily by a single product team are considered projects. And efforts that span many product teams are considered initiatives.1
Just to make things a little more confusing, keep in mind that in many cases, traditional IT organizations use the term project in the same way product organizations use the term initiative.
Project Managers
Similarly, except in the smallest of product organizations, product teams depend on project managers. Sometimes these people are called program managers, sometimes project managers (or technical project managers), and sometimes delivery managers.
In cases where companies don’t have project managers, or don’t have enough of them, the burden typically falls on the engineering managers and the product managers.2
The more dependencies and impediments in the work, the more project management is needed. This is why the most critical work for project managers are on the initiatives, as those efforts invariably have the most dependencies and moving pieces.
One other important point on project managers: in many companies, there can be real sensitivity to this role because there are different schools of thought for project managers. Those that come from the PMO school work best when predictability is the priority. Those that come from the empowerment school work best when outcomes are the priority.
Is The Product Model Right For You?
Consider the question this way: none of us want to set up a team to fail.
If a product team does not have the levers to truly impact value and outcomes, either because they are severely limited by a specific third-party product, or because they don’t have ongoing daily access to engineers to improve the product, or because they’ve been given output to build, and/or a date to deliver that takes precedence over the outcome, then the product model is not likely a fit.
- It may be worth mentioning that even in very strong product model companies, it’s very common that initiatives are both loved and hated. They are loved because they are often the items that generate the greatest business impact. They are hated because they require so much communication and coordination to manage all the interrelated pieces. ↩︎
- We do talk a lot about what happens when project management falls on the shoulders of the product manager; it usually results in little or no time left for the important work of product management, which is product discovery. Project management is still important; it just should not be the product manager doing it.
↩︎