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.
An excellent note base isn't enough if the ideas never get absorbed. A flash card isn't a small atomic note: it's a personal pillar of thought, recognised in the heat of the moment by its resonance, tested over time by experience and by new sources. Rare by definition, it holds up what you really want to carry in you.
We pile up tabs, links and quick notes — and never read them again. The problem isn't the amount of information, it's that nothing is ever decided 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.
The same words travel between product, marketing, sales and leadership, and nobody gives them quite the same meaning. A glossary isn't a collection of textbook definitions: it's a tool for collective precision. It pins down the terms that carry decisions, protects the links between notes, and cuts the cost of conversations where everyone defends a different idea with the same vocabulary.
"One idea per note" is the formula everyone knows, and it sends most people in the wrong direction. An atomic note is not a short note. It is a note with a single conceptual centre of gravity. Once you see that difference, it changes how you capture, rephrase, title and link. And in the end, how you write.
A thematic note is the link between a note system and writing. It doesn't pile up everything that touches a subject — it picks an angle and brings several atomic notes together to make a pattern, a tension or a line of argument visible. Not a folder, not an encyclopedia: a temporarily stable view onto a network of thought.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.