8. Progress over Process

The difference between Product and Project Management, without judgment.

For years, I got a bad rap. There was this idea projected onto me: that I hated Project Management, that I wanted them out of the building, off the project, and out of my life.

That couldn’t have been further from the truth. I cut my teeth in my early years of building apps as a project manager (in 2007–2010, we didn’t yet have the words or titles for Product Lead or Product Manager). I worked on waterfall projects, researched the different opportunities, managed decision‑making, note‑taking, mapped out all the details, and used Gantt charts and spreadsheets to track the work. I even did an extra‑credit project in graduate school where I wrote out three project plans for the movies Legally Blonde, The Sting, and Ocean’s 11.

I have a deep respect for Program and Project Management, and I hate the persistent myth that the two are at odds, that one is better, and that each wants the other out of the building. The truth is, they’re just very different ways of getting things done. Both can deliver from 0–1, manage complex, interdependent platforms, and deliver on time or just as easily be delayed, go the wrong direction, and solve the wrong problems. Stylistically, they are very different, and I would argue not juxtaposed opposites, but different tools applied to various kinds of work. I would love a world where the two styles of delivery lived in harmony, collaboration, and cooperation, but—ironically—that would require a process to manage. Ha!

So, maybe we should pause and ask ourselves why they are seen as opposing philosophies rather than options with criteria to match the team preference and the project’s scope?

As I’ve been thinking through this, I’ll be the first to admit, many times, Product comes into an organization with a lot of gusto, usually forced on departments that don’t have a good understanding of the differences between Project and Product.

I’ve often come into roles as the fixer, the person brought in to take over innovation when the last team didn’t deliver. In most of these scenarios, it wasn’t the previous team’s or the leaders’ fault. It was the setup—the introduction—that sank them from the start. Because when an executive team brings in Product to lead in a predominantly Project‑Management culture, they’re doing more than changing leadership; they’re inviting a new way of seeing the problem or envisioning the opportunity, and that shift comes with cultural consequences.

In two different roles, I was hired to lead “innovation teams” that were intentionally set apart from the rest of the organization. And the perks made it obvious:

The result? Innovation teams often looked like the golden child: set apart, indulged, and untouchable. Creating tension, jealousy, and frustration across the organization because many of these entrenched teams had been advocating for the same changes for years. And to be fair, innovation teams don’t always help themselves. Sometimes—and I have been guilty of this too—in our vision‑casting sessions, we can erase entire departments, because we are caught up in the future of what could be. Forgetting what is currently happening and who is in the room listening.

In one role, my counterpart in Customer Service told me bluntly: “Your predecessor said his Digital Team is going to make my team obsolete.” In another instance, another departmental head said to me, “So, I heard you were going to automate my entire department.”

And while I can appreciate the hyperbole—especially when casting vision—it’s fair to say that is not a good way to introduce yourself to your partners.

I understand. We forget that in a world of process, progress is scary, and the current standards and ways of doing things are comforting. Progress changes the norm, breaks patterns, and creates new possibilities. Whereas a process needs people to carry out tasks through the established gatekeepers. Progress sees automation as a way to remove the gates (and gatekeepers entirely). This, of course, would put any gatekeeper in a defensive position as you are threatening the power and control they have over their established fiefdom.

So, how do we manage the introduction better?

We can probably all agree, there must be a balance to how we communicate the vision and how we steward the changes it brings. Between the cost of cannibalizing old responsibilities and the opportunity to unlock new ones, we have to be sensitive to the real people these changes impact. Without empathy, a Product team can come across as precocious, naive, or even pompous. Especially when the broader team sees them getting more freedom, better tools, and room to experiment, while they are still hemmed in by bureaucracy and procedural debt.

Sloppy introductions, exclusive program rollouts, and hyperbolic visions of the future can create an environment where the product team is already ten steps behind in trust, yet asked to set the pace for everyone else. It is an unfair and almost impossible ask, because the very people needed to help the organization move forward have already been positioned in opposition to them.

So the story becomes this versus that, good versus bad, us versus them—an infinite regression of debate about the best way to build a product. We stop talking about the teams doing the work. Instead, the conversation shifts to power and control, disguised as process, debated in the name of progress.

Which misses the point entirely. These decisions shouldn’t be politicized or fueled by ego. Product should never enter the scene guns blazing, because it was never about Progress without Process; it has always been Progress over Process. In product‑led projects, we value moving forward over navigating a fixed process or appeasing a predetermined, gated bureaucracy.

If Product Management is about empowering the team to build.

Then, Project Management is about managing the people through the build process.

A subtle difference in definition, but a radically different orientation.

The Role of Process: A Necessary Container

Maybe it would help if I were pro‑Project Management for a few paragraphs, for you to believe my non‑biased, objective opinion on the two being different in purpose without judgment.

Process is good when we are creating a highly complex, repeatable process to reduce chaos and pre‑determine failure points.

If you are building a house, a rocket, or even a car that needs to be repeated by non‑experts post initial deployment, then it’s best that we really develop a process by which we identify the specifications, critical decisions, constraints, and components by which the thing will be built.

Research becomes increasingly important; competitive, historical, and current trends are the signals that drive the planning. Understanding team size, project scope, milestones, and timing of each piece of the complex puzzle must be plotted and agreed upon by the committee.

How the process is defined is in itself a process.

A house without a blueprint is not something I’d want to live in.
A car without an electrical spec is not something I’d want to drive.
A rocket without a documented full‑flow staged combustion fuel cycle is not something I’d want below my capsule sending me to space.

Again, process is important when you have many stakeholders, complexity, legacy systems, and replication as constraints. Many projects fit this criteria, and we need great project managers to help us get into the minutiae to create a solid project plan to work from.

Progress as a Core Value

When I contrast process with progress, I’m not dismissing the importance of process. I’m just demoting the urgency with which we implement it into the system.

A core tenet of the Agile Manifesto is: “Individuals and interactions over processes and tools.” That distinction—people over process—is where the real divergence between these two ways of building begins to show.

In projects where the outcome cannot be clearly defined and there is no obvious competitive template, or the work depends on messy, brittle legacy systems, process definition often becomes a distraction. You spend more time trying to design the scaffolding than solving the actual problem. You end up with an incomplete plan full of guesswork and time estimates that feels more like a document to appease a boardroom than actually help build the product.

In ambiguous projects, the emphasis should shift to the team’s ability to move through the unknown, toward something viable. We want to reach a working product quickly, learn from what breaks, and then iterate. Again and again. We treat failure as a faster and more faithful teacher than theoretical research could ever be. Maybe a fictional example to help us see the difference:

If you landed on an unknown planet and had to build a shelter outside your spacecraft, would you call in a project manager to draft a plan for a habitat made from unfamiliar materials? Or would you want a product manager to hack together a crude structure that gets you through the night—and then improve it, piece by piece, until you’ve built something more stable? Something livable, reliable, and stable enough to allow the project team to research a permanent solution.

I think this is where I see Product being the most advantageous way to work.

Where ambiguity is lessened by progress, and process can filter in behind to enable movement towards clarity while delivering some value (learned or earned), throughout each milestone.

Product Thinking: Outcome‑Oriented and Human‑Centered

So, as we separate the two styles and begin to focus on product delivery—where progress is prioritized over process—we can start to define strategies and orientations that help us measure the success of the project or product in every phase of the delivery.

Product is about desirability, feasibility, and viability, not just deadlines. When a product person is asked to define delivery of the final product, it’s a hard ask. We’d much rather define the delivery of the next feature or the next block of work and then present a roadmap to be prioritized. This can be frustrating in a project‑management–dependent worldview where every quarter is defined by spreadsheets, Gantt charts, milestones, and burn rate to be reported to the executive leadership and board.

It’s not to say Product isn’t outcome‑oriented; our outcomes are just defined differently. We aren’t concerned about whether we are on track with our pre‑determined plan, or hitting our revenue targets, or are under our project budget.

We are thinking more about how the product fits the current environment, market, or customer. We are asking, “Is what we delivered the right thing, or are we missing something?” We are learning from our failures as well as from the interactions, revenue, and engagement earned from our customers. Using this learned and earned data to re‑prioritize our roadmap to build the thing that is needed most! Our lens is more layered than just revenue or budget constraints.

We are asking the team to prioritize features to meet an expected objective. And these objectives can include:

People first, always—in prioritizing people over process, we are not just here to build for building’s sake, we are here to build to change behavior, to enrich people’s lives, and to create belonging. Product management is best suited when we are building to solve for people’s needs, wants, and desires. It’s not about building on time and budget, because there are plenty of projects that have done both of these things and completely missed the point (and the people)[^1].

Progress as a Posture

I think it’s best to be honest: I’m not as unbiased as I sometimes try to appear. I prefer working on products that prioritize progress over process. Not to demean the opposite, but to name my orientation clearly. I am NOT someone who fully aligns with those advocating for Process Management in the tradition of Frederick Winslow Taylor’s Scientific Management—the method designed to optimize workflows in manufacturing facilities for maximum efficiency[^2].

And while I can appreciate the intent behind creating an automated, repeatable cookie‑cutter output, I’ll always prefer the misshapen cookie with uneven edges but made with intention and love.

But we need to be honest about where we are. Artificial Intelligence—especially in its agentic and generative forms—is here to stay. And that puts those of us who have spent our careers bringing people to the center of development in a strange, even disorienting position.

If Taylorism is becoming the preferred influence in Silicon Valley, we’re in for a stretch of retraction, a few years where the color drains out of digital experiences, intention and love sacrificed to optimization and control. In its place, a world of black and white, where nuance is flattened, ambiguity is removed, and agentic bots execute tasks without context, curiosity, or even a need for why.

In that world, Project Management prevails—guiding people (or bots) through a rigid process. Building cookie‑cutter houses in cookie‑cutter neighborhoods for cookie‑cutter managers to lay their heads.

The pendulum may swing so far that risk mitigation becomes the most important metric. Change will no longer be proactively led. It will only be reactively applied when things break, and a change to something, rather than a patch, is the only solution.

For many industries, this will be the way, especially in those industries where predictability matters more than possibility.

I’m just more wired for possibility than predictability.

I prefer the messiness of reality, where nothing is black and white and everything is nuanced. Call me a post‑modernist, but I live in a reality where there are many truths and many ways to get to your preferred destination.

One of the most frequent criticisms of Product Management is that it’s messy, nonlinear, and inefficient. And yet we rarely apply that same scrutiny to process‑oriented systems, where scope changes, delays, and setbacks are abstracted away. No one takes it personally when a tsunami delays the shipping lanes, or when an executive changes direction after a year of work. The timeline is pushed, and the process holds the blame.

Yet, Product Management can’t run from the responsibility of failure; it craves it, because we look at failure as a learning multiplier—it makes us better, more responsive, and less rigid. To have a posture of progress is to see the nuance within a complex system and produce something living in response. We don’t build static objects but living systems—something that is meant to change, built to change, and wired to perform amidst the chaos of change.

Product elevates progress because the world doesn’t sit still. To be static is a death sentence in an ever‑changing world. In the reality I live and work in, change can’t wait for a project kickoff and a six‑week executive approval cycle; it must be a variable baked into the process itself.

Because in Product, we don’t reject the process.

We just refuse to be encumbered by it.

[^1]: Some examples of projects and products that completely missed the point:

- **Google Glass/Meta Rayban Glasses:** Solved a problem no one was asking to solve, in a way that made people feel surveilled and excluded.
- **Humane AI Pin:** It was beautifully principled on paper, but in practice, it felt like it was designed for a future that didn’t arrive—and maybe never will.
- **The Segway:** Assumed behavior would change to accommodate the product, rather than the other way around. Became a novelty, not a necessity.

[^2]: Taylorism — The theory of Scientific Management or Process Management to produce efficiency, workflow optimization, and standardization of process. https://en.wikipedia.org/wiki/Scientific_management