Instrumentation from Day One

The Missing Week

Three agencies try the client-digest pilot. All three create accounts. Two upload an ad-platform export. Both receive a generated digest. One account manager edits the explanation, sends it to a client, and comes back the following Monday. The other disappears.

If the product records only signups and page views, those accounts look almost alike. If the founder relies on memory, the friendlier customer may look healthier. Yet the useful questions begin after signup: Where did each agency stop? Did the product fail, or did the output fail to earn trust? Did either agency complete the weekly job without founder help? Which event should prompt a conversation?

The data model in the previous chapter taught the product what an agency, client, source export, digest, and delivery are. Instrumentation gives those objects a history. It should preserve enough of that history to change the founder’s next product, onboarding, support, sales, or pricing decision—and little else.

Begin with a Decision, Not a Click

It is easy to instrument an interface because the interface is visible. A founder can record page views, button presses, form submissions, and time on screen before deciding what any of them mean. The resulting dashboard moves, but the product’s central promise remains hidden.

Begin instead with a decision you expect evidence to change. For the agency pilot, the first decision might be whether to improve import reliability, improve digest quality, or narrow the target segment. The product must therefore reveal whether an intended agency arrived, began the workflow, received a candidate digest, trusted it enough to send, repeated the job at its weekly cadence, and needed founder intervention along the way.

That sequence separates several ideas that are often collapsed:

• Arrival means a person or account from a known source and segment entered the product.
• Activation means the account completed the first meaningful setup or workflow step. It is not automatically a signup.
• Value means the product produced the promised outcome strongly enough to affect the customer’s work.
• Retention means the customer returned for that outcome at the product’s natural cadence.
• Pull appears when the account pays, expands, invites, shares, or refers without being pushed through every step.
• Churn risk appears when a previously valuable workflow is abandoned, downgraded, cancelled, or repeatedly fails.

These are product claims before they are metrics. Instrumentation makes the claims inspectable.

Write the Smallest Event Contract

An event should name a durable change in the customer’s work, not a gesture in the current interface. clicked_primary_button expires when the button moves. source_export_accepted survives a redesign because it describes what the system accepted. digest_delivery_accepted describes a stronger fact than send_clicked, although it still does not prove the client read or valued the message.

The founder gives each event a compact contract:

• a stable name in product language;
• the actor and account responsible for it;
• the product object it concerns;
• the time it occurred;
• the result and any decision-relevant properties;
• the fact the event proves—and the fact it does not;
• the decision that could change because of it.

For example, the delivery event might be emitted only after the delivery provider confirms acceptance:

{
  "event": "digest_delivery_accepted",
  "occurred_at": "2026-07-07T08:42:11Z",
  "account_id": "agency_018",
  "user_id": "user_204",
  "actor_role": "account_manager",
  "client_id": "client_073",
  "digest_id": "digest_661",
  "delivery_id": "delivery_992",
  "segment": "small_marketing_agency",
  "acquisition_source": "founder_outreach",
  "channel": "email",
  "result": "accepted"
}

The event preserves identifiers and categories, not the client’s name, the digest body, or the recipient’s email address. It proves that an account manager trusted a particular digest enough to put it into the delivery path and that the provider accepted it. It does not prove that the client opened, understood, or acted on it. That boundary belongs in the definition; otherwise a convenient event slowly becomes a false claim about value.

Emit consequential events from the point that knows the outcome. A browser can report that a user attempted an upload. The server or background job should report whether the export was accepted, whether generation completed, and which account and client owned the work. Billing events should follow the product’s reconciled billing state, not merely a visit to checkout. A retry should not turn one customer action into three apparent successes.

Let One Workflow Choose the Taxonomy

The agency product does not need an event for every screen. Its day-one taxonomy can follow one digest from market arrival to repeat use:

1. account_created records acquisition source, target segment, and creator role.
2. source_export_accepted shows that the account began the real workflow without an import failure.
3. digest_generated records a candidate output, its generation result, and duration.
4. digest_reviewed shows that a person inspected the candidate and records whether editing was required.
5. digest_delivery_accepted records the first strong value proxy: the work entered a real client communication.
6. teammate_invited records internal pull and the role being invited.
7. subscription_started records the paying account, plan, and billing owner.
8. subscription_renewed records continued payment after the account has had another opportunity to receive value.
9. subscription_cancelled records churn after any value previously reached.
10. referral_submitted records explicit spread and the referred segment.
11. workflow_failed records the step, reason category, and retry outcome.
12. founder_intervention_recorded records support or manual work required to move the account forward.

Twelve is a useful constraint, not a law. A developer tool may need first_production_request_succeeded; a marketplace may need both sides of a completed transaction; a collaboration product may treat an accepted invitation as activation. The taxonomy is correct when it represents the product’s actual promise and remains small enough for its owner to inspect.

Notice what the list excludes. An email-open event is unreliable and may add privacy cost without changing the next decision. A generic report_viewed event cannot distinguish the founder checking a draft from an account manager reviewing it. digest_generated is not called value merely because the software finished. Stronger claims require stronger evidence.

Preserve Identity Where Value Belongs

The first account manager is not the whole customer. Another employee may upload the export, the owner may pay, and the client may receive the digest. If every event is grouped only by user_id, the product can look inactive even while the account adopts it—or healthy because one enthusiastic operator repeats work the buyer will not renew.

Each consequential event should attach to the smallest set of stable identifiers needed to reconstruct the product story. For this pilot, that means account, acting user and role, client, and the relevant export, digest, or delivery. Acquisition source and segment belong on the account or on an event snapshot whose historical meaning will not drift. Billing state belongs to the account, even when one user initiated checkout.

Segment only when two groups would lead to different action. The founder may reasonably compare small agencies with freelance consultants, or founder-led onboarding with partner referrals. Twenty company attributes across ten accounts create empty categories, not insight. Preserve the distinctions that can change the product thesis, onboarding path, sales motion, or pricing; leave curiosity unmodeled.

Follow the Broken Branch

Return to the agency that generated a digest and vanished. An activity chart says the account became inactive. A workflow trace can tell a different story:

source_export_accepted → digest_generated → digest_reviewed → workflow_failed

The failure occurred during delivery because the account manager lacked permission to use the configured sender address. The account did not reject the value proposition; the product blocked the value moment. That distinction changes the next build.

Failure events should sit beside the workflow they interrupt. Preserve a bounded reason category, the account and object, whether a retry succeeded, and whether help was required. Do not pour exception messages, file contents, tokens, or arbitrary customer text into analytics. Detailed diagnostic logs may exist elsewhere under stricter access and retention, linked by a safe correlation identifier.

Support and manual work complete the trace. If the founder repairs an import, rewrites an output, changes a database record, or walks the user through delivery, the product has not completed that step alone. Record the intervention, its workflow step, a short reason category, and the founder time it consumed. Hidden labor can make activation and retention look better while the business becomes less operable.

A useful burden view might reveal that four of six agencies delivered a digest, but three required manual file repair and two required forty minutes of editing help. That is better evidence than a clean activation percentage. It tells the founder that the workflow has demand and also that it is not yet a product one person can scale.

Read a Cohort as a Story

Totals erase sequence. Thirty created accounts accumulated over six months may look encouraging even if none of the last ten reached value. Cohorts keep the beginning and outcome attached.

Group accounts by a meaningful starting point—often the week they created an account or first attempted the core workflow—then ask how many reached each consequential event. For the first pilot cohort, the founder might see five intended agencies arrive, four accept an export, three generate a digest, two reach delivery acceptance, and one repeat the cycle the following week. The numbers are small enough to name every account. That is a strength at this stage: the aggregate reveals where to look, while the underlying accounts preserve the context needed for a conversation.

Retention must use the product’s natural cadence. A daily return metric is nonsense for a monthly close product. A weekly digest should be measured by eligible weekly cycles, not generic sessions. An account that sends one digest every Monday may be deeply retained while appearing inactive on six days of the week.

Define eligibility carefully. An account that signed up yesterday has not yet failed weekly retention. An annual renewal cannot be inferred from a two-week pilot. Cohort denominators should include only accounts that had the opportunity to perform the behavior being measured.

Build a One-Screen Decision Board

The day-one dashboard is not a miniature executive suite. It is a board for deciding what the founder should investigate or change next. Keep the same customer path visible from left to right:

• Arrival: new users and accounts by source, intended segment, and role.
• Activation: accounts reaching the first meaningful workflow step, with time to activation and founder help visible.
• Value: accounts reaching the strongest defensible value event, not merely a technical completion.
• Return: eligible cohorts repeating the core workflow at its natural cadence.
• Payment and pull: trials, paid accounts, renewals, cancellations, upgrades, invites, shares, and referrals connected to the accounts that received value.
• Failure and burden: blocked workflows, error categories, support requests, manual interventions, and time to resolution.

Each block should lead to a question. If intended agencies arrive but cannot accept an export, inspect setup and import failures. If digests are generated but not delivered, talk to the account managers about quality, trust, and workflow fit. If delivery and repeat use appear but payment stalls, investigate buyer identity, pricing, and purchasing friction. If apparent retention depends on founder intervention, fix or narrow the workflow before celebrating it.

The board should link back to accounts and event traces. A percentage without inspectable cases encourages storytelling. A raw event stream without a cohort view hides the shape of the problem. The founder needs both levels and no more ceremony than that.

Use Data to Aim the Conversation

Instrumentation can show that behavior stopped after review. It cannot reveal by itself that the account manager feared sending an automated explanation to an important client, that the agency bills for the manual work being removed, or that the buyer will not connect a production ad account during a trial.

Turn observed behavior into specific interview triggers:

• An intended account arrives but never accepts an export: ask what made setup unsafe or impractical.
• A digest is generated but never delivered: ask what had to change before it felt client-ready.
• One cycle succeeds but the next eligible cycle does not happen: ask how the work was completed instead.
• A paying account repeatedly requests help: ask which part of the promise still depends on the founder.
• A user invites a teammate or refers another agency: ask what became important enough to share.

The event narrows the question; the conversation supplies motive, constraint, and alternative. Neither is a substitute for the other.

Keep the Evidence Trustworthy

A small analytics system can become unreliable quickly. Event names drift, required properties disappear, client and server events double-count the same action, test accounts contaminate cohorts, and old definitions survive after the product changes.

Keep one canonical event file or document. Define required properties and validate them where events are emitted. Deliberately version, split, or retire events rather than silently changing their meaning. Mark test and founder accounts. Annotate material onboarding, pricing, and product changes so a discontinuity has context. Periodically trace one real account from product records to events to dashboard and confirm that the story agrees.

Data minimization is part of this discipline. For every property, ask whether it helps deliver value, support the user, reconcile billing, operate safely, or make a decision. Prefer identifiers, counts, statuses, duration bands, and reason categories over names, documents, free text, raw prompts, email addresses, or customer content. Know which analytics, logging, error, support, and billing systems receive the data. Know how an account can be excluded or removed and where retention limits prevent immediate deletion.

Instrumentation creates a second representation of customer behavior. If the founder cannot explain what it contains and where it goes, the product has gained memory at the cost of trust.

Prepare the One-Page Evidence Plan

Before the next pilot account arrives, write one page that another careful engineer could implement without guessing. Include:

• the customer, painful workflow, promised outcome, and natural cadence;
• the activation event and the strongest defensible value event;
• no more than twelve day-one events, each with actor, object, required properties, proof boundary, and decision use;
• the user, account, role, segment, source, billing, and core-object identifiers genuinely needed;
• the failure, support, and manual-intervention signals that can corrupt the experiment;
• the cohort definition and eligibility rule for repeat use;
• the six dashboard blocks and the question attached to each;
• the behaviors that trigger a follow-up conversation;
• the sensitive data deliberately excluded, the tools receiving event data, and the deletion or opt-out path.

Then trace the two agency accounts from the opening. Can the plan distinguish the one that delivered and returned from the one blocked by permissions? Can it reveal founder labor? Can it avoid claiming that a generated digest was valuable? Can it point to a decision or a conversation?

The product is instrumented enough when the next customer’s behavior can challenge the founder’s memory without creating another system the founder cannot operate or defend. The next question is what this new memory is allowed to contain, who may see it, and how the product will protect the trust placed in it.