How I work
Everything below is drawn from work that shipped. 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. A practice that appears once is a habit, so I have mostly listed the ones that show up across more than one product, and named where each can be checked.
The sequence
Roughly the same sequence every time, whatever the product is. The last step is the one most often skipped, and it is the one that changes decisions already written down.
Problem identification and motivation
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.
Define the objectives for a solution
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.
Design and development
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.
Demonstration
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.
Evaluation
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.
Communication
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.
Problem identification and motivation
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.
Define the objectives for a solution
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.
Design and development
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.
Demonstration
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.
Evaluation
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.
Communication
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
Three things I hold to
The product is a solution, but the user sustains that solution.
Collect, observe, and work with data.
Collaboration is key to a successful solution development.
Other key practices, drawn from work I shipped
I look for the job already being done somewhere else
Every case study
The strongest signal that something is worth building is people doing it without you. Three separate products I specified began with the same observation, found in three different places: creators using general AI tools to plan what to sell, exporting their contact lists into email platforms, and hosting their communities elsewhere and linking back. The demand was already visible as behaviour. That is a much better starting point than a feature request, because behaviour is expensive and requests are free.
Heuristic evaluation before a spec, in any category that already exists
Every case study
Structured heuristic work on the leading products in a space, before writing anything. Not to copy features, which produces a worse version of somebody else's product. It is to find where a category has already settled a question, so I do not spend invention there, and where every player is still getting something wrong, which is usually the opportunity. I have done it on generative AI interfaces, email platforms and community platforms.
A deferral has to name what would bring it back
Ella · Email CRM
Saying no is easy. Saying "not yet" with no condition attached is how a backlog fills with items nobody will ever revisit. When I deferred an external integration layer, the condition was written next to it: observe real usage and data first. It came back and shipped, on a different surface than originally imagined. When I deferred split testing, the condition was an adoption threshold. Both are in the specifications, in writing, beside the decision.
Irreversible decisions go in front of the person making them
Hubs
The easy way to handle a pricing change that affects existing members is a setting called "grandfather existing members," defaulted on, that nobody consciously sees. I made it a required choice at the moment of the save, showing which members are affected and stating plainly that the choice cannot be edited afterward, then recorded permanently against that change. A decision that cannot be undone should not be reachable by accident.
Where a structure already exists, I do not add a second one
Email CRM · Hubs
A segment can never contain another segment. A paid group inside a community never gets its own membership tiers; it keys off the tiers the community already has. Both decisions cost real expressive range. Both were worth it, because two overlapping structures mean every question about access has to be asked twice and every answer has to reconcile them. Fewer possible states, fewer confusing cases.
I write the cost down, including when it is unfair
Hubs · Email CRM
A leaderboard rule I specified removes points from everyone who commented on a post that later gets reported and taken down, including someone who commented in good faith to flag it. The alternative was building a moderation system instead of a leaderboard. I shipped the simple rule and documented the unfairness as a known limitation, with a plan to raise it for wider input. A flaw named in the document is a decision. The same flaw found later is an oversight.
Separate feedback channels, so I get signal instead of consensus
Hubs
When I released a communities product to a closed cohort, each person had their own direct channel and sent feedback unprompted, without seeing what anyone else had said. Put ten people in a shared room and you get one opinion, because the first confident voice frames the problem and everyone else either agrees or goes quiet. Separate channels cost more to run and produce independent observations, which is the only kind that tells you whether a problem is real or one person's preference.
Pass or fail criteria, not a description of the intent
Ella
For an AI agent I wrote around a hundred and twenty release criteria, each one written so it can only pass or fail, with a subset marked as hard gates that block release on their own. A specification that describes what a feature should feel like cannot be tested. One that states what must be true can be handed to anyone and checked.
On the line between product and engineering: I decide what a system must guarantee. The CTO I work with decides how it is built and owns the architecture. Where a case study describes a technical guarantee, it describes what I asked engineering for, not how they delivered it. I would rather be precise about that boundary than blur it.