Resources

Field notes on how product gets made.

Essays, studies, and longer pieces on the systems and decisions behind modern product organizations.

01 Interfaces

Voice as a primary interface for product work

For most of software's history, product work has been mediated by typing. Tickets are written, fields are filled, comments are composed. As speech-to-intent systems become reliable enough for production environments, a shift is underway in how product leaders interact with their tooling. We examine the workflows in which voice replaces typing — dictation of tickets, hands-free triage, navigation of large queues during meetings — and the second-order effects on decision capture, latency, and the kinds of work that get recorded at all.

Read
02 Organizational studies

How memory loss compounds in growing product organizations

Product organizations forget. Decisions made in one quarter are re-litigated in the next. Customer requests heard by a CSM in March do not surface during planning in May. Engineers leave, taking the reasoning behind half a year of architectural choices with them. We study the rate at which institutional knowledge decays in growing product orgs, the hidden cost of repeated decisions, and the structural reasons most software stacks accelerate forgetting rather than slow it down.

Read
03 Strategy

Institutional memory in software companies

Across software companies, a small set of organizations have begun treating institutional memory — the durable record of decisions, customer signals, and product reasoning — as a form of operational infrastructure rather than a documentation problem. We look at what changes when the memory of a product organization is structured, queryable, and continuous: how planning meetings shorten, how onboarding compresses, how strategy decisions become harder to reverse without reason. The piece argues that memory, more than tooling or velocity, is the asset that compounds across years.

Read
04 Prioritization

Weighting customer signal by source and authority

Standard prioritization frameworks (RICE, ICE, MoSCoW, WSJF) treat customer signals as broadly equivalent. In practice, product organizations know they are not: a complaint from a top-ten enterprise account behaves differently from a passing comment on a public forum, and a senior engineer flagging architectural risk is not the same input as a marketing request. We examine the frameworks emerging around role- and source-weighted signal, what they capture that flat frameworks miss, and where the practice introduces new failure modes.

Read
05 Infrastructure

Source-agnostic ingestion in product tooling

The first generation of product tooling was defined by integrations: Jira talks to Slack, Productboard talks to Salesforce, feedback widgets push into Zendesk. Each integration is an attempt to bridge two systems with different schemas and different assumptions about provenance. A newer pattern treats ingestion as orthogonal to source — a customer message, a pull request, a voice command, and a Slack thread enter the same intelligence layer and are reasoned about identically. We examine the architectural shift, the trade-offs around losing source-specific affordances, and what becomes possible once provenance is metadata rather than structure.

Read
06 Decision research

What override decisions reveal about a product organization

Every time a product organization overrides a recommendation — whether it comes from a heuristic, a teammate, or an automated system — the override carries information. It encodes which signals that team weighs, which contexts the recommendation missed, and where institutional judgment diverges from default behavior. Most organizations discard this data. We study what becomes visible when override decisions are captured systematically: hidden expertise, prioritization heuristics that no one has written down, and the implicit org chart that emerges from who reverses whom.

Read
07 Engineering & product

Pull requests as product context

Pull requests are typically treated as engineering artifacts: review surfaces, deploy gates, audit trails. They also contain dense product information — what is being built, what is being deferred, what is being rewritten, and what assumptions a team is making about the system. We look at what happens when pull requests are read as product signal rather than engineering output: how roadmap drift becomes visible earlier, how silent technical debt enters the prioritization layer, and how the gap between what teams say they are building and what they are actually shipping closes.

Read