My starting point
For PodTalk, I explored listening to study material as a student use case: turning documents and notes into audio.
MY APPROACH
What is worth building?What will make it work?
I connect product questions with engineering decisions.
QUESTION → BUILD → OBSERVE → RECONSIDER
I look at the need, the existing alternatives and the assumptions I am making. Then I build, release and use what happens next to decide where to go.
USER NEED
ALTERNATIVES
CONSTRAINTS
FEEDBACK
BEHAVIOUR
QUESTION → BUILD → LEARN
NEXT DECISIONRECONSIDER
I start with what
people already do.
Before choosing a solution, I look at the need, the context and the alternatives already available. I want to understand what would make another product worth choosing.
With Save It, I could already save a post, a video or a recipe in its original app. What I was missing was a way to return to those saves across platforms, based on what I felt like doing.
Read the Save It case study
like doing today?
That question led me to organise links around intent, rather than the app they came from.
I make the
assumption explicit.
I can believe in an idea and still be wrong about when someone would choose it.
What challenged it
Conversations about that use case brought negative feedback. They made me question the listening context and the reason to choose audio over an existing way of studying.
The next question
I needed to reconsider who would want this experience and in what situation. Those conversations challenged my assumption; they did not settle the question for the whole market.
AI → SOFTWARE → HUMAN
Product decisions
shape the system.
In Save It, I separated capture from classification: a link can be saved before AI decides where it belongs. I assign each responsibility to the layer that can handle it reliably.
AI LAYER
INTERPRET
- Understand context
- Extract meaning
- Compare evidence
- Generate proposals
Probabilistic judgement
DETERMINISTIC CODE
CONTROL
- Validate outputs
- Enforce permissions
- Route workflow state
- Apply limits and policy
- Reject invalid results
Predictable enforcement
HUMAN REVIEW
DECIDE
- Review ambiguity
- Approve high-impact actions
- Resolve missing context
- Remain accountable
Final responsibility
AI INTERPRETSSOFTWARE CONTROLSHUMANS DECIDE
I use this division where it fits the product. Human involvement can mean correcting a category, reviewing a draft or approving a consequential action.
Release gives me
something to learn from.
I use App Store Connect, Firebase Analytics and BigQuery to investigate what happens after release. I connect the numbers with feedback and the decisions I can actually change.
- Can people complete the main task?
- I look at the steps in the experience and where people leave.
- What brings them back?
- I examine repeat use and whether the product fits a recurring need.
- What should I change next?
- I weigh behaviour, feedback and uncertainty before choosing another feature or experiment.
I treat an observed pattern as a reason to investigate. When I run an experiment, I need a clear question, an appropriate sample and a stopping rule before I can interpret the result.
My approach draws on Alex Cowan's hypothesis-driven development, alongside what I learn from building and publishing my own products.
A WORKING LOOP
How I work
through a product.
These questions guide my work. The depth varies by project, and what I learn can take me back to an earlier decision.
UNDERSTAND
Who needs this, and when?
I start with the person, the situation and the job they are trying to get done.
COMPARE
What do they use today?
I consider existing products, manual workarounds and the option of doing nothing.
QUESTION
What am I assuming?
I make the proposed value explicit and look for a way to examine the most important uncertainty.
BUILD
What makes the experience work?
I connect scope, UX, architecture and delivery, making trade-offs around reliability, cost and effort.
OBSERVE
What happens after release?
I look at feedback and available behavioural data, including where people leave and what they return to.
DECIDE
What should change next?
I use what I learn to prioritise an improvement, revisit the hypothesis or leave a feature out.
I let what I learn
change what I build.
A change in direction can be the most useful outcome of doing the work.
VIEW SELECTED WORK