Every Product Manager has heard both sides of this.
Domain people say “you can’t build products in this industry if you don’t know the industry.”
Craft people say “a good PM can learn any domain.”
Both are half right.
Today we cover:
Why I lean towards domain (and where I see it hurt)
Domain is depth, not an industry label
The craft-first trap
A learning from my own world, payments
My verdict
A short word on AI
From our sponsor: Jimo Agent walks new users through your product, on the screen in front of them.
👉 A user types what they're trying to do, and Jimo builds a step-by-step guide fitted to that screen. It can also answer from your docs, or do the thing for them. Nothing has to be rewritten when a screen changes, and Jimo customers onboard new users in half the time.
My honest starting point
Domain matters a lot. If you don’t know the problem space and the solution space, you spend your time catching up before creativity can even kick in. You are stuck understanding, not creating.
I see this show up in two places, in any industry.
1. Business success is defined by the domain-related outcomes, not by the Product Craft Outcomes.
A PM can follow every craft step (documentation, structures, backlog management, PRD writing, Great acceptance criterias and more) and still not win (by which I mean success as defined by that industry itself).
Every industry has its own scoreboard: margins, unit economics, regulation, market share. You can launch a product beautifully, but if the P&L doesn’t work or you can’t compete in that industry on its terms, the launch was a success only on paper.
A launch means the team shipped after a lot of effort (hence often the blood ,sweat and tears feel like success when that product is finally out). Winning means it also makes sense in the real world: positioning against competitors, user preference, ease of conversion, and a business goal you actually reach.
Solve the customer problem yes, but do not stop there. All solved customer problems don’t always lead to successful business outcomes.
2. The core of the product is often not just the user experience
PMs without domain knowledge are usually strong on front end and user experience. They design a perfect journey and win the argument for it. But they are weaker on platform, core and infrastructure topics, and many dependencies live exactly there.
So feasibility becomes “whatever my engineers tell me.” Can it scale? Can we build more experiences on top of it? How much product debt is there? Do incremental features keep getting slower? These questions come from domain knowledge, and a UX-first PM often does not know to ask them.
Domain is not an industry label. It is depth.
Saying “I work in healthcare” or “I am a logistics person” does not mean much. Staying with few very important problems in your domain long enough that you know exactly where it breaks, that is domain knowledge. If you keep jumping from one problem to another, knowledge stays surface level and creativity never kicks in.
Also, domain is more local than people admit. The same industry looks different across companies, regulations, cultures and geographies. Every time you move, part of your knowledge needs rewiring.
An example from my world: payments
I work in payments, so let me quote some of my own learnings. Your industry will have its own version.
In payments there is a universal layer: pay-ins on time, pay-outs on time, the basics of payments infrastructure, and a lot of finance and accounting underneath. That travels with you everywhere. Then local layers sit on top:
→ A cash-heavy market with room to digitise vs an already digitised one
→ A credit-hungry culture vs a credit-cautious one
I learnt this the hard way. Every time I changed companies or geographies, I assumed I knew the domain. Same domain, different regulation, customers, partners and culture.
And here is the contrast I care about most. A craft PM can make pay-ins and pay-outs meet the industry standard. A domain-knowledgable PM makes them better than everyone in the industry. Swap payments for your own domain and the pattern holds: shallow knowledge gets you to standard, depth gets you past it.
The craft-first trap
Now the other side, and I will be fair to it.
Generalists also have a role to play. They find patterns in how domain experts work and bring structure to it. This frustrates domain experts, who just want to get things done. And craft people can apply too much craft, while domain experts worry too little about it. Both sides need to come closer.
But here is what I see when a craft-first PM lands in a domain they skipped. They go back to fundamentals. Start discovery, study the market, list customer types. All good practice. Except the problem in front of them is often a commodity problem that many others in the industry have already solved.
Knowing WHICH problems are commodity and which are still open is itself domain knowledge. It tells you where to copy the standard and where to be original. That saves months.
In my experience and observation, craft people who skip domain struggle more than domain people who skip the perfect craft.
My verdict: they feed each other
You can enter from either side:
→ Start with domain, and gain product craft along the way
→ Start with craft, and gain domain through product discovery
When I join a new company, my routine is mostly craft used to earn domain: study the market, talk to customers, study product data and behaviour, talk to sales and key account managers, go to conferences, and subscribe to newsletters from that region (my favourite hack). Craft is how I earn domain. Domain is what makes the craft pay off.
The real risk is stopping at one. And whichever you choose, go deep on a small set of problems instead of staying broad across many.
And what about AI?
Briefly…
AI is very good at common knowledge, simplifying, brainstorming and helping you learn a new domain faster. It helps you formulate your thoughts, check your biases and build prototypes quickly. PM work is mostly information in, action out, and I now spend less time reading and writing without losing quality.
But AI does not make you a better problem solver or product craftsperson, because that comes from practice in real life. And it is only as good as what you feed it. It stops helping at the edge of what it knows, and at tough trade-offs where you need creativity, not a summary.
So AI makes breadth cheap. Depth is where your own creativity comes in.
If you are worried about your PM career, here is my weekend advice: go through each workflow, make it AI-enabled, check what others are doing, and try some workflows in an entirely new way. Then spend the time you save going deeper on fewer problems.
Over to you
Where are you today?
A) Domain first, still building craft
B) Craft first, still building domain
C) Both, and they feed each other
Tell me in the comments