The job ate the title

Product management used to sound like a seat you filled. Now it is closer to a set of decisions people make with or without the label — the founder who writes positioning, the engineer who names the promise in the UI, the designer who kills a feature because the story does not hold. The craft is less about owning a backlog and more about owning what should exist, for whom, and what you refuse to build while someone watches the clock.

Deep product work today is depth under speed. You hold business pressure, taste, and feasibility in the same week — sometimes the same afternoon. You make tradeoffs legible enough that your future self (or the first person you hire) does not have to reverse-engineer your intuition. You let the story lose in private — research, debate, a spec that admits what is still a bet — so it does not only lose in public after you have shipped your pride.

Census-scale reality backs how lonely that job can be: in recent U.S. business surveys, roughly three in five businesses report a sole owner. That is not a flex — it is a picture of how often one ledger holds nights, savings, and reputation at the same time. When the org chart is that flat, “PM” is not a department. It is you, deciding.

Verifying a product is not a checkbox next to “talked to ten people.” It is climbing rungs that cost more ego each time: named hypothesis → something you can see someone do → comparison to what they already use → a commitment that hurts a little (time, money, switching). Most teams stop early because later rungs are socially expensive. The depth you need is the depth you are willing to be wrong in public about — before public is the App Store.

That is also where persona work stops being decoration. A persona is defensible when it carries a situation, a trigger, something you have actually observed, and a sentence that starts with “we would be wrong if…” — not when it is three adjectives and a stock photo.

A product doc is “good enough” when another builder could scope without séance: the problem is tied to evidence, the user shows up in a real context, scope has explicit cuts (including the painful ones), success is observable, and risks are named instead of smeared into optimism. If reading it still leaves “but who is it for?” open, the thinking is not finished — only the typing is.

BLS-style survival curves add the same moral from another angle: on typical benchmarks, about half of new employers are gone by roughly year five. Cheap tools did not cancel that gravity — they only made it easier to spend the first year building the wrong story beautifully.

Bloom is for people who already live inside that merged job — idea as seed, PM craft without the job title, and the need to strength-test the win before the repo becomes the only witness. Research you can cite, structured opposition, a visual read on the experience, then a PRD that reads like a receipt: proof the story was argued with, not just animated.