Files
WebinarNotes/wiki/concepts/product-ownership.md

2.2 KiB

Product Ownership & Problem Framing

#concept

Summary

The durable human skill in the AI era: owning outcomes, not completing tickets. Put yourself in the user's shoes, look at the actual result, and reframe work from "what needs to be done" to "what problem needs to be solved." Sebastian: "No one ever needed a programmer… people have problems that you are solving."

Current Understanding

  • The profile-picture story: an engineer implemented "change your photo," ticked every acceptance criterion, but shipped it ugly (visible in the corner) because they never looked at the actual result. That absence is the absence of ownership — a mindset/personality trait, not a task list.
  • Reframe the vocabulary: stop thinking in tasks/tickets; think in problems and desired outcomes. If you don't understand what to build, "you will simply not be an engineer anymore"; if you do get closer to the product, the software gets better (product-wise, even if not always technically).
  • Verification is the new craft. As code-as-throwaway, the engineer's value is directing and verifying — Sebastian's printer anecdote: his edge was knowing how to instruct and check the result, not writing Java. This is also the senior's advantage: read what you approve (seniority-and-the-junior-squeeze).
  • Allie's parallel: the meta-skill is knowing what good looks like (taste) — you don't need to do the graphic design to judge whether the ad is good.

Evidence

Contradictions / Uncertainty

  • "Get closer to the product" can improve product quality while reducing technical quality — the interview flags this trade-off explicitly.

Next Questions

  • How do you teach/hire for ownership if it's a personality trait, not a checklist?