> **TL;DR:** “Product engineer” is a label for a real shift: more engineers own customer outcomes end-to-end. As that happens (and as AI makes shipping faster), the bottleneck becomes **product truth** — keeping intent aligned with what production actually does. The missing artifact is a living behavior contract: not docs, not tickets, not tests. The “product engineer” conversation tends to sound like a job-title debate. It’s not. It’s a signal that the center of gravity is moving: more engineers are being asked to own **outcomes**, not just deliverables. And if that becomes normal, most teams will hit the same wall: You can ship faster than you can remember what your product is supposed to do. --- ## “Product engineer” is a messy label for a clear pattern Depending on the company, “product engineer” can mean: - a full-stack generalist who ships end-to-end - an engineer with strong UX taste and ownership - an engineer who can define a small slice of work without a full PRD It’s also a long-standing title in hardware/manufacturing, which adds confusion. But in software, the pattern is consistent: **tighter loops, fewer handoffs, more individual responsibility**. That’s a good thing. It’s also how product truth gets lost. --- ## When more engineers own outcomes, product truth fractures As ownership spreads across more people and faster cycles, your product decisions start living in places that don’t survive: - Slack threads - pull request descriptions - “tribal knowledge” in someone’s head - ticket comments that never get read again The code will reflect *something*. But the *why* disappears, and the “what” becomes ambiguous: - Is the 14-day refund window a deliberate product rule, or just the current implementation? - Is “3 projects on free tier” a hard cap, or a soft warning? - Is this edge case intentionally allowed, or simply not handled yet? When you’re shipping quickly, these aren’t philosophical questions. They’re the difference between “we shipped the plan” and “we shipped a version of it.” --- ## AI makes the problem sharper, not softer If your team’s execution speed increases (because of AI, better tooling, or smaller teams), the cost of missing product truth goes up: - more changes per week - more surface area touched per change - more chances to refactor away an implicit business rule A stronger builder can create bigger product mistakes more efficiently — if nobody has a durable artifact that defines “what the product must do.” --- ## The missing artifact: a living behavior contract Most teams don’t need more process. They need a better artifact. Something that sits between “spec” and “implementation” and answers: - what the software **does** (including edge cases) - which behaviors are **confirmed** as intentional - which behaviors are **provisional** and likely to change - what’s still **undecided** That artifact is what we call a **Product Behavior Contract (PBC)**. It’s markdown-first, readable, and can include structured anchors when precision matters. And it’s designed to survive organizational change. --- ## Why this isn’t docs, tickets, or tests It’s tempting to say “we already have docs.” But: - Docs optimize for explanation, not coverage of real behavior. - Tickets optimize for coordination, not long-term truth. - Tests optimize for preventing regressions, not communicating intent across humans. A behavior contract is different: it’s a durable, reviewable statement of what the product does and what the team intends. --- ## Where Stewie fits Stewie is a **product intelligence workspace** built to make this contract practical. The workflow is simple: 1. Run product analyses on a repo to generate a product structure map and candidate behaviors. 2. Triage those behaviors with the people who know the intent — keep what's right, flag what's not. 3. Maintain a living `.pbc.md` contract that stays aligned as the code evolves. If you’re a product-minded engineer (or a PM/Eng pair) shipping quickly, that’s the missing layer: Not “more documentation.” Product truth that doesn’t disappear. The format is open source. The [PBC viewer](https://pbc.stewie.sh) lets you browse contracts in the browser. And Stewie is in early beta — the landing page has the waitlist at [stewie.sh](https://www.stewie.sh).