Faith Based Product Development

There's a pattern I've run into often enough that I've given it a name: faith-based product development.

It's not religion, exactly, but it borrows the same mechanism. Senior leadership sets a timeline built on confidence rather than evidence — done in July, shipping in volume by September — while the reality on the ground looks nothing like that. There's a killer problem nobody's solved yet, and until it's solved, there's no product to sell. That gap between the plan and the facts would be funny if it weren't so expensive.

The symptoms are consistent enough that you can set your watch by them:

Engineering quietly falls off schedule. It's usually the first tell. Milestones start slipping, the delays get "factored in," and the backpedaling begins in earnest — well before anyone says the word "risk" out loud in a room with leadership in it.

Leadership stays comfortably above the details. This isn't a character flaw — it's mostly how management works at scale. Senior leaders get their picture of reality from staff meetings and program reviews, which means the picture is filtered through however comfortable each layer below them is with delivering bad news. Nobody's lying, exactly. Everyone's just managing up a little.

Product management ends up holding the gap. There's often a layer of management between you and the people who actually set the expectations, and no matter how engaged or sympathetic that layer is, they can't fully cover you. At some point you're the one standing there with the flag, and it's a lonelier position than it should be.

Layer sales on top of this and it gets worse fast: word gets out that something new is coming, sales training gets scheduled, demos get requested, and customers get promised things that are still sitting at proof-of-concept.

Faith-based product development runs on the belief that a senior leader's force of personality is enough to pull the rest of the org along by sheer will. It works right up until it doesn't. Technical hurdles are real. Some things need an actual breakthrough, and breakthroughs are notoriously bad at showing up on schedule.

So how do you push back on it?

Get a management layer that will actually go to bat. You need someone above you willing to carry the real story upward and lay out the consequences honestly, rather than smoothing it on the way up.

Build the confidence to skip a level when you need to. Product managers should have this in their toolkit generally, but it takes a real gut check — and yes, there's potential fallout. Do it anyway when the stakes call for it.

Get comfortable applying pressure to engineering, early. If a team is overcommitting, under-delivering, or stuck and not saying so, don't wait for it to become a crisis before you engage. It's rarely entirely their fault — but they own the delivery, and watching them flounder in silence helps no one.

And if you ever catch yourself thinking "that's not my job" — stop and reconsider. When faith-based development collapses, product management is the one left holding it. That's not unfair. It's the job.

Last licks: I call it faith-based because in top-heavy, disconnected organizations, the distance between what's actually happening and what leadership believes is happening can only be closed with a leap of faith. The job of product management is to close that gap with something better than faith — with the truth, delivered early enough to matter.

Where have you seen faith-based development show up on your team — and what actually broke the spell?