all

wiki/concepts/product-ownership.md

@@ -0,0 +1,43 @@
+# 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?