Over the past few years, there has been a significant shift in the way that technology investment is managed within companies. More specifically, there has been a move away from traditional project management towards “product”-style management. In this blog series, we will explore why companies are making this switch and the benefits that product management can bring to technology investment.
Before we begin, let’s provide some definitions. In speaking with customers attempting to make the projects-to-products transition, I'm often reminded of the early days of the expansion of project and portfolio management (PPM). In those days, we would often run into customers asking the key question: "What IS a project for our organization?" They say history repeats itself and it sure does: Lots of customers are now asking "What is a product for us?"
This question is not always asked for the same reason, either. Some practitioners ask the question out of confusion as they don't see their organizations delivering traditional "products." A senior leader at a major government agency expressed concern that "we don't really have products." We then proceeded to have the following conversation:
- ME: "Well, what do you fund?"
- CUSTOMER: "Oh, we fund capabilities."
- ME: "Do you also have capabilities managers that are responsible for the capability and its budget?"
- CUSTOMER: "Yes, we do."
- ME: "Sounds like that's a good start for the product discussion."
Whether or not you call them products will often be based on a series of factors:
- Internal or external audience
- Your particular industry
- Nature of the value being delivered
As long as whatever it is meets the criteria outlined in my previous post, it could be considered a product for the purposes of making this transition.
Here are just some of the terms that we have heard used in various customer organizations and that align with our definition of products:
- Capabilities
- Platforms
- Systems
- Applications
- Jobs (to be done)
- Experiences
- Value streams
- Work streams
- Business units (in cases in which a business unit focuses on a single product)
A key point is that this nomenclature often reflects the unique culture of your organization. As such, you should try to preserve it as best you can, while still applying the product management techniques we are discussing here. One key feature of Broadcom’s Clarity investment management platform is the ability to call your investments, or products, whatever people in your organization (or even in specific parts of the organization) want to call them. This reduces friction for getting people to adopt the centralized investment solution.
With all that said, it would probably be useful for us to agree on a common set of characteristics for a product. As a reminder, here are the PMBOK standard characteristics for a project:
- Set of related activities
- Definite beginning and end
- Creates a unique product, service, or result
- Receives explicit funding in the form of money and/or people
Based on our research among hundreds of customers, we have found products (or product-like substances) to have these characteristics:
- A sustained asset
- With an indeterminate lifespan, for example, an uncertain end date
- Delivers value that can be articulated in reasonable business terms, like outcomes
- Receives recurring explicit funding in the form of money and/or people
Items that meet these characteristics generally represent a product-type investment and would benefit from "product management" techniques. Our next blog will discuss how these different characteristics affect the way an organization approaches managing these types of investments.
Brian Nathanson
Brian Nathanson is a recovering certified Project Management Professional now serving as the Head of Product Management Clarity at Broadcom. He is the host of several popular Clarity-related customer webcasts (Office Hours, Release Previews, and the End-to-End Modern UX Demos) and has conducted many hours of both...
Other resources you might be interested in
Demystifying NODE
Use this step-by-step guide to master the installation of Network Observability Deployment Engine (NODE). Simplify network observability rollouts.
AAI v26.0 - Linux Standalone Upgrade
Learn how to upgrade a standalone AAI installation on Linux from version 24.4.x to 26.0. Find out about updated configuration and log structures.
Automic Automation v26 Standard Administration – Agents
This course covers two agent administration topics in Automic Automation version 26 (Standard): Centralized Agent Upgrade (CAU) and Agent authentication.
Automic Automation V26 Standard Administration - General Topics
This course provides Automic Automation v26 administrators with a direct, technical breakdown of core system configuration and maintenance tasks.
Automic Automation V26 Standard Administration - Advanced Processes
This course covers the Automation Engine (AE) server processes in Automic Automation version 26 (Standard).
Automic Automation V26 Standard Administration - Functional Security
This course covers the administration of functional security in Automic Automation version 26.
Rally Office Hours: October 22, 2026
Find out about the GA of multi-column sorting. Learn more about tracking physical resources, cycle time widgets, and work rules for sprint additions.
Automic Automation: Transition to SAP RISE with Confidence
Automic Automation safeguards Clean Core architecture, mitigates SAP RISE migration risks, and unifies enterprise scheduling from mainframe to cloud.
AutoSys Workload Automation: Transition to SAP RISE with Confidence
AutoSys safeguards Clean Core architecture, mitigates SAP RISE migration risks, and unifies enterprise workload scheduling from mainframe to cloud systems.