Files
WebinarNotes/wiki/concepts/product-ownership.md
EugeneTes 62d0f06a2d all
2026-07-30 11:13:27 +02:00

4.3 KiB
Raw Permalink Blame History

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.
  • First-principles thinking becomes the top skill (thorsten-ball). His anti-example: someone at his club asked for an app so a tablet prints a paper receipt the kitchen picks up. His push-back — "Why do you need a printer? Why not a second tablet?" — is the whole competence in one question. The skill is seeing the workflow underneath the request, and it is now the scarce half of the job: "everyone becomes an architect," and the value is knowing solutions from other industries and having the right idea for this problem. Note the direction of travel: the profile-picture story above is a failure to check the output; the printer story is a failure to check the problem. Ownership now runs at both ends.
  • What just got commoditised. What senior engineers used to hand-teach over 23 years — his example, the safe multi-step column-drop migration — is a 30-second model output. Also gone is the lucky overlap of the last 2030 years, where "the guy who loves Haskell on weekends is also the guy who models the finance backend well." Technical depth and domain judgment have come apart, and only the second is still scarce. See seniority-and-the-junior-squeeze.

Evidence

Contradictions / Uncertainty

  • "Get closer to the product" can improve product quality while reducing technical quality — the interview flags this trade-off explicitly.
  • "Everyone becomes an architect" is asserted, not argued. The corpus's own non-engineers reach for AI to do the framing for them (levels-of-ai-usage), and nothing establishes that first-principles thinking distributes more widely than the technical skill it replaces. Status: tentative.

Next Questions

  • How do you teach/hire for ownership if it's a personality trait, not a checklist?
  • If the senior's 23 years of hand-taught pattern knowledge is now a 30-second output, what is the new apprenticeship — and does it produce the judgment the printer story requires? Compounds the pipeline problem on seniority-and-the-junior-squeeze.