Software Teams Don't Have a Gate. I Spent Two Days With People Who Do.

I'd been a PDMA member for over a year, going to the Chicago chapter's monthly breakfasts with a wonderful group of people, before this year's summit announcement tipped me off that the Product Development and Management Association is mostly about physical products. I'd never heard of the keynote speaker, either. I do software.

So I went to the summit in Atlanta on October 8 and 9 – my first conference as a solopreneur – half-expecting that picking it had been a huge mistake. Most of the people I met did fit the description. They make things you can hold in your hand, like the guy I talked with who works on hose bibs and water fountains. I eventually found two other software people, both data analysts working with AI, and felt a little more at home after that.

But what I keep coming back to now isn't who was there. It's a tool the physical-product world takes for granted and most software teams have never built, and it turns out the keynote speaker I'd never heard of is the person who invented it.

The gate is where a project can actually stop

That speaker was Robert Cooper, who created the Stage-Gate process. If you've spent your career in software you may not have run into it either, so here's the quick version. A project moves through stages (scoping, a business case, development, testing, launch), and between each pair of stages sits a gate, where a group of senior people looks at what the team has learned and decides whether the project earns another round of money and people. Cooper often cites an estimate that 70% of new product developments never become a commercial success, and the gates are there to stop the losers early, while stopping is still cheap.

That decision is the part that breaks down. In a paper on what he calls pipeline gridlock, Cooper admits that even with the best of intentions, "the Kill option is rarely exercised," and that after the first approval most gates "amount to little more than a project review meeting, an update for management, or a milestone checkpoint." He even has a name for saying yes to a project without giving anyone the time to work on it. He calls it a "hollow Go decision," and it's how a company ends up with more projects than people and every one of them late.

The people who have gates still struggle to close them

That afternoon I sat in on a workshop about the next generation of product governance, run by Michelle Jones of Stage-Gate International and Penny Wise of 3M. They had everyone score their own organization from 1 to 10 on four drivers of innovation performance, live, and then put the room's numbers next to the top performers in their benchmarking data.

The room gave itself a 4.9 on innovation strategy, against 7.2 for the top performers. The stage-gate process itself – this crowd's home turf, you'd think – came in mostly at fours and fives, where the top performers sit around 8.5. One room grading itself isn't a study, but these are people who do this for a living, and when the facilitators asked why, the answers came fast. "They don't kill projects," someone said. Someone else described the quieter version, where nobody stops a project, they just wound it by taking its resources away. And plenty of gate reviews have turned into virtual meetings that leadership skips, with the votes emailed in ahead of time: "hey, I vote yes… I can't make it."

So even companies with formal processes, trained gatekeepers and decades of research behind them find it hard to stop something once it has momentum. Stopping is hard for everybody.

Most software teams never built the gate

Physical-product companies at least have a place where the stop is supposed to happen. Most of the software companies I've worked with don't.

Katie Trauth Taylor, the CEO of Narratize, told a story in her talk about a large consumer products manufacturer she'd worked with. They spent three years developing an eco-friendly diaper fluff, then tried to sell it to Procter & Gamble and were told no mom was ever going to pay a lot more for that. "Three years of technical development," as she put it, "working through incredibly hard technical problems without a market."

I caught her afterward and told her the talk was inspiring, and also that there isn't really an analog for it in software product management. In software, the diaper fluff doesn't take three years. It takes a quarter, or a few weeks with AI, and that speed is the exact argument I hear against slowing down to check: "but we can spin this up so cheap." You can't, actually. You just think it's cheap. Turns out she'd been making the same case from the other side – at a startup conference last year, her whole talk was that startups need to learn stage-gate.

Agile was supposed to be our gate

The obvious pushback is that software already has something better. That's what agile is for: short cycles, constant feedback, learning as you go. I've got a deep background in agile, and I don't think that's wrong. Every agile loop is supposed to deliver a valuable increment that's grounded in the user, which makes each one a small, frequent gate.

But most organizations don't have that discipline. They read agile as "we just do stuff quick," and the fail-fast, just-pivot advice that came out of Silicon Valley in the late 2000s and 2010s gave them permission to. That's how you burn all your capital. Iterating quickly on a direction nobody validated just gets you to the diaper fluff sooner.

Meanwhile, Cooper has spent recent years moving the other way, folding agile methods into stage-gate for manufacturers instead of dropping the gates. In a paper he published this August with Xinjin Zhao, they describe the next generation as gates "designed to maximize learning velocity through conditional Go decisions, rapid feedback loops, and dynamic, real-time governance." The physical-product people are busy borrowing our speed, and we could stand to borrow their willingness to stop.

A cheap yes leads to an expensive no

This matters to me because most of my work happens right where that gate should be. A big part of what I do is the discovery stage, doing deep research to figure out whether an idea is good or bad before anyone builds it, and it's usually a bad idea. Most ideas aren't grounded in a customer. Somebody had an idea and it looked shiny.

What those ideas got instead of a gate is a cheap yes. The AI said it was a great idea, the team said it was a great idea, and nobody had to put any evidence on the table to get there. The bill comes later, in the market, after you've spent the money and the opportunity cost and customers tell you no. A cheap yes leads to an expensive no, and a gate with teeth is where you can get a cheap no instead, early, before the money's gone. It's why I think the most valuable answer research can give you is no.

And I think software companies reach for building because it's the path of least resistance. Product and engineering always want to build something new, "we'll just build it" is the easy sell, and AI has lowered the resistance even further. Cheaper building doesn't make the decision about what to build any less important. It makes it more important, because now you can build the wrong thing faster than ever.

What a gate could look like in a software company

I don't think most software teams need a five-stage process and a steering committee. But after two days with people who've practiced this for decades, I think a few of their habits would cost a software company almost nothing.

The gate has to be a real decision. Somebody with the authority to commit people says yes or no, out loud, and owns it – and if the yes doesn't come with people actually freed up to do the work, it's a hollow Go and you've just added another project to everyone's plate.

The bar gets set before the work starts. My own rule is to gather enough to form a real hypothesis (not certainty), then run a short experiment with the signals defined in advance, so we know fairly quickly whether the hypothesis was right. When the results come in, you hold them up against the bar you set before you saw them, instead of finding reasons the weak result is secretly promising.

And stopping has to be a normal outcome. The phrases to listen for are "let's table this and revisit it next month" and, worse, "let's form a committee to look into it." That's how projects get wounded instead of stopped, and how a room ends up acknowledging every risk and moving on anyway.

None of it needs a binder. It needs one meeting where somebody's willing to say no and has the evidence to back it up.

The people in that room in Atlanta have had gates for decades and still struggle to say no at them. But most software teams I've worked with haven't even built a place to say it yet.