Product Ownership

#concept #ai

Summary

The durable human skill once AI writes the code: owning the outcome a user actually experiences, not the ticket you were handed. From 2026-07-06-sebastian-interview-ai-and-software-engineering. It is the supply-side twin of outcome-based-selling — the same "outcomes, not deliverables" principle, seen from inside the engineering work rather than the sale.

Current Understanding

Ownership = putting yourself in the user's shoes and understanding what they'll expect — a mindset/personality trait, not a task list. The reframe: stop thinking "what needs to be done" (tickets); start thinking "what problem needs to be solved." "No one ever needed a programmer… people have problems that you are solving."

The profile-picture story (the whole idea in one anecdote): an engineer implemented "change your photo," ticked every acceptance criterion, and shipped it ugly — the photo visible in the corner — because they never looked at the actual result. Meeting the spec is not owning the outcome.

Why AI raises the stakes. When code is nearly free, acceptance-criteria-following is exactly what the AI does; the human's remaining value is judging whether the result is actually good for the user. Sebastian's sharp version: if you don't understand what to build, "you will simply not be an engineer anymore" — or you get closer to the product and the software gets better product-wise (if not always technically). This connects to seniority-and-ai (the senior's judgment is what catches "spec met, outcome bad") and to relationships-as-moat (understanding the client's real problem is the same skill that wins trust).

For a services business this is the through-line to the sales side: outcome-based-selling can only promise an outcome if the delivery culture actually owns outcomes. Ownership is what makes an outcome guarantee survivable rather than reckless.

Evidence

"No one ever needed a programmer… people have problems that you are solving." — 2026-07-06-sebastian-interview-ai-and-software-engineering
The profile-picture story (spec met, result ugly, never looked) — same source
"Stop thinking what needs to be done; start thinking what problem needs to be solved." — same source
Move-up-the-value-chain conclusion: from "produce the solution" to "understand and frame the problem, then direct and verify the AI." — same source

outcome-based-selling — the demand-side twin (sell outcomes)
seniority-and-ai — judgment as the senior's product; ownership is part of it
future-of-engineering-work — the role shift from coder to problem-owner
relationships-as-moat — understanding the client's problem is the shared skill
overview

Contradictions / Uncertainty

Single-source (the interview) and framed as a personality trait — the source offers no method to teach ownership, only to recognize its absence. Status: tentative as a trainable skill vs an innate trait.
"The software gets better product-wise, if not always technically" concedes a real tradeoff (product-owner engineers may ship technically worse code) that the source doesn't resolve.

Next Questions

Can ownership be trained/hired for, or only selected? What interview signal reveals it?
Where's the line between "own the outcome" and scope creep, when the AI makes gold-plating cheap?
Does product-owner-engineering degrade technical quality enough to matter in regulated/high-liability work?

3.5 KiB Raw Blame History