The Most Important Person Who Can Kill Your Project and Burn All Your Money – The Product Owner

In my career, I worked for six startups – always as lead developer, lead engineer, or CTO. I also worked for two product companies before starting my own agency, which later merged into Q.

Between my own company and Q, I’ve worked on, managed, overseen, or deep-dived into dozens of projects. This article shares what I’ve identified as the single biggest project killer: a bad Product Owner.

Why PO is on the Client Side (and Why That Matters)

When you’re an agency like Q, you work with a Product Owner. Either the PO is on the client side, or the PO is on your side.

My experience tells me it’s better if the PO is on the client side, and here’s why: skin in the game.

When the PO is internal to the client, they own the consequences. They face their stakeholders daily. They feel the burn when money is wasted. They can’t hide behind “the agency didn’t deliver.” This creates the right incentives – they’re forced to be decisive, organized, and accountable because their ass is on the line.

When we provide the PO, we create a buffer that lets clients avoid hard decisions. They can delay, waver, change their minds, and blame us when things go sideways. We’ve tried both models. The client-side PO model, when done right, produces better outcomes.

What Makes the PO Role So Difficult

The PO role is genuinely hard. It requires a rare combination of skills:

Strong communication – not just talking, but translating between business stakeholders who speak in revenue and outcomes, and technical teams who think in systems and constraints.

Firmness – the ability to say NO and make it stick. To stakeholders who want everything. To developers who want to rebuild the entire stack “the right way.”

Organization – maintaining clarity across hundreds of moving pieces without drowning in process.

Drive – pushing when the team is stuck, rewarding when they deliver, and knowing the difference.

I’ve been in this role many times. More often than not, I took it rather than had it given to me, because I saw what happens when there’s a vacuum.

What a Good PO Actually Does

A Product Owner is the mini-CEO of the product. Here’s what that means in practice:

1. Align internal stakeholders – This can be brutally complicated and stressful, especially when stakeholders are on different sides, related through family, or tangled in politics. Someone has to cut through that mess and get everyone moving in the same direction.

2. Own the product – Say when something will be developed, why, and in what order. Then defend those priorities to both stakeholders and the team. This isn’t consensus-building. It’s decision-making.

3. Pass on vision in digestible chunks – Break down the big picture into pieces small enough to execute, but not so small the team loses context and drowns in micro-questions. This balance is harder than it sounds.

4. Make hard decisions – Cut when a cut is needed. Push when momentum is flagging. Don’t waffle.

5. Know the product state at 2 AM – Where is the product right now? What’s in the backlog? What’s the holdup? A good PO doesn’t need to check Jira to answer these questions.

6. Absorb the heat – Blush before stakeholders when something isn’t done. Blush before the tech team when something stupid is said by the business side. Take the hits that come from both directions.

7. Own outcomes – When shit goes wrong, it’s on them. Not the developers, not the stakeholders. The PO.

The Pattern We Keep Seeing

The biggest issues, biggest challenges, and most expensive disasters we’ve had – both financially and relationally – come from clients who either didn’t choose the right person for the PO role, or chose someone for the wrong reasons (politics, family, availability, cheapness).

Red Flags: How to Recognize a Bad Product Owner

Not strong enough to say NO – They fold under pressure from stakeholders. Everything becomes a priority, which means nothing is.

Organizationally chaotic – They create 1,500 tasks with 400 circular references. The backlog is a dumping ground, not a roadmap.

Domain ignorance – They don’t understand the business domain deeply enough to make trade-offs. Every decision requires a committee.

Tech illiterate – They don’t need to code, but they need to understand high-level technical constraints. When they don’t, they promise impossible things and blame developers for “not trying hard enough.”

Can’t align stakeholders – Instead of aligning them internally, they bring us in to mediate. This never works. We’re outsiders. We don’t have the authority or context to settle internal politics.

Allows direct stakeholder-to-dev communication – They let stakeholders bypass them and go straight to developers. This creates chaos. Priorities shift hourly. The team gets contradictory instructions.

No forward visibility – They don’t have a backlog, roadmap, or strategy prepared at least three months out. Everything is reactive, firefighting, last-minute.

FAANG ego – Especially dangerous with POs who worked at big tech companies. They assume what worked at Google with unlimited resources and 18-month release cycles will work in a startup with six months of runway. It won’t.

Context mismatch – A PO who ran a mature, long-lived product for years gets thrown into a startup. They bring mature-product thinking to a place that needs scrappy MVP mentality. The result: over-engineering, paralysis by analysis, burning runway on polish nobody needs yet.

What a Good PO Looks Like

Clear roadmap upfront – They show up with guidelines, priorities, and a vision that makes sense.

Gives the big picture – They spend time with the team explaining WHY, not just WHAT. This isn’t wasted time. It’s how you get a team that can make smart micro-decisions without constant hand-holding.

Works on motivation – They understand what the team needs to stay engaged and productive. They notice when morale is dropping and do something about it.

Understands needs – Not just business needs, but what the team wants and needs to do their best work.

Business AND financial literacy – They understand the domain, but they also understand burn rate, CAC, LTV, and why we can’t spend six months building the perfect solution.

Owns decisions and consequences – When something goes wrong because of a call they made, they own it. No finger-pointing.

The Inevitable Blame: “It’s Always the Dev Team’s Fault”

When projects go sideways with a bad PO, here’s what we hear:

• “They didn’t deliver”
• “The quality was subpar”
• “They don’t understand the business”
• “They’re overengineering”
• “They’re making it too complicated”
• “Why do I have to explain things multiple times?”

That last one is particularly irritating.

Why You Need to Explain Things Multiple Times (And Why That’s Normal)

After explaining how knowledge and neurons actually work, we usually get asked the same question again: “But why do we need to explain it multiple times?”

So let me explain clearly:

This primarily refers to existing projects with complexity.

It is necessary to explain things multiple times. Sometimes over and over in a single session when a matter is complex. Usually it’s today, then again in a month, because the level of knowledge of the person on the receiving end changes. You need to tie things together as their understanding evolves.

Knowledge isn’t static. It builds. Context from three months ago connects with new information today, and suddenly something clicks that didn’t before.

Here’s what stakeholders usually don’t realize: they aren’t fully aware of how their own systems work under the hood. They know what they need it to do. They don’t know how it actually does it, what the constraints are, or why changing X breaks Y.

When we explain the same thing twice, we’re not repeating ourselves. We’re building on previous understanding with new context.

Two Projects That Illustrate Everything Wrong

Project 1: The Family Business Death Spiral

Small, family-owned business. Three main stakeholders: husband, wife, and a relative on the IT side.

They made a terrible mistake: they brought in a junior PO because he was related to the family.

She couldn’t align the stakeholders internally. The husband wanted financial controls. The wife wanted shiny features. The IT relative kept saying what was and wasn’t possible, but nobody listened.

This torment lasted over two years.

At some point, we were running in circles. The client was unhappy. Our team was frustrated and unmotivated.

Hundreds of questions were raised. Very few got answered.

The core problem: the stakeholders needed to internally align first. They needed hundreds of hours of workshops to agree on how they wanted the new system to work alongside the old system, with all the dependencies mapped out.

The PO couldn’t drive that alignment. She didn’t have the authority, the skill, or the backbone.

We raised this issue more than ten times. The stakeholders didn’t want to even consider there was anything wrong with their PO.

At the end, we pulled the plug. They were spending money, but no real value was being generated. That’s not the business we’re in. If we’re not clearly creating value, it doesn’t make sense to continue.

Project 2: The FAANG Ego Trip

A startup led by two ex-FAANG employees. They thought they knew everything.

One founder handled business and acted as PO. The other was tech and jumped in as PO depending on focus area.

We made the mistake of assuming that because they came from top tech companies, we were in safe hands.

What actually happened:

Gold plating everywhere – Endless polishing for no reason. Features implemented with no need to launch. After more than a year, we discovered the core business idea had a fundamental issue and wasn’t properly implemented.

Constant complaints about the dev team – “Not senior enough. Not working hard enough. Don’t believe in the product.” All bullshit. The team was solid. The direction was broken.

Massive over-engineering – They prepared everything for 10,000 concurrent users. Guess what? Six months after launch, there was barely one concurrent user.

The “rockstar developer” delusion – When we started, they requested rockstar developers. Here’s the truth: you don’t need rockstar developers in a startup. You need a solid senior to make architectural calls, a solid mid to build reliably, and a motivated, ambitious junior to move fast and learn. That’s the team composition that works.

The FAANG POs brought big-tech thinking to a scrappy startup. They optimized for scale that didn’t exist. They built for problems they didn’t have. They burned runway on perfection when they needed validation.

The Real Cost of a Bad PO

Bad product owners don’t just slow projects down. They kill them.

Money burned – Every sprint running in circles is cash out the door with no value created.

Team morale destroyed – Good developers leave when they’re building the wrong things, being blamed for failures that aren’t theirs, and watching their work get thrown away because priorities changed again.

Opportunity cost – The time spent building the wrong thing is time you didn’t spend building the right thing. In a startup, this can be fatal.

Relationship damage – Bad projects with bad POs poison the client-agency relationship. Trust evaporates. Every conversation becomes adversarial.

What This Means If You’re Hiring a PO

Don’t hire based on pedigree. FAANG experience can actually be a red flag if the context doesn’t match.

Don’t hire based on availability or politics. The fact that someone is family, or free, or already on payroll, doesn’t make them the right PO.

Look for decisive people who’ve been in the fire. Have they owned a product that shipped? Have they made hard trade-offs under resource constraints? Have they aligned messy stakeholders and lived to tell about it?

Test their backbone. Can they say no to you? If they fold in the interview when you push back, they’ll fold when your stakeholders push back.

Assess their technical literacy. They don’t need to code, but can they understand system constraints well enough to have a technical conversation? Or do their eyes glaze over?

What This Means If You’re the PO

Own it. This is your product. When it succeeds, you did your job. When it fails, it’s on you. Not the developers, not the stakeholders. You.

Build the muscle to say no. Most of your job is figuring out what NOT to build. Practice saying “not now” and “not ever” until you can do it without flinching.

Invest in understanding both sides deeply. Learn enough about the business to make trade-offs. Learn enough about the tech to understand constraints. The gap between these two is where you live.

Create clarity. Your backlog should be a roadmap, not a wish list. Your priorities should be clear enough that the team can make decisions without you in the room.

Face the fire. When stakeholders are unhappy, don’t hide behind the dev team. When the dev team is frustrated, don’t hide behind stakeholder demands. Absorb the heat from both sides and translate it into decisions.

The PO role is hard. It’s high-pressure, high-stakes, and filled with no-win situations where someone will be unhappy no matter what you choose.

But when done right, a good PO is the difference between a project that ships value and a project that burns cash until someone pulls the plug.

Choose wisely.

The PO Readiness Checklist: Your First Week

If you’re stepping into the PO role, here’s what needs to exist before you write a single ticket:

Documents That Must Exist

Product vision document (1-2 pages max) – What are we building? Why does it matter? Who is it for? What does success look like in 6 months, 12 months, 24 months?

Stakeholder map – Who has decision authority? Who has veto power? Who needs to be informed? Who’s just noise? Map the power structure so you know who to align.

Constraint document – What’s the budget? What’s the timeline? What’s non-negotiable? What tech debt or legacy systems do we have to work with?

Success metrics – What are we measuring? Revenue? Users? Engagement? Retention? Define it now, not six months in when someone asks “is this working?”

Meetings You Must Schedule

Stakeholder alignment session (Week 1) – Get everyone in a room. Force them to agree on priorities. Document disagreements. Resolve them now or accept that you’ll be paralyzed later.

Tech architecture walkthrough (Week 1) – Sit with the tech lead. Understand what exists, what’s possible, what’s expensive, what’s fragile. You don’t need to understand the code, but you need to understand the system.

Team expectations session (Week 1) – Meet the team. What do they need from you? What slows them down? What motivates them? How do they want to communicate?

Weekly stakeholder sync (ongoing) – Lock this in. Same time, same day. Non-negotiable. This is where you manage expectations and prevent surprises.

Questions You Must Answer Before Sprint 1

• What’s the MVP? Can you describe it in three sentences?
• What are we NOT building in V1?
• What’s the riskiest assumption we’re making?
• What could kill this project?
• Who’s the user we’re designing for? Can you describe them specifically?
• What happens if we launch and nobody uses it?

If you can’t answer these, you’re not ready to start building.

When Your PO Is Failing: Intervention Tactics

You’ve realized your PO is weak. Maybe they can’t say no. Maybe they can’t align stakeholders. Maybe the backlog is chaos.

Most companies won’t fire a PO mid-project. So what do you actually do?

The Conversation Script

Have this conversation privately, not in front of the team:

“I want to talk about how we’re working together. I’m seeing [specific behavior: unclear priorities, circular discussions, direct stakeholder-to-dev communication]. This is creating [specific impact: team confusion, rework, frustration]. Here’s what I need from you going forward: [specific change: a single prioritized backlog, all stakeholder input filtered through you, a firm roadmap for next quarter]. Can you do that?”

Be specific. “You need to be more organized” is useless. “I need a prioritized backlog by Friday with no more than 20 items in the next sprint” is actionable.

When to Coach vs. When to Escalate

Coach when:

• They have the right instincts but lack process
• They’re overwhelmed but willing to learn
• The team still trusts them
• They own mistakes when confronted

Escalate when:

• They deflect blame to the dev team repeatedly
• They can’t or won’t say no to stakeholders
• The team has lost confidence
• They’re politically untouchable and incompetent

Guardrails When You’re Stuck With a Bad Product Owner

If you can’t replace them, contain the damage:

Create a technical veto – Give your tech lead the authority to say “this is technically impossible” or “this will take 6 months, not 2 weeks” and make it stick.

Impose structure – Force sprint planning. Force backlog grooming. Make them follow a process even if they don’t want to.

Limit stakeholder access – All requests go through the PO in writing. No hallway conversations. No direct Slack messages to developers.

Weekly written status – Make the PO write a weekly summary: what shipped, what’s blocked, what changed. Force clarity.

Shorten sprint cycles – Go from 2-week sprints to 1-week. Bad POs thrive in ambiguity. Shorter cycles force decisions.

Interview Questions That Actually Expose a Weak PO

Pedigree doesn’t matter. Experience at FAANG doesn’t matter. What matters is whether they can do THIS job in THIS context.

Question 1: “Tell me about a time you had to kill a feature that stakeholders wanted.”

What you’re testing: Can they say no?

Red flag answers:

• “I always find a way to make stakeholders happy” (they can’t say no)
• “We built it anyway and it worked out” (no judgment about trade-offs)
• Can’t give an example (they’ve never had to make a hard call)

Green flag answers:

• Specific example with reasoning
• Explains how they communicated the decision
• Owns the discomfort but stands by the call
• Can articulate what they said yes to instead

Question 2: “Walk me through your typical sprint planning process.”

What you’re testing: Do they have a repeatable process?

Red flag answers:

• “It depends” (no structure)
• Vague platitudes about “agile” and “collaboration”
• Can’t describe the mechanics
• Process sounds like it takes 8 hours

Green flag answers:

• Clear structure: backlog grooming, sizing, commitment, goals
• Specific time boxes
• Defined outcomes
• Sounds efficient

Question 3: “You have three critical features, two months of runway, and a team of four developers. How do you decide what to build?”

What you’re testing: Decision-making under constraints.

Red flag answers:

• “I’d ask stakeholders to prioritize” (deflecting)
• “We’d build all three in parallel” (no focus)
• Technical answer that ignores business impact
• Can’t make a call without more information

Green flag answers:

• Asks about business impact and risk
• Forces rank ordering
• Explains reasoning
• Makes a definitive call
• Acknowledges what’s being sacrificed

Question 4: “Tell me about a project that failed. What was your role in that failure?”

What you’re testing: Can they own mistakes?

Red flag answers:

• “I haven’t had a project fail” (they’re lying or haven’t taken real risks)
• Blames the dev team
• Blames stakeholders
• External factors only

Green flag answers:

• Specific example
• Takes ownership: “I should have…” or “I missed…”
• Explains what they learned
• Different approach next time

Question 5: “How do you handle a situation where your tech lead says something will take 6 weeks and your CEO wants it in 2 weeks?”

What you’re testing: Can they mediate between business and tech?

Red flag answers:

• “I’d push the tech lead to find a way” (doesn’t respect technical constraints)
• “I’d tell the CEO it’s impossible” (doesn’t explore creative solutions)
• “I’d let them fight it out” (abdicating responsibility)

Green flag answers:

• Asks both sides probing questions
• Explores scope reduction
• Finds the MVP within 2 weeks
• Manages CEO expectations on quality/scope trade-offs
• Makes a recommendation

Reference Check Questions That Actually Matter

Don’t just ask “Was [candidate] good?” Ask specific questions that reveal patterns:

To their previous stakeholders:

• “Tell me about a time [candidate] told you no. How did that go?”
• “Did projects generally ship on time? If not, why?”
• “How did [candidate] handle competing priorities from different executives?”

To their previous dev team:

• “How clear were priorities day-to-day?”
• “How often did direction change mid-sprint?”
• “Did [candidate] protect you from stakeholder chaos or amplify it?”

Listen for patterns. One bad experience is an outlier. Three people describing the same dysfunction is a pattern.

The “Good Enough” PO: Minimum Viable Product Owner

You’re not finding the unicorn who’s technical, business-savvy, a great communicator, politically adept, and decisive. That person either doesn’t exist or is already a CEO somewhere.

Here’s what you can’t compromise on – these must be innate or very deeply ingrained:

Decisiveness – You can teach process. You can’t teach someone to make hard calls under pressure. If they waffle in normal conversation, they’ll waffle when it matters.

Backbone – The ability to say no and absorb anger. This is temperamental. Either they have it or they don’t.

Ownership mentality – Do they take responsibility or deflect blame? Watch how they talk about past failures. This reveals character.

Here’s what can be learned:

Process and tools – Backlog management, sprint planning, roadmapping. These are skills. They can be taught.

Domain knowledge – They can learn your business. It takes time, but it’s learnable.

Technical literacy – They can learn enough tech to be dangerous. Won’t make them a developer, but they can learn to understand constraints.

The minimum viable PO:

• Decisive and has backbone (must be innate)
• Willing to learn your domain (teachable)
• Has run something end-to-end before (must have experience)
• Can communicate clearly in writing (mostly innate, partly teachable)
• Has basic project management instincts (teachable)

You can build up from there. But you can’t fix a wishy-washy people-pleaser who’s never owned an outcome. Don’t try.

When You Don’t Need a Dedicated Product owner

Sometimes a dedicated PO is overkill. Sometimes it’s actively harmful.

When the Founder Should Just Own It

Pre-product/market fit startups (pre-seed, seed):

• You’re iterating too fast for handoffs
• The founder has the vision in their head
• You need tight loops between customer feedback and product decisions
• A PO becomes a bottleneck and a game of telephone

Warning: The founder must actually do the work. If they say “I’m the PO” but don’t write stories, don’t prioritize, don’t attend standups, you’re worse off than having no PO.

When a Senior Dev Should Own It

Highly technical products with limited business complexity:

• Developer tools
• Infrastructure products
• Internal tooling

The users are developers. The decisions are technical. The trade-offs are technical. A senior dev who understands the domain will make better calls than a business-focused PO trying to learn tech.

Warning: Not every senior dev wants this job. Many hate it. Don’t force it on someone who just wants to code.

When You Need a Dedicated Product Owner

Post-product/market fit, scaling phase:

• Multiple stakeholders with competing needs
• Roadmap is 6+ months out
• Team is 5+ developers
• Business complexity (compliance, regulations, partnerships)
• Founder doesn’t have bandwidth

Complex stakeholder environments:

• Multiple business units
• Enterprise sales cycles
• Regulatory requirements
• When internal politics would eat a founder alive

The Brutal Truth Nobody Wants to Say

Here’s the pattern I see over and over, and nobody talks about it:

Most companies hire the wrong PO because they’re afraid to hire someone more competent than the founders.

Weak founders hire weak POs. They do it unconsciously, but the pattern is clear.

A strong PO will challenge you. They’ll tell you your roadmap is unrealistic. They’ll push back on your pet features. They’ll force you to make hard trade-offs. They’ll own the product in a way that makes you feel like you’re losing control.

Insecure founders can’t handle that. So they hire someone junior, or someone who’s a good “culture fit” (read: won’t push back), or someone who’s politically safe.

Then they wonder why the product drifts, why the team is confused, why money is being burned.

The truth: If your PO never makes you uncomfortable, they’re not doing their job.

A good PO should piss you off at least once a month by saying no to something you want. If they’re not, they’re just an order-taker with a fancy title.

The fear is real: What if the PO is better at product than I am?

Good. Hire them anyway. Your job as a founder isn’t to be the best at everything. It’s to hire people better than you and get out of their way.

If you can’t handle a PO who’s more competent than you at product, you’re going to build a mediocre product with a yes-person at the helm.

How to spot this pattern in yourself:

Are you avoiding candidates who have more experience than you? Are you gravitating toward people who defer to you? Are you uncomfortable when someone challenges your product decisions?

If yes, you’re about to hire a bad PO for the wrong reasons.

The fix: Hire someone who scares you a little. Someone you’re not sure you can manage. Someone who might be right when you’re wrong.

That’s the PO who will save your product.

How the PO Role Must Evolve

What makes a good PO changes as the company grows. If you don’t evolve the role, you’ll fail at the next stage.

Pre-Seed to Seed: The Scrappy Executor

What matters:

• Speed over process
• Bias toward shipping
• Comfort with ambiguity
• Direct customer contact
• Willingness to throw away work

What doesn’t matter:

• Formal roadmaps
• Stakeholder management (there aren’t many stakeholders)
• Process adherence

Profile: Former founder, early startup employee, or product person who’s comfortable in chaos.

Series A to B: The Organizer

What matters:

• Creating process without bureaucracy
• Managing multiple stakeholders
• Building roadmaps 6+ months out
• Team communication at scale (10-30 people)
• Balancing new features with tech debt

What doesn’t matter (yet):

• Cross-functional coordination with 10 teams
• Enterprise sales support
• Compliance and legal navigation

Profile: Someone who’s scaled a product from 0 to 1 and 1 to 10. Has seen the chaos-to-structure transition.

Series B+: The Orchestrator

What matters:

• Managing complex stakeholder landscapes
• Cross-team coordination
• Balancing short-term revenue with long-term vision
• Enterprise customer needs
• Compliance, security, legal requirements
• Strategic roadmapping 12-24 months out

What doesn’t matter (as much):

• Hands-on feature design
• Direct customer interaction
• Day-to-day sprint management (you have PMs for that)

Profile: Someone who’s been a PM or PO at a scale-up or large company. Comfortable with complexity and politics.

When to Swap Your PO

Warning signs your PO can’t scale to the next stage:

From startup to scale-up:

• They resist process (“we don’t need roadmaps, we’re agile!”)
• They can’t delegate
• Every decision requires them
• They’re still designing features instead of managing product strategy

From scale-up to enterprise:

• They avoid stakeholder management
• They can’t communicate with executives
• They don’t understand compliance/legal/security
• They want to be in the weeds instead of strategic

How to handle the transition:

Option 1: Coach them through it (if they’re willing and capable) Option 2: Promote them sideways (IC product role, domain expert) Option 3: Replace them (painful but sometimes necessary)

Don’t let loyalty or inertia keep the wrong PO in place. The company’s needs change. The role changes. Sometimes the person can grow with it. Sometimes they can’t.

Be honest about it before you’re six months behind and bleeding money.

Final Thoughts: Choose Wisely

The PO is the mini-CEO of your product. They can make you or break you.

Bad POs burn money, destroy team morale, and kill projects. Good POs ship value, align chaos, and make hard trade-offs that save your company.

Hire for decisiveness and backbone first, skills second. Skills can be taught. Character can’t.

Don’t hire someone weaker than you need because you’re afraid of being challenged. Hire someone strong enough to push back.

Evolve the role as your company grows. What worked at seed won’t work at Series B.

And if your PO is failing, fix it or replace them. Don’t wait. Every month you delay costs money and momentum.

The right PO is worth their weight in gold. The wrong one will burn your company to the ground.

Choose wisely.