"Seven years of it, moving from user experience to product management. I believe that the best product decisions are made with the people who will use them, and that the best way to make those decisions is to understand the people first."
Researcher, Product manager and Head of Product 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: after shipping narrow, 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. Saying "not yet" with no condition attached is how a backlog fills with things nobody will ever revisit. Every deferral I write carries the evidence that would reopen it.
Two overlapping structures mean every question has to be asked twice and every answer has to reconcile them. Extending one costs expressive range. It buys a product that can still be reasoned about a year later.
The easy version of a permanent choice is a setting, defaulted on, that nobody consciously sees. I would rather force the decision at the moment it is made, show who it affects, and record the answer.
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.
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: what it may do, what it must ask permission for, and what it must refuse.
Read the case study
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 welcome email. The hard part was making a relational model legible to people who are not analysts.
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