# Product Driven Model
A five-part model Matt built while trying to teach software engineers to think about product beyond just code. It is not a company-wide HR-style mission statement — it's tactical: a weekly discipline for giving an engineering team the why behind its work. The five components are vision, focus, clarity, shared ownership, and courage.
Explaining why this specific piece of work matters this week — not an aspirational company vision but a tactical, recurring framing of purpose tied to the current task. Contrast with the broader, longer-horizon sense of Product Vision.
Telling engineers explicitly why the team chose to do this thing and not that thing, including the trade-offs involved. Ambiguity about "why" is one of the biggest sources of engineer frustration. Compare Annotate Roadmap Items with the 'Why'.
The constant, day-to-day flow of what needs to be done and why, mostly supplied by product managers. Matt considers clarity probably the most important of the five components because it drives what a team actually does day to day. Clarity has to be dosed: handing a team six months of requirements at once is as unusable as handing them none — context needs to arrive project-by-project or day-by-day. The best engineers ("purple squirrels," "10x developers") create their own clarity and don't need to be told what to do. Related: Lead with Context, Not Control (Netflix Mantra).
The goal state the model works toward: ownership of work should always be distributed across a team, never resting with one person — not even a company's founder — because an organization can't scale from one team to many without shared ownership. Related: Founder–Leader Ownership Map. (Distinct from Vision Authorship: Never a Collective Enterprise, which is about single authorship of vision specifically, not day-to-day work ownership.)
The component that originated the whole model, about 18 months before this conversation, sparked by conversations at Full Scale about developers who were "struggling" rather than "bad." Courage means telling engineers explicitly that they were hired as experts and are wanted to voice opinions, ask why, and suggest better ideas. It also requires leaders to have the courage to change and stop being "the hero." Tied to psychological safety: a team member should feel safe saying they don't want to be "the code monkey" anymore, and a leader should respond by thanking them and acting on it. Related: All Problems Are People Problems, and People Problems Are Leadership Problems, Hollow Empowerment Declaration (Abdication Mistaken for Empowerment).
Applying the model mostly comes down to spending a few extra minutes every week giving the team context on what they're doing, why, and whether they're winning or losing based on the previous week's work.
Vision — not a company-wide, HR-style vision statement, but the tactical vision of why a specific piece of work matters this week. Applied by explaining to the team why the thing being built today matters, framed as the "big picture" for the current week rather than the multi-year horizon.
Focus — explaining the customer value behind doing this thing and not that thing, including the trade-off behind the choice. When engineers ask why approach A was chosen over approach B, tell them explicitly, so they understand the trade-off and get on board rather than just complying.
Clarity — probably the most important of the five, since it drives what a team does day to day. It's the continuous, day-by-day flow of information from product managers about what needs to be done and why. Clarity has a dosage problem specific to engineering work: too little context stalls engineers into asking someone else what to do next; too much context (e.g. six months of requirements dumped at once) is equally useless because it won't be remembered. The fix is to dose context day-by-day or project-by-project, giving just enough to unblock today's work — see roadmap-mistaken-for-strategy-antipattern for a related failure mode of substituting a long list for ongoing clarity.
Shared ownership — a state in which ownership of a product or team is always distributed among everyone, never held by a single individual — explicitly not even the founder, reasoning from the risk of what happens when that one person leaves. Practically: give every team member a voice and an opinion, and let the team collectively decide and strike a balance. This is the mechanism Matt credits for letting a company scale from one team to many teams, echoing Founder–Leader Ownership Map.
Courage — the willingness of engineers to voice opinions, ask why, and suggest better ideas, paired with leaders' willingness to change and stop being "the hero." At Full Scale this component originated from a labeling shift: the company stopped calling underperforming developers "bad" and reframed them as needing "courage," turning a performance issue into a psychological-safety/leadership issue rather than a skills issue. Applied by telling struggling developers explicitly that they were hired as experts and are wanted to speak up, ask why, and suggest better ideas — and thanking them when they do (e.g. when someone says they no longer want to be "the code monkey").
A concrete practice tying shared ownership and courage together is the Definition of Done: 'Log In as Me' rule: once Matt modeled the expectation himself, a lead engineer independently began repeating and enforcing it to the rest of the team without being asked to.
Notably, Matt built this model without compressing it into a mnemonic acronym — a choice one interviewer reads as a sign of his engineering/CEO background rather than a "product person" background, who would more likely have "backwards engineered it into an acronym to make it a little bit more memorable."
Из тем: The Product Operating Model