A large account stalls your deal because it wants its data in its own Azure, its own IAM, its own keys, its own LLM contract. This piece offers a way to sort those requests: what actually carries your value, what merely makes it buyable, and where to draw the line between the customer's control and your ability to keep the product evolving.
Your team rebuilds the same product model for every question, every bug, every tender. Here is how to write it down once: several dozen objects, a few hundred rules, under six hours. And above all how to know you have finished — the three stopping criteria that look like proof of completeness and prove nothing, plus the one that holds.
Hiring a PO to hold the backlog and sit between the business and the developers? You are optimising a circuit that is already obsolete. This piece takes apart the split between the people who do the thinking about the product and the people who execute it: why it degrades quality, why a backlog cannot support a profession, and why AI removes the last excuse for living with it.
AI raises the capacity to build, not the capacity to decide. Developers move up towards product; PMs move down towards building. The shift blurs roles without dissolving responsibilities. A full pass over what AI makes ordinary in product management, what stays hard, and a catalogue of emerging roles with the real risk attached to each.
Four days building a real product with Claude Code — 180 commits, starting from nothing. What it shows: the speed that goes to your head, the traps the AI creates on its own, what tests change when you haven't written the code yourself, and how far a PM can go without stepping outside their remit. A field report, not a doctrine.
Do you lose half an hour in a test environment just to answer a product question on Slack? That hidden cost disappears once AI can query the source code, the real truth about how the product behaves. Answers grounded in evidence — functions, tests, commits — rather than in documentation that has fallen behind. Provided the code speaks the language of the business.
You think a market opens up once your product is translated? Brazil says otherwise. Through the most mundane scene there is — paying at the till — you'll see why everyday credit, a tax ID number, Pix and a visible informal economy form a cultural infrastructure no translation reproduces. Enough to avoid an expensive strategic mistake abroad.
Most organisations know how to produce documents. They don't know how to bank the reasoning behind them. On every decision they start again almost from scratch. The PM as Context architect turns scattered customer knowledge — transcripts, objections, past calls, weak signals — into a reusable asset. The result: faster, sturdier decisions, and an advantage competitors cannot copy overnight.
The real problem with bugs isn't that they exist, it's the organization that grows used to keeping them. We prioritize them, we push them back, we review them in committees — until a customer crisis hits. A zero-bug policy aims at something else: zero known bugs left undecided. Either we fix it, or we accept it isn't a defect. What this approach refuses is the third state: knowing a bug exists and keeping it alive in a list for later.
A product team can pile up studies, workshops, and analyses without the company ever knowing what's a priority. The NNL roadmap answers this problem: not by scheduling dates, but by making commitments, serious directions, and possibilities visible — and above all, what won't be done. Its strength lies in the capacity constraint and in the implicit No.
Certain product decisions come up everywhere: in roadmap reviews, with sales, in specs, with every big client. Without a record, the company keeps re-deciding them, often with less context. The PDR — inspired by technical ADRs — documents these cross-cutting decision rules. Rare, short, immutable: it doesn't say what to build, it says why the company chose a rule. It removes dozens of pointless discussions.
In many organizations, the backlog has become a clean trash can: you throw everything in so you don't forget. A few months later, 500 lines nobody understands anymore. A backlog shouldn't be a repository of ideas, a database of customer signals, or the graveyard of untriaged bugs. It exists to organize information mature enough for several people to work on it together. It comes into play when the work stops being individual.
A zero-bug policy shrinks the stock of known defects. But if the team fixes them faster without changing how it builds, it stays stuck in a repair loop. The real issue lies upstream: giving ownership to those who ship, refusing overly vague specs, testing earlier, giving QA a quality-policy role rather than a catch-up one. Quality can't be delegated after the fact — it belongs to those who ship.
Watching what competitors ship means reading outputs without understanding the reasoning behind them. Useful intelligence starts from the target customer: their needs, their decision criteria, their alternatives. Competitors only become interesting because they reveal how a market responds to those needs. Copying a move without understanding the logic behind it means reproducing an answer without ever having asked the right question.
Managing product opportunities inside a borderless network of notes means losing control: errors propagate silently, the AI context window blows up, and contradictions and decisions become impossible to find. The bounded context — borrowed from DDD — offers a better approach: each opportunity in its own bounded, auditable space, with a structured memory.
Documentation never keeps up with the code. We know it, we accept it, and yet it costs us time with every change. AI shifts the equation: when the code is clean, it becomes the source of truth from which the other artifacts—specs, changelogs, support documentation—can be regenerated. This code-centric approach demands a minimum of technical literacy, but it opens a real lever for the product managers who master it.
Too many insight systems fail because they classify everything along a single axis: features, or business stakes. Tactical feedback gets lost, strategic signals evaporate. A 4-level framework — business stake, use case, product capability, local friction point — lets you capture everything without a Rube Goldberg machine, and ties each signal to the right level of decision.
Producing software is no longer rare. The cloud commoditized it, and AI will accelerate the trend further. When everyone can build fast and well, churning out features by the yard is no longer enough. The real competitive edge shifts toward understanding the context: the business, the users, the customers, the competition, the standards. Understanding better than others, before building.
Your days as a PM are devoured by tasks that have nothing strategic about them. In eight days on Claude Code, I automated my competitive intelligence — gathering, organizing, updating. Time reclaimed to analyze, understand, decide. This field report shows concretely why the center of gravity of the Product Manager job is shifting: fewer intermediate artifacts, more real strategy.