Decision records

What I thought before I knew how it turned out

Four decisions where the reasoning was written down before the result, so the record can disagree with me — and in one of them it does.

I keep these records because retrospective accounts tend to smooth over uncertainty. Writing down reasoning before the outcome is known creates a verifiable baseline that can be checked against what actually happened.

Doximity · August 2016

Defer phone verification

Ship Dialer without verifying that the phone number belonged to the physician using it.

What I knew then: Every user was already a registered, identity-verified Doximity member. Adding an SMS round-trip on top of that would re-prove something the account had already established.
What I wrote at the time: I struck the four SMS-verification screens out of the MVP spec and wrote next to them: “Let's defer verifying the user's phone until version 1.1… We do already have them in as a registered & verified doximity user so that's a pretty good protection layer.”
What happened: Deferring got the product in front of physicians within weeks. The account-level identity held, and nothing replaced that protection layer while I was at Doximity.
What it taught: The reasoning found the layer actually carrying the protection. Re-proving identity at the phone number would have bought a first-run drop-off point and no additional protection. A verification step is worth what it establishes that is not already established.

Two layers that could carry the protection
Option	What it demanded	What became of it
SMS phone verification	Four screens in the MVP spec: a code, a round-trip, and a drop-off point in the first-run flow. Proves the number belongs to the physician — a fact the account already established. The verification path would have taken quarters.	Struck from the MVP; deferred to version 1.1.
Account-level identity	Every caller was already verified by medical email domain, DEA number, a photograph of a license, or fax before reaching Dialer. Cost nothing at first run. Held for as long as I was at Doximity.	Chosen — the layer actually carrying the protection.

Contemporaneous artifact The spec page survives, red strike-through and note intact — Doximity's document, so it is described on the Dialer case study rather than republished. Full case study →

Doximity · April – August 2016

A vendor over Twilio

Launch on a vendor that would set any caller ID without proof of control, rather than on Twilio, which required verification first.

What I knew then: The two routes differed in what had to be proven before a number could be displayed. The physician chose an office number they legitimately controlled, displayed it from their device, and made no clinical decision through the call.
What I wrote at the time: The April proposal names Twilio as “our chief 3rd party vendor” with its pricing. The spec four months later names a different vendor in the server-interaction notes. Both documents survive and show the switch from either side.
What happened: The product launched and physicians used it. Hospital authorization followed in stages: the compliance posture gave IT a documented basis and the EHR integration followed.
What it taught: This is the one that looks worst written down, and it is the one I would defend — but only with the boundary attached. Adoption may precede institutional approval while the risk stays with the person choosing. When the risk is clinical, approval comes first. I did not have that sentence in 2016; I derived it from having made this call.

Two caller-ID routes
Option	What it demanded	What became of it
Twilio	The plan on paper and the legitimate path — named as “our chief 3rd party vendor” in the April proposal, with pricing. Every number had to be proven before it could be displayed, so launch waited on verification.	In the proposal, not in the launch.
A vendor without proof of control	Would set any caller ID immediately. Named in the August spec's server-interaction notes. The risk stayed with the physician, who chose a number they legitimately controlled and made no clinical decision through the call.	Launched on; the route did not change while I was there.

Contemporaneous artifact The April 2016 proposal deck and the August 2016 MVP spec, in the Doximity archive. Full case study →

Transcarent · 2021

One shared infrastructure

Build one shared decision infrastructure for four specialty-care programs instead of duplicating the infrastructure four times.

What I knew then: Surgery, everyday urgent care, Behavioral Health, and Oncology Care had different protocols, benefit structures, and partner integrations, and no shared answer to who was responsible for a case at each step.
What I wrote at the time: Stated at the time as an explicit trade: slower to build, faster to scale. The unified member record and role-based routing carried that constraint from the start.
What happened: Four programs launched on one shared architecture. Routing delays stopped being the primary bottleneck, and the spread between the best and worst performing service lines narrowed.
What it taught: The cost was real and arrived first. Nothing about it was clever — ordinary architectural patience, made survivable by having said out loud, in advance, what it would cost.

One architecture or four
Option	What it demanded	What became of it
A product per program	Four builds, one per specialty, each carrying its own protocols, benefit structures, and partner integrations. Ships the first program soonest. No one has to agree across clinical teams on who owns a case.	The default. Fastest first launch.
One shared decision infrastructure	A unified member record and role-based routing under all four programs. Slower to stand up, and forces four clinical teams to agree on who is responsible for a case at each step.	Chosen — slower to build, faster to scale.

Attested, not documented No design document survives in my archive; the reasoning is my account, and the four programs launching on one architecture is the public part. Full case study →

Andwise · 2024

Wind Andwise down

Wind the company down rather than take the monetization paths that would have funded its growth.

What I knew then: 1,200 physicians and a 700-member community said the user problem was real. Three payer models were open, and only one kept the physician in the customer seat: a direct subscription, whose acquisition cost exceeded its lifetime value. The two that could have funded the next stage — an employer benefit, or referral fees from financial advisors — would each have moved the paying customer away from the physician. The product's entire claim was that it answered to the physician.
What I wrote at the time: The record identifies a broken assumption: enough user value will surface a business model that preserves it. That is the sentence that failed, and it is the one I had never tested.
What happened: The company closed. The user problem it identified is still there and still unserved on those terms.
What it taught: Execution held; the belief failed. I had assumed user value and economic capture would eventually converge. Who pays is part of the architecture, and I should have designed around that question in year one. I discovered it in year two.

Payer models considered
Option	What it demanded	What became of it
Direct physician subscription	User-aligned: the physician pays, the product answers to the physician. CAC exceeded LTV because subscription fatigue among physicians is structural — a $15/month tool competes against email newsletters, free DEA lookup sites, and the EHR's ownPhone directory, all of which cost nothing.	Aligned incentives, unsustainable unit economics.
Hospital or employer benefit	The hospital or employer pays, the product is sold as a benefit. Sales cycle 12+ months; demands reporting on which employees used the benefit, which breaches physician confidentiality. A tool whose premise is answering to the physician cannot survive becoming an HR reporting instrument.	Revenue possible, core premise destroyed.
Advisory or wealth-manager referral	Lucrative per-referral revenue. Converts a fiduciary product into a lead-generation funnel for financial advisors. The physician becomes the product, not the customer. The entire claim — that the tool answers to the person using it — becomes marketing copy rather than architecture.	Highest revenue, antithetical to the fiduciary premise.

Attested, not documented The assumption ledger on the case study; the January 2023 deck predates the decision and does not contain it. Full case study →

When more decisions are made faster and with more machine involvement, the scarce thing stops being the decision and becomes the ability to reconstruct why it was made when someone asks a year later. That reconstruction is only possible if the reasoning was written down while it was still uncertain.