Decision records

What I thought before I knew how it turned out

Anyone can narrate a decision after the result is in. These are four where the reasoning was written down first, so the record can disagree with me — and in two of them it does.

I keep these because the alternative is a career told entirely in outcomes, which is the version everybody tells and nobody can check. A decision you can only describe after the fact is indistinguishable from a decision you got lucky on.

The uncomfortable half is the point. Two of the four below record reasoning that turned out to be partly or wholly wrong, and one of those is the decision the product I am best known for was launched on.

Doximity · August 2016

Partly held

Ship Dialer without verifying that the physician owned the phone number they were dialing from.

What I knew then: Every user was already a registered, identity-verified Doximity member — verified by medical email domain, DEA number, a photograph of a license, or fax. Adding an SMS round-trip on top of that would re-prove something the account had already established, and would cost a screen, a code, and a drop-off point in a first-run flow.
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: It was right about the launch and wrong about the destination. Deferring got the product in front of physicians in weeks rather than quarters, and the account-level identity did hold. But an unverified caller ID was never going to survive a hospital security review, and it was replaced by verified telco attestation before the product could be sold into health systems.
Verdict: The reasoning was sound for the thing it was reasoning about — consumer adoption inside the physician's own authority — and silent on the thing that mattered a year later. Being right about the next three months is not the same as being right.

Contemporaneous artifact The spec page survives, red strike-through and note intact. It is reproduced on the Dialer case study. Full case study →

Doximity · April – August 2016

Bounded, then closed

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

What I knew then: Twilio was the plan on paper and the legitimate path; it was also slower, because every number had to be proven before it could be displayed. The alternative would set the caller ID immediately. The identity being set was the physician's own office number, on their own device, at their own choice — something they already legitimately held — and no clinical decision passed 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, so the switch is visible from both sides rather than asserted from one.
What happened: The product launched and physicians used it. Institutional authorization then arrived in the order institutions actually grant it: verified telco attestation replaced the shortcut, the compliance posture gave hospital IT a documented basis, and the EHR integration followed.
Verdict: 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.

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

Transcarent · 2021

Held

Build one shared decision infrastructure for four specialty-care programs instead of four programs that each carried their own.

What I knew then: Surgery, everyday urgent care, Behavioral Health, and Oncology Care had different protocols, benefit structures, and partner integrations. The default was a product per program, which would ship the first one soonest. Shared routing and ownership would take longer to stand up and would force four clinical teams to agree on one model of who owns 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 were designed against that constraint rather than retrofitted onto it.
What happened: Four programs launched on the same architecture. Routing delays stopped being the primary bottleneck, and the spread between the best and worst performing service lines narrowed.
Verdict: The cost was real and arrived first, which is the part that makes this kind of decision hard to hold to. Nothing about it was clever — it was ordinary architectural patience, made survivable by having said out loud, in advance, what it would cost.

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

Andwise · 2024

Failed

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. The routes most likely to finance the next stage — tiered plans, referral fees, urgency tactics — would each have made an employer or a financial institution the paying customer. The product's entire claim was that it answered to the physician.
What I wrote at the time: Recorded as a broken assumption rather than a market outcome: 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.
Verdict: Not a failure of execution — adoption was fine — but of a belief I had held without examining: that user value and economic capture eventually converge. They do not. Who pays is part of the architecture, and I should have been designing against that question in year one rather than discovering it in year two.

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 →

Why this page exists

Every system on this site is built to make somebody answerable before a failure happens rather than after: an escalation path with a named owner, routing tied to clinical accountability, an authority boundary a model cannot cross on its own. It would be strange to argue for that and keep no record of my own decisions.

It is also the practical case for the argument. 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.