Product Manager Decision Style test

Toward the high end, people tend to look for real user pain before shaping a solution, in places such as support tickets, interviews or usage data, and test internal ideas against what they find. Toward the low end, people tend to start from what colleagues, sales or leadership already believe and check user evidence later. That draws on what the team knows and keeps calls quick, but it can produce a well-built answer to a problem users do not have. The high end has its own cost: when evidence is thin, a decision can wait longer than the team can afford.

Starts from internal views

You tend to begin with what colleagues and leaders already think and check user evidence later, which saves time but can aim the work at a problem few users have.

Before your next product decision, find one piece of user evidence, such as a support ticket or an interview note, that backs it or challenges it.

Depends on the call

You start from user pain on some decisions and from internal opinion on others, so the evidence behind your calls varies from one to the next.

For each product decision you make over the next week, note whether user evidence or an internal view started it, and compare the two lists at the end.

Starts from user pain

You usually want evidence of real user pain before committing to a solution, which keeps the work grounded but can slow a decision when that evidence is hard to get.

On your next decision, set a date to decide with the evidence you have by then, rather than waiting for more.

Toward the high end, people tend to say early what is a must-have, what can wait and what is a no, so the team is not left stalled on an open scope question. Toward the low end, people tend to keep several options alive after priorities are clear. That leaves room to change course as the team learns, but people can be unsure what is in scope. At the high end, the risk is closing an option the product later needs.

Keeps options open

You often leave several options in play once priorities are set, which helps when plans may change but can leave the team guessing what is in scope.

Before you plan your next piece of work, sort its requests into must-have, later and no, and share the three lists with the team.

Closes some options

You make some scope trade-offs visible early, while other options stay open after priorities are clear, so parts of the scope settle later than the rest.

Pick one option that is still open after priorities were set, and decide this week whether it is must-have, later or no.

Draws scope lines early

You usually make scope trade-offs visible before the team gets blocked, which keeps work moving, though an option can close before you have learned enough.

Take one item you have marked as no, and write down what evidence would bring it back.

Toward the high end, people tend to make sure each product decision has someone who owns it, a milestone to aim for and a clear sign of whether it worked. Toward the low end, people tend to trust a good idea to pull the work together, and leave the organising to whoever picks it up. That gives the team room to shape how it is built, but hand-offs can slip when nobody owns them. At the high end, a plan fixed early can leave little room for what the team learns while building.

Leads with the idea

You tend to expect a strong idea to turn into coordinated work on its own, which trusts the team with the how but can leave owners and milestones unclear.

For your next decision, write down one owner, one milestone and one sign that it worked, and share them with the team.

Part idea, part plan

You plan some decisions through to an owner, a milestone and a success signal, and leave others to come together as the work goes.

Pick one piece of work in progress and write down how you will know it has succeeded.

Ties intent to delivery

You usually turn product intent into an owner, a milestone and a success signal, which makes progress easy to follow but can settle the plan before the team has had a say.

Before you set the next milestone, ask the people building it how they would break the work down.