Projects

A 0-to-1 AI product for early-stage founders. A five-person team had stalled on it for two months; when they were reassigned I was told to carry it with AI instead, with fractional support from a UX researcher and an engineer. Leadership wrapped it in June 2026.

Research that made a call it could defend. Six months of desk research had gone in and nobody had spoken to a user. I worked with our research lead on scoping the study and moderated some of the sessions myself. Internal testing had flagged the AI reading as a feedback-giver, not the collaborator the product assumed. I checked that against behavior with a nine-day market test of two positioning variants, with paid traffic I bought and instrumented. Volume missed the thresholds I'd set in advance and the quality signals held, on one channel that couldn't carry a kill, so I recommended a pivot to community-first and said plainly what the test could not support.

Criteria written before the evidence. The market-test result was ambiguous and could have gone either way. I had written the go, pivot and kill criteria twelve days before the test went live, so the call came out as a decision instead of an argument.

A method our sponsor designed for finding where a product could win before anyone builds it. I run the first stage.

Agents fan out, I make the calls they can't. Scoped agents run evidence and competitive scans in parallel. What they can't do is decide what the domain is, which opportunity is worth taking, or whether a candidate is strong enough to move. I set the frame and make those reads.

Testing the product and publishing what it couldn't do. Our scoring feature had never been tested against anything but its own documentation. I ran the same assessment twice, once with a strong submission and once with a deliberately weak one, then added an off-domain case and one with a planted omission. One scorer ranked the weak submission higher. I wrote it up with the limit of my own test stated in the same document: single runs are not a reliability study.

The product definition. Now at its fourth revision with the engineer and the sponsor, defining what's being built, what the first stage produces, and which of two user types carries the harder part of the work.

Worked examples, including one built to fail. The method needed something concrete to be demonstrated from. One example is a deliberate re-run with the product removed, to check whether a result held on its own or only because we already knew the answer we wanted.

Four learning platforms, no agreed way to judge them. They ran across a 20-campus network with real budget behind them. I designed the evaluations, tracking adoption, completion and frequency of use alongside learning outcomes, because usage isn't comprehension. My recommendations were the evidence leadership used to decide what to scale and what to shut off.

A built product, no evidence anyone wanted it. I inherited a product that had already been built for two community colleges, on three assumptions nobody had tested: that students would use it, that it would match them to the resources they needed, and that the institutions would see their own goals met. I ran the pilot across both. None of the three held, most students never logged in, and I recommended a push model instead of one that relies on students coming to it. The product was archived and the capacity went to other work.

Every review of the prototype became an argument about tone, and every argument was two people's preferences with nothing to appeal to. So the first thing I built was not a better prototype. It was something to judge one against.

I mapped the ninety-day experience the AI was going to sit inside, classifying every touchpoint as human-essential, an AI opportunity, or already built. Then I wrote the behavior specification: five guiding principles, seven interaction patterns and five hard boundaries, each grounded in user interviews and peer-feedback documents rather than in anyone's preference.

It was an internal design exercise on an early-stage prototype. Nothing in it was shipped or validated, and the published version is rebuilt as a neutral example. The structure, the method and the reasoning are the work.

The experience map and the specification →

Leadership asked for reporting dashboards. Talking to users showed the ask wasn't the need: the problem was upstream, in how data got entered under deadline. I cut the dashboard and shipped a data-entry tool that saved automatically and worked offline. Input errors fell 30% across 30,000 transactions and task time fell 10%.

Read the full product brief →

I treat my portfolio as a project I run on the same operating model I use for product work. The point is the discipline of maintaining a public surface that reflects how I actually think, on a cadence I can sustain.

An evolving site built with Astro, TailwindCSS, and DaisyUI, deployed through GitHub Actions to a custom domain, with PostHog analytics for visibility into how readers find the work.

Custom components built for specific editorial purposes: a pull-quote treatment for thesis statements, a callout pattern for worked examples, a sticky table of contents with scroll-spy for long-form pages.

Notes that capture what I'm learning at work, in sanitized form, tagged across four categories: methods, experiments, failures and signals. The archive lives at Notes.

Written from the work itself, not as a separate exercise, which is the only reason they get written at all.

A personal intelligence journal for tracking AI and EdTech developments. The discipline is integrating what I read back into the work I'm doing, so reading isn't a separate activity from building.

A capture system that doesn't break flow. A Chrome extension I built triggers a /capture skill in Claude Code. Whatever I'm reading gets captured with metadata, tagged by project, and added to a searchable journal.

A tag taxonomy that ties findings back to specific work. When I'm making a decision on the AI Entrepreneurship Portfolio, I can pull captures tagged with it. When I'm preparing a workshop, I pull training-related captures. The tagging is the glue between reading and doing.

A practice of integration over accumulation. I write up what each capture changes about how I think. The writing is what makes the work stick, and the public version of that writing lives in the Notes.