It’s hard to build a product oriented team in an organization that traditionally reaches for control. I’ve introduced the importance of getting it right in Building a product oriented team and hinted at it elsewhere. This article goes deeper, because if you don’t do it right, your team won’t survive long term.
Products rarely die from a shortage of ideas. They die from decisions — the wrong person making them, or nobody making them, until the runway runs out.
I watched it happen to a product I wanted to succeed. The founder was one of the smartest, most energetic people I’ve worked with: a hands-on CEO with a vision for social media built around positive messages, a real answer to the outrage machines we have instead. The visuals were beautiful. The mission was easy to believe in.
And every product decision was his.
Not on paper. On paper there was a team, and the team was good. But he was the loudest voice in every room, and the loudest voice also signed the checks. What excited him got built: message animations, 3D effects, short video clips — shipped early, well before the platform underneath could carry them. What bored him waited. Scalability, fault tolerance, PII handling, the right to be forgotten: those were details, and details could always wait one more increment. The roadmap fed the pitch narrative. The substance that would make the product reliable went to the back burner, every time.
We never built a proper steel thread. We never ran real discovery. No experiments, no end-user input; the question of what was valuable had a standing answer: whatever he got excited about.
In the end... the product shipped as a beta and it mostly worked. Bugs, of course; the backend never had the prioritized attention it deserved. But it worked, and it looked good. And it landed flat. Customers found the idea exciting but the product confusing; they never quite got it, because nobody had ever asked them what it needed to be. No outside investor ever wrote a check. The company ran on the founder’s own money, struggled through fits and starts, but eventually... petered out.
The easy lesson is founder ego, but it’s the wrong lesson. Plenty of opinionated founders ship great products (think of Steve Jobs). This product failed because every consequential decision — what was valuable, what got built next, how users would experience it, which technical risks mattered — had the same owner. No one person has the evidence to make every call, and nothing in the company’s structure should.
If you’re new, welcome to Customer Obsessed Engineering! I write about an article a week. Free subscribers can read roughly half of most articles, plus my free articles. Learn more.
Why a RACI doesn’t solve the problem
Try it with your own team. Pick the last decision that mattered: a feature cut, an architecture bet, a launch date. Ask who made it. Not who was in the meeting. Whose call was it?
Most organizations can’t answer cleanly. They point to a RACI, but a RACI maps activities: who does the work, who’s accountable for a deliverable. Authority over decisions is a different axis, and the RACI is silent on it. They point to a reporting line, but “it escalates to the VP” describes a delay, not an owner. Or they say “we decide together,” which sounds healthy but often means nobody actually decides. Consensus is a graveyard of contested decisions.
There are two ways to get this wrong, and they look like opposites. The first is diffusion: no named owner, so every hard call floats upward, stalls in a working group or dies in a thread. The second is concentration: one person owns everything. My founder ran the concentrated version, and it was fast: decisions arrived instantly, confidently and consistently underinformed. Both versions fail for the same reason. Authority isn’t sitting where the evidence is.
There’s a fix, and it’s almost embarrassingly simple. It fits on one page.
One decision, one owner
The clearest fix is a short table: one decision per row, exactly one owner, with each consulted party named. This is the playbook’s table, from 1.1 Team mobilization, built during mobilization — notably, put into play before anyone needs it.
Notice what the table refuses to allow. Critical decisions have one owner. No row has two — only commitment calls for consensus. No owner decides unconsulted; the parties are listed beside every decision, and consultation is an obligation, not a courtesy. And no row says “everything else.” If a decision matters enough to fight about, it matters enough to have a row.
This newsletter grows by word of mouth… I’d really, truly appreciate it if you could refer a friend. Your referrals make it worthwhile.
Two decision rights that carry the model
The customer owns what’s valuable. Nobody else can. Value belongs to the person who receives it, and a product organization that overrides (or never consults) its customers on the definition of value is creating detachment (a failure mode we’ll get to shortly). But notice how narrow the row is: it grants the customer the outcome, not the roadmap.
