Product Thinking

How I think about building products.

Short essays on the decisions behind the platforms — architecture, search, AI workflows, and the discipline of shipping less.

Search Architecture

Why we standardized search across every page in That's Big Time

Fragmented search kills discovery. When every page has its own filter model, users learn nothing they can reuse. We built a single universal search primitive — same input, same ranking, same entity model — and let every page pass context instead of reinventing the UI. It compounds: every improvement to the core lifts the whole product.

Information Architecture

How we designed a knowledge graph instead of a database hierarchy

Sports don't fit tables. An athlete belongs to a school, a club, a state, a class year, an event, and a story — often at once. A relational hierarchy forces you to pick a parent. A graph lets the truth stay true: entities and relationships, queried from any direction. This unlocked discovery paths we couldn't have hand-coded.

Product Strategy

Why simplicity beats feature overload

Every feature is a tax on the next one. Founders overbuild because it feels like progress. What actually moves the product is removing the three things nobody uses so the one thing that matters becomes obvious. I ship less than I want to, on purpose.

AI Product Design

Designing AI-assisted workflows instead of replacing people

The hard problem isn't the model — it's the workflow around it. Import a roster, verify entities, resolve conflicts, publish. AI compresses the tedious steps; humans keep judgment where it matters. That's the shape of every AI feature I've shipped: acceleration, not automation-for-its-own-sake.

Founder Notes

Lessons from building four platforms with AI

AI-assisted development changed what one operator can ship — but it doesn't change what makes a product good. Clear problem, honest scope, tight feedback loop, and someone who owns the outcome. The stack got faster; the product discipline got more important, not less.

Product Ownership

The product owner as translator

Half the job is turning fuzzy business goals into stories a builder can act on tomorrow morning. The other half is turning what got built back into language a non-technical stakeholder can trust. Neither side sees the translation. That's the point.