# 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

## Related Pages

- [[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?
