44 lines
3.5 KiB
Markdown
44 lines
3.5 KiB
Markdown
# 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?
|