Project != Product

The narrative of abandoning projects and organizing around products won. And he was right about almost everything.

The problem is that, during the move, many organizations also threw out a discipline that was not responsible for the disaster: the job of executing under uncertainty. Not the Gantt, the status report or the ceremonial tracking of the plan. The ability to turn an idea into something deliverable, manage real constraints, and forecast with evidence rather than optimism.

That job is still necessary. What is no longer so clear is who exercises it.

I had a conversation recently with a friend, Product Manager, about the problems she was facing at her job. After that, I’ve been mulling this over for several weeks and I’m still not sure I have it completely right. I write it more to organize it than to close it. If you think I’m wrong, write to me — I’m serious.

#.The scene

The scene is repeated so much that I can almost narrate it by heart. This is how it manifests itself, in the teams I have seen over the years. Let it be clear that this is what I have seen and not a census, nor the portrait of a particular team.

Product someone presents. And he presents well: he did real interviews, not filler surveys. It has a direction that connects with the business strategy. You know what problem you want to solve, for whom, and why now. All good. All solid.

Then someone asks:

—And when is it ready?

And the answer is a number.

—In March.

A number that does not come from a history, a distribution or comparable initiatives. A reasonable number, in the most dangerous sense of the word: it sounds plausible enough for no one to question it.

Everyone nods and writes it down. Not because there is evidence behind it, but because no one in the room knows how to construct a different answer. An answer that is not simply reasonable, but defensible.

And that’s fine. Seriously: it’s okay.

Not all people who work on product have to master probabilistic forecasting, queuing theory, dependency management or risk analysis. Likewise, mastering execution doesn’t automatically make you someone who can figure out what product is worth building.

They are different jobs.

Or, rather, they are different sets of questions.

#.The usual distinctionProduct connects user needs with business strategy. The discipline of execution is concerned with getting a decision into someone’s hands under real constraints.

Ready. I already said it.

And if the article ended here it would be useless, because that distinction has been known for years and you don’t need me to repeat it.

Additionally, the cut is not as clean as the definition suggests. “Product is the what and project is the how” looks lovely on a slide, but it doesn’t describe how software is built.

The scope is also discovered during execution. You don’t finish deciding what you’re going to do and then you start, cleanly, building it. Part of the what appears within the how: when you test a solution, encounter a technical limitation, see how a user responds, or discover that a supposed feature didn’t solve the problem.

Separating them as consecutive phases would, in itself, return to a waterfall logic.

They are not two phases.

Nor are they necessarily two people or two positions.

There are two sets of questions that remain alive throughout the work and require different skills:

• Are we solving a problem that matters?
• Are we building the right solution?
• What uncertainty should we reduce before investing more?
• In what order should the work be done?
• When is it likely to be available?
• What agencies can prevent it?
• What risk are we accepting?
• What should we cut to protect time, cost and quality?

This article is about the second set of questions.

Not because it is more important than the first, but because, in many organizations, it was left without a clear person responsible.

#.They were right

Look, I know what you’re thinking: “aha, the project lord defending his guild.” Let me get that idea out of your mind before I continue.

Since 2018 or so, the industry decided something: the project model is the problem. Mik Kersten published Project to Product ^fn-1 and said it without anesthesia: project management and cost centers are the completely wrong model if you want to innovate in software ^fn-2. Sriram Narayan wrote “Products Over Projects” on Martin Fowler’s site ^fn-3. Allan Kelly compressed it into four words that are difficult to improve: “products last, projects end” ^fn-4. And the #NoProjects movement dedicated itself to finishing off the wounded man ^fn-5.

Did you know? They were right. And I don’t say this out of rhetorical courtesy.

Narayan put it in a single sentence:

“[T]he way project funding works, funds are made available to sustain a team for a duration of time much shorter than the lifespan of the underlying problem being addressed.” Funds are made available to sustain a team for a time much shorter than the life of the problem that team is solving. There it is. That is the structural imbalance, and it is lethal. You finance eighteen months for a problem that will exist for ten years. The team delivers and disbands. And as Narayan concludes, there is no documentation, transfer or transfer of knowledge that compensates for the complete dispersion of the team that built the thing.

Leybourn and Hastie dedicated an entire book to the subject ^fn-6, and the InfoQ review sums it up this way: the book is about why “running a temporary endeavor is the wrong approach to building sustainable products”. That “temporary endeavour” is not coincidental — it is, word for word, how the PMBOK defines a project: “a temporary endeavor undertaken to create a unique product, service, or result”.

So yes. The project funding model — temporary budget, fixed scope in advance, team that is assembled and disassembled — is toxic for software that is never finished. Granted. No buts, no defensive nuances, no “yes, but.”

The problem is another. The problem is what else we throw away when moving.

#.What fell from the moving truck

Here is my complete thesis, and it fits in one line: we killed the financing model and, in the process, unintentionally, we killed the execution discipline. Which is something else.

One is how the money gets to the team. The other is the craft of getting something from an idea into someone’s hands, within real constraints, with evidence rather than optimism. Throwing away the first did not require throwing away the second. But they came in the same box, and no one noticed.

The strange thing is that no one picked her up from the floor.

Look, I checked this while writing: the Scrum Guide does not contain the word “manager” even once ^fn-7. Neither in the 2020 version, nor in the 2017 version. Zero times, in about four thousand words. And in the 2020 version, the word “project” appears exactly once, in this sentence:

“Each Sprint may be considered a short project.”

In other words, the project does not disappear: it shrinks to fit within a Sprint. And be careful, Scrum is not negligent with execution within that horizon — it has a long-term Product Goal, distributes planning and quality responsibilities among the three roles, and Sprint Planning includes a forecast based on past performance. What is left out of its minimum definition is what does not fit in two weeks or in a single team: the dependencies between teams, the budget, the long horizons. And I’m not saying that Scrum eliminated the project manager role. I was going to say it — it’s what everyone repeats — and it’s false. Scrum never had it. Absence is not an erasure, it is a silence: it was never there to eliminate it.

I don’t want to force reading either. When the guide says “Within a Scrum Team, there are no sub-teams or hierarchies”, it is describing what happens within the team; It does not prohibit the existence of an engineering manager or a director around. Scrum simply has no say in how the rest of the company is organized. The problem is not that Scrum says the wrong thing. The thing is that many people read that silence as an answer.

And what happens when a responsibility does not have an explicit owner? It doesn’t disappear. It spreads. It falls on whoever is standing closest — often the product owner, who already has a full-time job.

I want to be precise here, because this easily reads like an attack and it is not. The problem is not that product managers and product owners are incapable of executing. The problem is that many organizations handed them the complete execution without asking themselves if they had been trained for it.

Knowing how to discover problems, understand users, organize opportunities, and connect an initiative to strategy does not automatically teach you how to forecast dates, manage dependencies, model risks, control work in progress, or recognize when pressure on time and scope is degrading quality.

But, in practice, both things end up in the same hands.

The product manager or product owner receives pressure from stakeholders, translates that pressure into a date, and then manages the work almost exclusively from the perspective he or she knows: priority, scope, and value. When the date becomes set in stone and the scope continues to grow, you rarely have the authority to increase the cost. What remains is to pressure the team, reduce controls, postpone technical work or accept commitments that no one explicitly named.

Not because I want to destroy quality. Because no one made quality a protected constraint and no one took responsibility for explaining what should move when constraints conflicted.

That’s the gap. Not the absence of a position called project manager, but the assumption that knowing what to build also implies knowing how to conduct its execution under pressure.

This is how it manifests itself, in the teams I have seen. Let it be clear that this is what I have seen and not a census.

The right column is the problem I want to discuss.

SAFe, to be fair, did notice the gap and plugged it with the Release Train Engineer. And here I have to be careful, because I wrote the first version of this paragraph wrong: SAFe yes assigns the RTE risk management, elimination of impediments and facilitation of train execution ^fn-8. The responsibilities are there, written. What catches my attention is the headline with which it is presented — “a servant leader and ART coach” — and the fact that we needed to invent a new role, with coaching vocabulary, to say again what a project plan said without ceremony. The show is back. The name had to be disguised.

Not even the PMI has it figured out. PMBOK 7, in 2021, removed the 49 processes and 10 knowledge areas from the center of the guide and replaced them with 12 principles and 8 performance domains, with a section literally titled “A System for Value Delivery” ^fn-9. The PMI approaching the language of value and results. And in November 2025, PMBOK 8 comes out, which retains the principles and value orientation but returns about 40 processes, now presented as an adaptable guide instead of a recipe.

I don’t read it as PMI being lost — principles and processes are not competing categories. I read it as the institution that certified me has been publicly searching for the balance between the two things for five years, and still has not found it. If it’s hard for them, I completely understand that it’s hard for your team too.

#.They taught me wrong

I trained in this. Master’s degree, certifications, the complete package. And that is why I can tell you with first-hand authority that part of what I was taught was wrong, and that project people carry that error with admirable stubbornness. I was taught that execution lives in four dimensions: time, scope, cost and quality. And they taught me the triangle: move one, the others adjust. Choose two. The thing sounds like a physical law and has the elegance of false things.

Let’s start with the one that matters most to me, because it is the one we already discussed in Piano piano si va lontano: quality should not be one of the variables you negotiate.

The evidence is old and it is clear. In Accelerate, Forsgren, Humble and Kim say it with a word that betrays its own surprise — “astonishingly” — and with data from thousands of teams behind it: there is no trade-off between improving performance and achieving more stability and quality ^fn-10. Those who go fast are stable, and they are stable because they build quality within, not despite it. That finding is cited frozen in time too often: it’s data from 2017, and the 2024 DORA report found that the medium cluster has a better failure rate than the high ^fn-11. The correlation remains within each group but cracks between groups. The body of knowledge is alive. What has not moved is the core: quality should not function as a discretionary lever that you adjust to meet the deadline.

The DSDM handbook ^fn-12 changed the argument for me. DSDM is the agile framework that inverted the triangle: it fixes time, cost and quality at the end of the fundamentals phase, and absorbs the unexpected by moving the only thing that remains — the features.

But that’s not what’s interesting. The interesting thing is what it says about the traditional model. I assumed that the classic model “fixes quality.” No. DSDM says something more uncomfortable and more real:

“Under such pressure, quality often becomes a variable, as a result of introducing compromises which have not been thought through, by reducing essential quality control steps or by cutting back on testing.”

Quality is not fixed in the classic model: it is unprotected. When you squeeze time and cost with scope nailed down, quality is the only thing left unguarded. Nobody decides to sacrifice her. She is simply the one who gives in, because she is the only one who can give in silently.

I say “usually” on purpose. There are projects where the minimum scope is defined by a regulator, where a functionality cannot be split in two, or where delivering half does not deliver half the value but none at all. DSDM proposes a coherent strategy, not a natural law.

And the time and cost? That’s where the real craft begins. And it doesn’t look anything like a Gantt.

#.Almost all our evidence is garbage

If you ask anyone in projects for evidence that projects fail, they will cite Standish’s CHAOS Report. It is probably the most recognizable statistic in the discipline: 31% of projects canceled, 53% with problems, 16% successful ^fn-13.

That data does not hold up to the weight we put on it. And taking it apart is the best way I know to explain why execution is a craft and not an ornament.

Start with the definition. For Standish, “success” means delivered on time, on budget, and with all the features initially specified. Read it again. That does not measure value delivered. Measures adherence to an estimate made when you least knew. A project that discovered halfway through that half the scope was useless, cut it, and delivered something people love is a failure according to Standish. A project that promptly delivered a hundred features that no one uses is a success.

In 2010, Eveleens and Verhoef published a paper in IEEE Software with a title that already says a lot: “The Rise and Fall of the Chaos Report Figures” ^fn-14. They took Standish’s definitions and applied them to 5,457 actual forecasts of 1,211 actual projects. They found this:

A real company — Landmark Graphics, which systematically underestimates its forecasts — achieves 5.8% success according to Standish. The authors then constructed a fictitious organization with the same exact deviations but with the sign reversed: overestimating instead of underestimating. That organization obtains 94.2% success.

The same quality of estimation. Identical. Six percent versus ninety-four percent, and the only thing that changed was the bias sign.The Standish metric does not measure success. Measure which direction you are going wrong. And like any metric that becomes an objective, it rots: the authors document an organization that adopted Standish’s definitions and whose managers began inflating budgets to ensure “success.” In his words, the metric “perverts rather than improves estimation accuracy”. It’s Goodhart’s law again, the same one I discussed in The Death of the LOC, and it appears where you least look for it.

And where did the 1994 sample come from? Jørgensen and Moløkken-Østvold went looking for it and found that Standish describes his own method like this

“We then called and mailed a number of confidential surveys to a random sample of top IT executives, asking them to share failure stories.”

They asked for stories of failure. And with that they calculated a failure rate. When the researchers asked Standish to explain his methodology, Jørgensen and Moløkken-Østvold summarized the response they received: Giving that information would be like giving away their business for free.

And the finishing touch, which is in the IEEE Software paper. When Eveleens and Verhoef confronted Standish with their findings, chairman Jim Johnson responded:

“All data and information in the Chaos reports and all Standish reports should be considered Standish opinion and the reader bears all risk in the use of this opinion.”

Opinion. The authors close the paper like this: “We fully support this disclaimer, which to our knowledge was never stated in the Chaos reports.” That disclaimer never appeared in the reports that Standish sells.

To be fair with rigor: no one has proven that the figures are numerically false. No one can — the raw data was never published, the reports are not peer-reviewed. The argument is not “they lie.” The argument is that they are not auditable and do not mean what you think they mean. It’s an important distinction and I’m not going to blur it.

#.What can last

Now, just because popular evidence is bad doesn’t mean there is no evidence. There is, and it is good, and almost no one cites it.

Flyvbjerg and Budzier, in Harvard Business Review, studied 1,471 IT projects ^fn-16. The average cost overrun was 27% — nothing dramatic. But that average hides the real story:

“Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%.” One in six. And be careful, because this fact is constantly misquoted: 200% are from the black swan subset, not the average. The average is 27%. What kills is not that IT projects go a little over budget. It is that an abnormal proportion of them go completely off the rails. And while everyone is looking at the average, no one is looking there.

Something that almost no one mentions when citing this study: the sample is 92% public agencies and 83% projects in the United States. The authors say they found little difference from the rest, but that bias exists and you should know it. And the article never numerically defines what a “black swan” is, so the “one in six” is not auditable from there. For the serious argument you have to go to the 2022 academic paper, with 5,392 projects ^fn-17. It’s a good idea to get rid of the jargon, because this is the part that really matters.

Think about people’s height. It is concentrated in a narrow range: there are taller people and shorter people, but no one is four meters tall, and no matter how many people you measure, the tallest person in the world will never double the average. The extremes exist, but they are tied. In a world like this, the average tells you almost everything you need to know.

Now think about wealth. The average, alone, says very little, because in any group there can be someone with ten thousand times more than the rest, and that single person moves the number. The extremes are not tied: they rule.

Software cost overruns resemble wealth, not stature. That’s what they demonstrated with 5,392 projects. And the authors say it without accusing anyone: managers “may be unwittingly exposing their organizations to extreme risk by severely underestimating the probability of large cost overruns.” Without realizing it. Not by negligence, but by planning as if they were measuring heights.

And this is not something you learn by doing discovery. That average, alone, is a dangerously incomplete statistic. That extreme cost overruns are not the improbable anomaly that conventional models suggest, but rather a fat part of the distribution. That risk lives in extremes, and that we have to go look for it there. And what do you do with that? Flyvbjerg proposed twenty years ago an answer that is still the best available: reference class forecasting ^fn-18, which he defines as “a method for systematically taking an outside view on planned actions”. In Christian: stop wondering how long this project is going to take, with its quirks and its team and its unique charm. Ask yourself how long similar projects took. The view from the outside, not the view from the inside — a distinction that, contrary to what almost everyone believes, does not come from Thinking, Fast and Slow but from a 1993 paper by Kahneman and Lovallo ^fn-19.

Your intuition about your own project, alone, is a weak foundation. A comparable reference class lets you calibrate it against something that really happened. It doesn’t replace it — it lands it. That’s the job.

#.Our cone is also a lie

And while we’re tearing things down, let me tear down one of my own house.

Everyone who estimates software knows the cone of uncertainty: at the beginning of a project your estimates are in a range of 4x up or down, and the cone closes as you learn. It is attributed to Barry Boehm and is always presented as an empirically derived curve.

I went to look for the source. The 4x range is real and it’s there ^fn-20. But it has a footnote, number 4, written by Boehm, which says:

“These ranges have been determined subjectively, and are intended to represent 80 percent confidence limits.”

Subjectively. He says it. The canonical multipliers of that figure did not come from the data: they came from the expert judgment of a very intelligent man. And they are 80% confidence limits, not absolute limits. There has been subsequent research on how uncertainty evolves in a project — I’m not saying the idea is false. I’m saying that we tend to present those numbers with much more empirical authority than the original source had. Boehm didn’t even call it a “cone” — his figure is called “Software cost estimation accuracy versus phase.” The pretty name was given to him by Steve McConnell in 1997, thirteen years after that paper.

My guild has no moral authority here. We also cite folklore and call it evidence.

#.The bridge that no one crosses

Up to this point I have disassembled quite a bit. It’s time to build.

If I were forced to summarize the execution document in a single concept — one — it would be this: the cost of delay. Cost of delay. And it is the best bridge that exists between product and project, because it is simultaneously a question of both.

Donald Reinertsen built the entire framework in The Principles of Product Development Flow ^fn-21, and his E3 principle pulls no punches:

“If you only quantify one thing, quantify the cost of delay.” Because? Because it is one of the few economic denominators that let you compare decisions that are otherwise incomparable. Is it worth splitting this batch into three? Is it worth having idle capacity? Which of these two things comes first? Without the cost of delay, all those questions are answered with hierarchy and voice volume. With the cost of delay, they are answered with arithmetic.

The problem is that almost no one has it. Reinertsen explains that prioritizing like this is only possible when you know the cost of the delay, and then he says, in passing, that this is “information that 85 percent of developers do not have” ^fn-21. He wrote it in 2009 and it continues to describe the room you were in yesterday.

Eighty-five percent. And I quote it carefully, because this information is circulated distorted: Reinertsen says “developers”, not “companies”. Nor is it a study with a sample and method — it is the professional statement of a man who by then had been writing on the subject for twenty-six years. It’s worth what it’s worth.

There is another piece of information about him, in the same chapter. In companies that do not calculate the cost of delay, different people on the same project give answers that vary 50 to 1. Fifty to one. On the same project, in the same company, the same week.

The beauty of the concept is that the question “how much does each week of delay cost us?” it is not a product or a project. You need the business knowledge of one and the flow knowledge of the other. It is literally the conversation that both trades should be having and are not.

And about time, the modern answer already exists and is not a Gantt. It is probabilistic. Daniel Vacanti sums it up in a line that should be taped to the wall of every planning room: a forecast without a probability taped next to it is deterministic ^fn-22. And the future is not. When someone asks “when is it ready?”, the professional answer is not “March 15.” It is “90% probability of finishing before March 22, based on our history of the last twelve weeks”. That number comes from running thousands of scenarios against your own delivery history — a Monte Carlo simulation. The simulation is simple and with a fairly clean history you can set it up in an afternoon with what is already in Jira. Getting the history clean, that’s another conversation. With a warning that Vacanti highlights and that people ignore: all this depends on your history looking like your future. If your flow constantly changes — the team changed, what counts as “done” changed, there’s work that’s been open for months — then forecast confidence plummets, whether probability sticks or not. The assumptions of Little’s law, which relate how much work you have open to the rate at which it comes out, serve precisely to check whether your process is predictable enough to make it worth forecasting. Monte Carlo does not rescue chaos. First stability, then forecast.

#.The mirror, on this side

I have spent a thousand words pointing out a gap on the product side. Touch on symmetry, because without it this is a guild fight and not an argument.

My training did not prepare me for product. And I didn’t realize it for years.

Our sin has a characteristic form: turning discovery into a schedule. Put user interviews in the Gantt, with an end date, as if understanding someone were a dependent task. Asking “when do we finish discovering?” hoping that afterwards there will be no more uncertainty — which is where the question breaks down. A spike can last a week and an experiment can have a stopping criterion; What does not exist is the point where you stop learning and start building.

When you train in execution, you develop a reflex: turn everything into a plan. And there is a kind of problem — precisely the one that matters to product — where that reflex is the wrong one. Marty Cagan lists four risks that must be attacked before building: value, usability, feasibility and business viability ^fn-23. Guess which of the four is mine. One. One of four. And yet we have entered those conversations convinced that a well-made plan solves them all.

Cagan wrote it uncharitably, and rightly so: IT-minded companies continue to fund projects — output — instead of product teams measured by business results — outcomes ^fn-24.

An impeccable plan that delivers the wrong thing on time is still a failure. And that’s something that my guild, the four-dimensional one, took too long to accept — because our metrics don’t know how to distinguish between delivering well and delivering what’s right. Standish, again, at the bottom of it all. So no: this is not about product people learning project management. It is that typical product competencies do not guarantee mastery of forecasting, flow, dependencies, or risk — and that traditional project training does not guarantee mastery of discovery, strategy, or value validation. It’s about stopping assuming that someone, because of their title, already has both.

#.The orphan discipline

So what do we do?

I’m not going to tell you “hire a PMP.” It would be selling my guild, and it wouldn’t work — the title doesn’t matter. There is a set of specific responsibilities that have no owner, and everyone assumes that someone else carries them.

These are. Read them and ask yourself who does them on your team:

• Forecast with evidence, not with optimism. View from the outside. Similar projects. Distributions, not points. If your answer to “when?” It does not say its level of confidence or its assumptions, it is not an incomplete forecast: it is a promise waiting for someone to collect it.
• Know the cost of the delay. Even if it is approximate. Even if it is a range. If no one on the team can tell you what a week late costs, they are prioritizing by voice volume.
• Manage how much work is open at a time, and what size. When the work started exceeds the actual capacity of the team, waits grow and everything takes longer — just like a supermarket line with too many people inside. And the larger the package you deliver at once, the later you find out it was bad. It is not an aesthetic preference: it is the behavior that queuing theory has studied for a century.
• See dependencies before they explode. No one looks at this until one team has been stuck waiting for another for three weeks.
• Keep a risk register that someone reads. Boring. Dated. Works.
• Protect quality explicitly, because as DSDM inadvertently taught us, what is not protected is what gives way silently.

Who does that? It can be a delivery lead. It could be the engineering manager. It could be the tech lead. A product manager or a product owner can do it, of course — but not by virtue of the title, nor because product owns all the decisions. You can do this if you also master, or are accompanied by someone who masters, forecasting, flow, dependencies, risk, and explicit quality protection.

The title doesn’t matter to me. The error is not that the product participates in the execution; The mistake is handing over all the execution to the product and pretending that the skills are included. And what I don’t care about either is the answer “that’s what the team does”, which in practice means nobody, dressed up in nicer clothes. Because Jira doesn’t. Jira is a place to put things.

#.Closing

Kersten, Kelly, Narayan and the others won the argument. And they won it well: the project financing model deserved to die and the world is better with durable product teams.

But when we dismantled the house, we threw away something that wasn’t broken. The discipline of execution — the real one, the one of distributions and queues and the cost of delay, not that of the Gantt and the status report — outlived its own financing model and no one came to rescue it. She stayed there, lying in the rubble, while the rest of us argued about whether story points should be Fibonacci.

And that’s why, when someone from a product or a stakeholder answers “in March” with all the confidence in the world, it doesn’t bother me. I’m worried about something else: that no one knows that this question has a professional and slightly more correct answer. That, in fact, there is a job behind it. That there are a hundred years of operations research, queuing theory and development economics waiting for someone to use them.

Project != Product. Not because one is worth more. Because they are two jobs, and neither of them is the one you think you already master.

That someone from a product does not know how to forecast with evidence is fine. It’s not his job, and no one told him it was. What is not right is that we have put together so many teams where that job belongs to no one, and we continue to be surprised when the date arrives and it is not there. Or when the date is imposed on us by a Product Manager and a Designer based on a stew of faith and prayers.