Your team rebuilds the same product model for every question, every bug, every RFP. Here is how to write it once: 52 objects, 250 rules, under six hours. And above all, how to know you're finished — the three stopping criteria that look like proof of completeness and prove nothing, plus the only one that holds.
ReadHiring a PO to keep the backlog and sit between the business and the developers? You're optimizing a circuit that is already obsolete. This piece takes apart the split between those who think the product and those who execute it: why it degrades quality, why a backlog cannot ground a profession, and why AI removes the last excuse for living with it.
AI raises the capacity to produce — not the capacity to decide. Developers move up toward product, PMs move down toward construction. This shift blurs roles without dissolving responsibilities. A full account of what AI commoditizes in product management, what remains hard, and a catalog of emerging roles with their real risks.
Four days building a real product with Claude Code — 180 commits, from scratch. What it reveals: the intoxicating speed, the traps AI creates on its own, what tests change when you're not writing the code yourself, and how far a PM can go without leaving their lane. A field report, not a doctrine.
Shipping code faster doesn't help if nobody understands what got built. AI automates exactly the tasks that used to train junior developers, and a delayed error stops teaching anything once the system has grown too complex. A few concrete anchors for staying in control: clear contracts between APIs, tests tied to actual behavior, rebuildability as a quality bar instead of raw delivery speed.
Your documents don't say everything: the fine-grained understanding of the field stays in the PM's head. Session sources give you a channel to pour that informal knowledge into an AI Context — a hallway remark, a customer nuance, an emerging tension — and turn an accumulation of micro-signals into notes, hypotheses, and better-framed decisions.
Your tools file information away just fine, but they don't capitalize on what it teaches you. This piece explains why the future of the information system isn't a better AI-filled form, but a shift toward contexts: portable, governed units of memory that can link sources, decisions, and reasoning instead of merely storing them.
Do you lose half an hour spinning up a test environment just to answer a product question on Slack? That hidden cost disappears when AI queries the source code, the real truth of how the product behaves. Answers grounded in evidence — functions, tests, commits — instead of stale documentation. Provided the code already speaks the language of the business.
Do you lose the thread the moment you reopen a conversation with an AI on a subject that stretches over time? This article lifts the hood on a structured memory system: the difference between the goal and the attention, the directives, the offline queue, the three memories (journal, synthesis, checkpoints) and the cycle of a session. Enough to understand how an AI can truly remember a mission.
Think a market opens up just by translating your product? Brazil proves otherwise. Through the most mundane scene imaginable — paying at the register — you'll see why everyday credit, a tax ID number, Pix and the informal economy form a cultural infrastructure that no translation reproduces. Enough to avoid a costly strategic mistake abroad.
The thematic note is the link between the note system and writing. It doesn't pile up everything touching a subject — it picks an angle and assembles several atomic notes to reveal a pattern, a tension, or a line of argument. Neither folder nor encyclopedia: a temporarily stable view onto a network of thought.
\"One idea per note\" — the formula is well known, but it often leads us astray. An atomic note isn't a short note: it's a note with a single conceptual center of gravity. Grasping this distinction changes how we capture, rephrase, title, and connect our notes. And ultimately, how we write.
The same words travel between product, marketing, sales and leadership — without everyone giving them the same meaning. A glossary isn't a collection of textbook definitions: it's a tool for collective precision. It stabilizes the terms that carry decisions, protects the links between notes, and lowers the cost of conversations where everyone defends a different idea using the same vocabulary.
We pile up tabs, links, quick notes — and never read them again. The problem isn't the amount of information, it's the absence of any decision about what it becomes. This article separates capturing from building capital, and offers a simple rhythm for turning your captures into knowledge without drowning in them.
Having an excellent note base isn't enough if the ideas aren't truly internalized. A flash card isn't a small atomic note: it's a personal pillar of thought, recognized in the moment by its resonance, tested over time by experiences and new sources. Rare by definition, it structures what you truly want to hold within you.
Most organizations know how to produce documents. They don't know how to capitalize on the reasoning behind them. With every decision, they start over almost from scratch. The PM as context architect turns scattered customer knowledge — transcripts, objections, trade-offs, weak signals — into a reusable asset. The result: faster, more robust decisions, and a competitive edge that rivals 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.
You leave a meeting with an action plan, yet nothing has truly been settled. This is what I call a soft decision: a non-decision dressed up as consensus. Organizations often prefer it to a genuine judgment call because it preserves the appearance of agreement without making the loss visible. This piece explores why the mechanism is rational in the short term, and why it costs so much at the execution stage.
Your teams leave the meeting aligned—and each walks away with a different version of the decision. The problem isn't a lack of meetings, it's the absence of shared objects. Glossary, one-pager, PR/FAQ, ranked metrics, decision log, escalation rules: these tools don't produce alignment, they force disagreements to become visible before they turn costly.
Classic RAG starts from scratch with every question. By building an AI Wiki — a persistent wiki maintained by an LLM — you capitalize on domain knowledge once and for all. Atomic notes, links between concepts, contradiction detection: knowledge is compiled, not rediscovered. Lessons learned from 950 notes extracted from industrial maintenance sources, with calibration insights and concrete use cases.
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.
Drowning in email and losing track of the threads in flight? By handing the structuring over to Claude — one file, a few directives, then a gradual split — I turned 500 building-management emails into a queryable knowledge base. Seven steps, from the vague directive to a multi-file system, without ever needing a complex framework.
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.
4 older articles available in the archives.