Compared with engineering work, the measure of success changes: not what has been shipped but what people started doing differently.
Do now
- I talk to a user without feeding them the answersWhat I take out of the conversation is the problem, not a confirmation of my idea.
- I choose a metric that cannot be gamed without making the product betterI can name where it could be cheated and why that will not work here.
- I explain to the team the reason an idea was turned downA no has an argument behind it rather than a line about what was decided.
- I write the statement of work with the behaviour on errors and on empty statesThe team does not come back asking what happens if the service is unavailable.
Where next
Sideways out of the role
What this step asks of you
I talk to users without feeding them the answers
What I take out of an interview is a description of the problem, not a confirmation of my idea.I choose a metric that cannot be gamed without making the product better
I can explain how my metric is connected to money and where it can be cheated.I prioritise in a way that lets me explain the decision to the team
A refusal has a reason behind it, not a line about what was decided upstairs.I state a problem so that it can be built
The team does not come back asking what to do if the service is unavailable.
Common mistakes
- Collecting wishes and calling it prioritisation: the list grows and no direction appears.
- Asking users what to build: they name a solution, not a problem.
- Measuring success by the volume shipped: the team is busy and the product stands still.
What to learn
- Product, process and peopleProduct ManagementSystems and business analysis