Back to Work

Product Practice · 2026

Living Fieldbook

A daily practice for product judgment: observe something real, keep it apart from what you think it means, and watch your beliefs change in a living habitat.

Visit Living Fieldbook
Three Living Fieldbook screens over the mineral habitat: today’s mission, the habitat map of beliefs, and a field report set as a codex page.
RoleProduct Manager & Builder
Year2026
CategoryProduct Practice
CapabilitiesProduct strategy, Evidence systems, Interaction design, Frontend engineering, Offline-first web, Privacy design, Accessibility, Performance engineering

Why did our judgment change?

A research repository can hold hundreds of notes and still leave a team unable to answer one question: why did our product judgment change? Capture is not the problem. Observations get mixed with interpretation, interpretations harden into conclusions, and conclusions reach a roadmap with no visible link to the belief they strengthened, weakened, or complicated.

Living Fieldbook is my answer, built as a practice rather than a repository. It asks for one real observation a day, keeps what you saw apart from what you think it means, connects it to a belief, and shows you how that belief changes. It lives at fieldbook.alvn.io and needs no account.

One real observation a day

Each day opens with a field mission from a catalog of 36, across six skills: observation, problem framing, assumption testing, systems thinking, prioritization, and decision review. Most work on any public product, so nobody needs customer access to practice. A mission is one observation, with an upper time limit and an example of what good evidence looks like.

The capture is four short steps. First, what happened, with its source and a context label. The fieldbook reads the observation as you write and flags words that slip into interpretation, such as "seemed" or "confused", and offers to move them to the next step. Second, what it might mean, and how sure you are. Third, which belief it touches, and whether it strengthens, weakens, or complicates it. Fourth, what happens next: investigate further, update your confidence, make a decision, or archive it as insufficient.

Once the ledger holds a few beliefs, the fieldbook starts handing missions back from it. A decision that is due for review always takes the day; otherwise a belief in fog, one that is contested, or one that has gone quiet.

Beliefs that show their state

An assumption’s state is never stored. It is derived from the evidence every time: untested, gathering, leaning supported, leaning weakened, contested, in fog, decided, or retired. The word is always "leaning", never "proven". Fog is the state the product is most careful about: high confidence on thin support.

A decision is recorded against the signals it rests on, with a date to revisit it. When that date comes, closing the loop asks one question: what happened? Confidence keeps a trail, with a reason for each change. Six field-quality prompts sit on every assumption page and never add up to a score.

A habitat that grows from evidence

The world the fieldbook documents is the Mineral Observatory, an original place, and the habitat is a map of your beliefs on its terrain. Each belief is a specimen shaped by its state: a seed in fog, a sprout, a rooted glow, a dimming core, a branch for contested, a core wrapped in fog, a crystal for decided, and a fossil for retired. The eight forms share one mineral body and remain distinct by shape in Field and Study. Each signal is a sprout rooted to the belief it touched. Different kinds of source grow biodiversity, a revisited decision restores its ground, and the headline names what the habitat needs most. A ledger shows the same beliefs as a plain list, grouped by what they need.

Nothing here costs you progress. Contradiction grows a branch. Missing a day grows nothing and loses nothing.

A field report someone else can read

When a line of inquiry is finished, it becomes a field report: the question, the belief, the signals you choose to include, how the belief moved, the decision, and what you would watch next. It is set as a glossed codex page. What you observed is the text, in iron-gall ink; what you made of it is the gloss in rubric, in the margin on a wide screen.

Before anything leaves the device you choose what leaves: the study’s name, where each signal came from, and whether to mask emails, links, phone numbers, and handles. Publishing creates an unlisted address that anyone with the link can read, exactly as previewed. Only the device that published can remove it, and readers can flag one. Any mission can be shared the same way, so one product manager can send another a mission.

Built to be trusted

Your working notes stay in the browser, on your device; only the report snapshot you choose to publish leaves it. There is no account. Settings hold a JSON backup you can restore anywhere, a Markdown export for Notion or Obsidian, and a plain-language privacy page that says only what the code does. The app installs to a home screen and, after one visit, a whole loop works with no connection.

Field and Study show the same terrain by morning and by night. The world follows the clock until you choose one with the dial or in Settings. On a phone, each task fits one column. On a tablet or laptop, vellum pages and glass instruments sit within the habitat, with the beliefs anchored to the terrain. Reduced motion stops the ambient animation.

A report also works on paper. Printing removes the surrounding world and editor, preserves the full folio width, and keeps the evidence and decision readable across A4 and Letter pages. You can print directly while writing and return to the draft afterward.

The October 12 release passed 229 unit tests, 137 browser checks, and all six performance checks on the throttled phone profile, which holds the largest paint and habitat image below 2.5 seconds. The browser suite checks accessibility, touch targets, keyboard focus, and deliberate visual changes. Seven additional print checks passed against production in both worlds at phone, tablet, and laptop widths. The rendered PDFs retained their text and footer. These are automated and visual checks, not evidence of a user outcome.

What I learned building it

The July prototype looked finished and was not: a surface with no studies, no state, and nothing to read back. Finishing it meant choosing a story, then building each chapter end to end before polishing any of them.

Deriving state instead of storing it removed a whole class of bugs and put the rules in one file anyone can argue with. Treating visual parity as a contract made each interface change deliberate, including the later overhaul of the July design. A redaction rule that read dates as phone numbers, a test that depended on whether the day was even, and a published report that lived on in a cache after its author removed it were each caught by writing the test that would have embarrassed me later.

The first measured load on a slow phone took nineteen seconds. The fix was not clever: a 3 MB image became 180 KB, loaded from the page head.

What comes next

The product is ready for its first real study: two weeks of my own, then six to eight sessions with other product managers, asking two questions. Can someone produce a defensible note without being taught the model? Does the report feel more useful than a page of notes? The thesis is still falsifiable, and the findings will be recorded here.