Program: You Keep Using that Word, I Don’t Think You Know What it Means

I’ve heard “program” used to mean everything from a team to a project plan to a portfolio to lines of code. At some point, someone has to stop and say: you keep using that word—I don’t think it means what you think it means.

A shared Taxonomy and Lexicon essential for focus and execution. Without one, organizations descend into semantic chaos. Few places create more confusion than the “P” words: Pfunction, Program, Project, Product, and their associated management functions.

Every company eventually trips over these. People use them interchangeably, often without realizing it. “Program” means one thing to engineering, another to marketing, and something else entirely to finance. The result is fuzzy ownership, blurred priorities, and circular conversations.

As I described in How We Scaled Alexa: One Problem, One Leader, scaling complex work requires single-threaded clarity. You can’t have one leader accountable for “the product” if half the org defines “product” as an app and the other half thinks it’s a platform. Leaders must explicitly define the boundaries: who owns what, what success means, and how each piece fits into the larger system.

This post defines the “P” words as I use them and explains how aligning on them creates clarity, focus, and scale.

Pfunction

A Pfunction (that’s a joke to make the “P” theme work) is what a person contributes to the company. Every employee provides one or more functions.

A CEO’s pfunctions might include executive leadership, fundraising, and investor relations. A software engineer’s pfunctions might include design, implementation, and testing. Pfunctions are not roles or titles; they describe what the role delivers.

Ok, I’ll stop using pfunction now and just use function. You get the point.

When an organization is small, people wear multiple functional hats. As it scales, clarity about each function’s purpose becomes the scaffolding for specialization. Confusion about functions is often the first crack in the foundation of focus.

Program

A Program is a long-term (measured in years) human effort to deliver customer value in a well-defined scenario area.

Programs are the durable units of investment; they are what the company will care about indefinitely. A great program has a clear vision, a defined customer set, and measurable outcomes that endure over time.

Programs are usually led by a Single-Threaded Leader (STL) who is fully accountable for the program’s success. The STL owns both strategy and execution, bringing together all pfunctions (engineering, design, marketing, operations) behind one clear goal. STLs of Programs are strong in all four of the CBTO perspectives.

Examples from my time at Control4: Smart home customers will always care about lighting, so we had a Lighting Program that built all of our connected lighting products. Jeff, a kick-ass, traditionally trained Product Manager, was the STL for Lighting (a vertical). People living in smart homes will always care about how scenarios that combine smart home verticals (Lighting, Whole Home Audio, Security, etc…) come together in a unified way, so we also had a horizontal Program for Home UI. Joel’s team built the Control4 mobile app and the experience on touch screens. He was a very technical engineering manager type. ¹

Programs produce Products over time. Each Product emerges through one or more Projects. Or, as I like to say, “Programs poop out Products, using Projects.”

Project

If Programs define the long-term why, Projects deliver the short-term what.

A Project is a short-term human effort to fix a problem or deliver something specific by a certain date. Projects are measured in days, weeks, months, or sometimes years. When a project is complete, the people involved move on to something else.

Projects are how organizations make progress in the short term. They are temporal, discrete, and measurable. A project without a defined end state isn’t a project; it’s a program pretending to be one.

Projects work best when their goals ladder up cleanly to a Program’s long-term outcomes.

A Project can also have an STL. The best ones do. The STL of a Project has full ownership of getting the thing done on time, on spec, and aligned with the broader program. Generally, STLs of Projects are super strong on Technical execution and appropriately strong in the other CBTO perspectives.

Product

A Product is a cohesive bundle of functionality that customers experience as a whole.

Products are what customers see, touch, and pay attention to (and often pay for). They can be physical, digital, or experiential. They can be literal boxed products or software as a service. Products deliver the promise of a Program.

Programs evolve through a series of Projects that create and improve Products. Over time, a strong Program poops out new Products: each one a milestone in the Program’s lifecycle of customer value.

When we scaled Alexa, teams had wildly different ideas of what “the product” was. Some thought it was the Echo device, others thought it was the Alexa voice service, and others still said it was the developer platform. Clarity only came when we defined “product” in customer-centric terms: the thing customers experience and value.

Products are the bridge between customer value and company execution. Misdefining them breaks that bridge.

For early-stage companies the Product and Program are usually one and the same. If the startup is successful with the first product, then the Program becomes distinct. The danger comes when growth blurs this line, turning a scrappy Product into a sprawling Program without reassigning ownership.

The Heart of the Confusion: Program vs. Product Management

Microsoft and Intuit² in the 1980s and 1990s, invented a discipline called Program Management.³ A Program Manager’s job was to be the single threaded leader for a product area: define what should be built, why, and ensure it got built the right way.

“A Program Manager is the advocate for end-users and customers” who bridges engineering and usability while driving execution.” — Steven Sinofsky

That model worked brilliantly. It fused customer obsession, technical depth, and operational rigor into one role. It forced alignment between strategy and execution.

But when Microsoft alumni scattered across the industry, the terminology mutated. Other companies borrowed the idea but changed the labels. The same role that Microsoft called Program Management eventually became known everywhere else as Product Management.⁴

The result: decades of linguistic confusion. Today, Product Managers rarely “manage products.” Program Managers rarely “manage programs.” And Project Managers often do a bit of both.

There should be a single function that defines what to build and ensures it gets built the right way. That function bridges strategy and execution. I wish the world still called that Program Management because that’s what it really is. But since most of the industry uses Product Management for this function, I use that term to stay consistent.

Function Taxonomy

Project Management

Project Management is the function responsible for ensuring a specific body of work is completed according to plan. Unlike Program Management and Product Management, there’s little confusion around the terminology: Project Managers manage Projects.

The skills required for Project Management are the fundamental blocking and tackling required to drive the mechanics of execution: schedules, dependencies, risks, and reporting. Somone skilled at Project Management is able to keep lists of details organized, up-to-date, and accurate. They master tools like Google Sheets, Jira, and Microsoft Project. They are good a herding cats.

Project Management is tactical by definition (recall from above, a Project is an effort literally bounded by time) and essential. The best project managers anticipate failure modes, surface tradeoffs early, and enforce accountability with discipline and humor.

Program Management (PgM)

Program Management is a supporting function that provides systems, tools, and mechanisms for consistency, coordination, and delivery at scale. Dedicated Program Management resources are not needed when the scale is small (startups, early-stage Programs). Dedicated PgMs are valuable when an organization has scaled to dozens of Programs with interdependencies and a need for cross-Program consistency.

At Amazon, there’s a function called Technical Program Management (TPM). These folks are very technical, really good at influencing others, and excellent at holding teams accountable to dates. They provide the most value when they manage complex arcs of dependencies across organizations.

At the scale most startups operate at, and when something new is hatched within a larger organization, dedicated Program Manager resources are a bad idea and a sign that the Program’s STL is not the right person for the role. Put another way, adding a PgM to an early-stage effort both robs the STL of ownership and just adds another chef to the kitchen.

Product Management (PM)

Product Management owns both the “what” and the “how.” The Product Manager leads the PROGRAM. He or she is the STL for the area of functionality that customers will care about over the long haul. I use PM as the acronym for Product Management.

World-class Product Managers (STLs of Programs) have little ego, are skilled at starting with the customer and working backwards, and consistently raise the bar for Ownership..

The best Product Managers are really good at Project Management (being the “a-hole with a clipboard”). If they’re not, they’re really good at hiring or delegating to someone who is. Likewise, they’re really good at Program Management (driving consistency and coordination).

One does not have to hold the title of Product Management to provide the function of Product Management. I’ve delivered amazing, magical, customer value via a Software Development Manager who acted as his own PM. A recent thread on X, by Nikia Bier, is a great example:

How to Reconcile Internal and Industry Terms

I obviously have strong opinions, strongly held on these terms. Maybe you agree with my definitions. Regardless, the real point I’m trying to make is:

Most people are confused and unclear on these terms and it’s very common within teams for there to be disconnects and misalignment. As a leader it’s your job to recognize this and be intentional about fixing it. Stop the semantic sword fights; define your ‘P’ words, arm your STLs, and watch execution accelerate.

Here’s how:

Define Internally First
Decide what each “P” term means inside your company. Write it down. Review it regularly. Teach it to every new hire.
Map to Industry Terms
Recognize where your definitions differ from common usage. Create a simple mapping document so you can explain your language to external partners and candidates.
Be Consistent Across Mechanisms
Use your taxonomy consistently in planning, budgeting, reviews, and reporting. If your systems use “project” differently, adapt them or clearly translate.
Keep the STL Principle Front and Center
Every Program and every Project should have one clearly defined leader who is responsible for the outcome. One problem; one leader.

When these definitions are explicit and mapped to reality, your organization gains coherence. People stop fighting over things that don’t matter and get to the crux of debate faster.

If your team struggles with blurred ownership or mixed terminology around programs, projects, and products, I’ve helped many leaders build taxonomies that scale. You can grab time with me during my office hours to talk.