A common hiring misconception is that PMs must be hired primarily for domain expertise because a given industry is "too complex" for an outsider to learn. Chris Jones (SVPG) notes that nearly every company believes its own domain is uniquely complex, and that hiring for domain experience has rarely worked out well for him in practice.
Shreyas Doshi's formula, as quoted by Chris: true domain expertise = domain knowledge − domain dogma. Domain veterans often import "it's always been done this way" thinking, and that dogma is hard to remove once ingrained. It is easier to start with a PM who has no domain knowledge and add expertise quickly than to start with a domain expert and try to subtract baked-in dogma. A PM should still become the acknowledged customer/data/industry expert early on — just without the dogma.
Enterprise executives who cite scale, regulation, or complexity as reasons they need domain-expert PMs are, per Christian, actually making the argument for product managers rather than against generalists: the job is creative problem-solving within constraints, not knowing the existing rules. As an illustration, the first wave of fintech disruption largely did not come from insiders inside banks/compliance functions who said "we cannot do this" — most of it came from outsiders without institutional permission.
Chris Jones (SVPG) cites a security startup with three co-founders — only one of whom had deep security domain background — as first-hand evidence for this formula. Unburdened by "how security has always been sold and built," the team took a dramatically different technology and go-to-market approach than the security incumbents, and the company achieved a higher valuation, higher ASP, and higher perceived value than domain-typical competitors. The lesson: deep domain tenure can calcify into assumptions about how a category "has to" work — exactly the dogma this concept warns against.
Chris Jones estimates it takes roughly three years to develop a genuinely good product manager, but only about three months of focused effort to bring someone up to speed on a new domain. The asymmetry argues for hiring PM skill over domain pedigree: stripping ingrained dogma out of a domain veteran is harder and slower than teaching a strong generalist the domain facts.
Supporting evidence offered: most innovation in fintech reportedly came from outsiders without institutional "permission" from banking/compliance insiders — "Most innovation in that industry came outside of the people that had permission." Deep domain incumbency can be a liability, not merely neutral, when the goal is disruptive problem-solving. See Diagnostics for Reading a Candidate's Product-Leadership Archetype and MSN List (Must/Should/Nice-to-Have Hiring Framework) for related hiring-evaluation frameworks.
Domain/tenure expertise is a double-edged sword for Product Sense: a necessary baseline understanding of users, but the same expertise can calcify into dogma that blocks continued learning. Two examples: long-time programmers treating object-oriented programming as a universally necessary paradigm, and many of those same long-time programmers struggling to adapt to generative AI precisely because it is probabilistic rather than deterministic — the entrenched domain expertise becomes the obstacle, not the asset.
The same failure mode shows up across domains, not just within one: founders who built genuine product sense in one industry through years of immersion sometimes mistake that success for personal genius, skip the immersion/humility work required in a new domain, and end up with no real product sense there. Expertise transfers only if the underlying humility and curiosity that built it also transfer — the domain knowledge itself does not.
Deep domain expertise is explicitly framed as a 'superpower' — and, in the same breath, as dangerous: real innovation requires questioning assumptions that experts in a field have stopped questioning precisely because they're experts. The danger isn't the expertise itself, it's the dogma that accumulates alongside it once assumptions calcify into unquestioned defaults. See Constraint Reframing as the corrective habit.
A concrete example Cagan gives: teams that believe Continuous Deployment Cadence isn't allowed under their compliance regime — when in fact no such hard requirement exists, and the belief is inherited habit mistaken for a compliance rule. This is domain dogma, not domain knowledge, and distinguishing the two is part of the Product Sense a founder-style leader needs in order to coach a team past an inherited constraint rather than accept it at face value.
Compliance-heavy industries are where the expertise/dogma confusion is most common and most costly: teams frequently claim a constraint is 'required by regulation' when it's actually inherited habit — dogma passed down as if it were law. The fix is to verify the actual rule rather than accept the inherited lore.
"So, the true domain expertise is when you pull out the dogma."
A coach's job in these settings is to actively interrogate 'we have to do it this way because compliance' claims rather than deferring to them, since deference just launders dogma as expertise.
A concrete instance: teams in compliance-heavy industries like finance often avoid practices such as Continuous Deployment Cadence, believing regulation forbids it — when in most cases it doesn't. The obstacle is domain dogma (an unexamined belief about what the domain requires) rather than actual domain expertise or actual regulatory constraint.
Apply: when a team cites 'our industry/regulator won't allow X,' verify the actual regulatory text before accepting the constraint — the block is often inherited belief, not law.