How I think
through product problems.
Frameworks, activation principles, and writing about the connection between users, data, and implementation.
Review what the code means, too.
While reviewing an AI agent’s work, I caught an Android tracking implementation that used -1 for days_since_signup. It had copied an iOS fallback instead of implementing the missing Android field.
On iOS, that fallback covered missing data. On Android, it would have replaced the real value every time. The backend data was available; the implementation needed to read it.
Always review AI-generated code. Check whether it preserves the meaning of the data as well as whether it runs.
The thinking behind the work.
How I investigate, what I look for, and what I’ve learned along the way.
How I investigate product problems
A structured way to connect product goals, user value, evidence, and implementation.
Activation ↗Look beyond completing signup
How I think about first value, meaningful behavior, and the path to an ongoing habit.
Writing ↗Notes from product work
Longer thoughts on engineering, experimentation, analytics, and product decisions.
Focused services ↗When a defined review is useful
Product consultations, experiment reviews, audits, and tracking ownership.
Bring me
the problem.
An app that needs building. A migration that needs someone to own it. Numbers that don’t make sense. A product decision your team can’t resolve. Tell me what’s happening. I’ll tell you whether I’m the right person, how I’d approach it, and what the work would cost.
Email Alex ↗alex@x91tech.com