Seven years of it, moving from user experience to product management. My take: Best products → understand User's (experiences ✕ problems ✕ current solutions).
Co-founder, Head of Product and Product Manager at Nestuge.
Roughly the same sequence every time, whatever the product is. I adapt Peffers et. al's Design Science Research Methodology (DSRM) to the context of product management to make the rules that guide my decisions.
I first find the problem, then make the case for it. Justifying the value of a solution accomplishes two things: It motivates the team and the user, and it helps to understand the reasoning associated with the team's understanding of the problem. The strongest evidence is the job already being done somewhere else.
Next is to state what the solution has to achieve, and make it falsifiable before we build anything. Objectives can be quantitative or qualitative, and should be inferred rationally from the problem specification. I write targets with evaluation windows into the requirements, so the thing can be judged against what I said rather than against what it turned out to be.
Includes deciding the solution's desired functionality and its architecture, and then creating the actual artifact, drawing on heuristic evaluation of the products that already exist in the category and relevant theory. Every goal and non-goals are documented, including what we give up to achieve them.
Here, I show real people how the solution works, in a bounded way: A closed cohort, a gated tier, or even a beta with review before we finally ship to the public. Narrow enough that a mistake is recoverable, real enough that the problems surface. A separate feedback channel per person, so I get independent signal rather than the first confident opinion.
Compare what happened to the objectives I set, not to a story I would prefer. Volume and shape, acceptance against downstream outcome, where people abandon a flow, what they name unprompted in interviews. Then either iterate back into design or accept the result. This is where written decisions get reversed.
Document every requirement, pass or fail criteria, resolved open questions, and the limitations. A decision or insight nobody can find is one nobody can challenge, and a flaw named in a document is a decision while the same flaw found later is an oversight.
The process is a loop: evaluation can return to design and development, and after communication observation begins again and decisions are revised.
I first find the problem, then make the case for it. Justifying the value of a solution accomplishes two things: It motivates the team and the user, and it helps to understand the reasoning associated with the team's understanding of the problem. The strongest evidence is the job already being done somewhere else.
Next is to state what the solution has to achieve, and make it falsifiable before we build anything. Objectives can be quantitative or qualitative, and should be inferred rationally from the problem specification. I write targets with evaluation windows into the requirements, so the thing can be judged against what I said rather than against what it turned out to be.
Includes deciding the solution's desired functionality and its architecture, and then creating the actual artifact, drawing on heuristic evaluation of the products that already exist in the category and relevant theory. Every goal and non-goals are documented, including what we give up to achieve them.
Here, I show real people how the solution works, in a bounded way: A closed cohort, a gated tier, or even a beta with review before we finally ship to the public. Narrow enough that a mistake is recoverable, real enough that the problems surface. A separate feedback channel per person, so I get independent signal rather than the first confident opinion.
Compare what happened to the objectives I set, not to a story I would prefer. Volume and shape, acceptance against downstream outcome, where people abandon a flow, what they name unprompted in interviews. Then either iterate back into design or accept the result. This is where written decisions get reversed.
Document every requirement, pass or fail criteria, resolved open questions, and the limitations. A decision or insight nobody can find is one nobody can challenge, and a flaw named in a document is a decision while the same flaw found later is an oversight.
then watch, and revise the decision
Saying no is easy when there's reason. But saying "not yet" with no condition attached almost always fills the backlog with tickets nobody will ever revisit. Every deferral I write carries the evidence that would reopen it.
Two ways of organising the same thing means two answers to every question, and then they drift apart. I instead extend a more reasonable existing structure, even when that means saying no to another less reasonable one.
A choice that can't be undone shouldn't be reachable by accident. I stop the action, show who it affects, and record what was decided.
A known flaw named in a document is a decision. The same flaw discovered later is an oversight. Naming it also means nobody has to be convinced when it happens.
Building audience infrastructure for people who don't think in databases
13 August 2026
A contact database with lists, segments and trigger-based email sequences, layered on top of a platform that previously sent one-off welcome and broadcast emails. The hard part was the structure: contacts sit inside lists, segments are carved out of those, and sequences run off both. Creators had to be able to predict what any of it would contain.
Read the case study
Deciding what an AI agent is allowed to do
13 August 2026
An in-product AI agent that builds products with creators through conversation and answers questions from their own account data. I wrote the behavioural contract: how it is experienced, what it may do, what it must ask permission for, and what it must refuse.
Read the case study
Designing access for when payment and permission disagree
MVP 1 October 2025 · Public 18 March 2026
Paid membership communities with tiered access, a members-only resource library, events, paid sub-groups and a leaderboard. The hard part was access: one tier system holding a whole community, and rules that still make sense when a member has paid but has not been approved.
Read the case study