Try a piece of the work · 6 min read

Is product management right for me? Try deciding what not to build

Try a product decision with limited capacity, customer requests and incomplete evidence. Includes a brief, sample memo and a way to assess your reaction.

Written by Nivaan, founder of OffLadder · Last reviewed 10 October 2026 · Sources listed at the foot of this page

Begin with a problem, not a feature list

The UK Government Digital and Data role framework describes product management through user needs, product value, prioritisation and working with multidisciplinary teams. It is one public-sector model of the role, not a universal job description.

The distinction matters because “product manager” can mean different things between employers. Some roles emphasise discovery, others delivery, commercial decisions or a particular technical domain. This exercise samples prioritisation and evidence handling.

Use a document. Allow about ninety minutes. The fictional case deliberately leaves some questions unanswered; that is part of the work, not an invitation to invent more data.

The brief: more organisations should reach first useful use

A small service helps community groups coordinate volunteers. Fifty organisations signed up last month. Thirty completed setup and used the service within seven days; twenty did not. For this exercise, “activated” means creating a rota and having at least one volunteer accept an assignment. The measure is specified so that “active” is not whatever makes a chart look better.

Notes about the twenty incomplete organisations suggest ten were waiting for an administrator's approval, five had not finished setup and five had not invited volunteers. These categories come from support notes, not a rigorous study. Their accuracy needs checking.

The team has five developer-days available for the next small release. Existing proposals are: clearer setup guidance, estimated at two days; an approval-status view with a reminder, three days; calendar integration, five days; and a CSV export, four days. Estimates are preliminary.

The requests do not make the decision for you

Sales says a prospective customer wants calendar integration. A current administrator has requested export. Support thinks better instructions would reduce repetitive questions. A developer believes the approval process is confusing.

Your objective is to improve useful first use for new organisations. It does not follow that every popular request serves that objective. Nor should you ignore a contractual, security or accessibility obligation because it is not aligned with a growth metric. The brief gives no such obligation; you should ask whether one exists.

Write down the decision you are making: which problem deserves the available investigation and development effort now. Keep that narrower than “what should the product become?”

Separate facts, interpretations and proposed solutions

A fact in the practice brief is that thirty of fifty organisations met the defined activation measure. An interpretation is that approval delays are the main cause of non-activation. A proposed solution is a status view with a reminder.

Those three statements are not equivalent. An organisation may appear to be waiting for approval because the administrator is absent, lacks authority or no longer wants the service. A clearer screen may not solve any of those conditions.

Before selecting the feature, propose a small check. Speak with a few relevant users, inspect the support records within authorised access and map what happens at the approval step. Ask what information would distinguish confusion from a genuine organisational delay.

Do not manufacture interview quotations for this exercise. Write the questions you would ask and the evidence you would need.

Make a bounded recommendation

One defensible recommendation is to investigate the approval step first because it appears in half of the incomplete cases, then proceed with the three-day change only if the problem is something the product can address.

That does not mean “ten out of twenty proves the biggest opportunity.” The notes may be incomplete, and a change affecting fewer people could still produce more value. Your recommendation should acknowledge why the evidence is sufficient for a small investigation but insufficient for a large commitment.

Keep developer capacity separate from research time. State who would conduct the investigation, when the decision must be made and whether the three-day implementation estimate still holds afterwards. Do not spend five developer-days twice by forgetting the cost of the work already proposed.

A sample decision memo

I recommend investigating the approval step before committing the release. It appears in ten of the twenty incomplete cases, but the notes do not establish why approval stalled. We should verify the process with affected administrators and support records. If the main barrier is unclear status or an absent reminder, the three-day proposal is a plausible small

change, subject to a revised estimate. If approval is blocked by an organisation's own authority or procurement, we should reconsider. Calendar integration and export are deferred for this release, not rejected permanently. We should confirm that neither is an existing obligation before doing so.

Add a second paragraph about what success would mean. For example, compare the proportion of new organisations reaching the defined activation event and the time required, while also checking support burden and mistaken or unwanted invitations. The particular evaluation design would need more traffic and context than this brief provides.

Decide what could make your recommendation wrong

Suppose interviews reveal that administrators understand the approval process but will not authorise the service until they can export records. That changes the causal story. The apparently unrelated export request may be part of the activation problem.

Or suppose the ten cases all came from one partner campaign whose organisations signed up before they were ready. A product change might address the wrong problem entirely.

Write an explicit reversal condition: “If evidence shows X, I would reconsider Y.” This is not weak conviction. It makes the reasoning inspectable and prevents the first recommendation from becoming something you defend simply because you wrote it.

What would you measure, and what would you refuse to claim? The observed baseline is thirty of fifty organisations, or 60%, meeting the stated measure. A future increase would not automatically prove the feature caused it. Marketing, customer mix, timing and measurement changes could also matter.

For this exercise, propose a feasible comparison and name its limitations. Do not invent a statistical-significance claim or a projected revenue gain. If you do not yet know how to evaluate a change properly, identify that as a learning need.

Also ask whether the metric captures a worthwhile outcome. A rota created solely to trigger activation is not necessarily a useful service. Measures are tools for judging progress, not substitutes for understanding users.

What did the decision feel like? Did you enjoy clarifying the objective? Were you curious about the missing evidence? Did saying no feel uncomfortable but worthwhile, or did you mainly want to generate more ideas? Did you want to talk with users and colleagues, or only work privately on the solution?

A product role may involve substantial influence without direct authority. The experiment cannot reproduce that working relationship, so ask a practitioner how decisions are actually made at their organisation.

Do product managers need to code? Requirements differ. Technical understanding can help you collaborate and judge constraints, but this decision exercise does not require coding. Examine the roles you would actually pursue.

Is this enough for a portfolio? It can become an honest practice case showing assumptions and reasoning. Label it as fictional and include what you would need to validate. It is not evidence of shipping a product or improving a real business metric.

Keep the reasoning, including the change of mind

OffLadder helps you explore directions through small tasks and retain the evidence they produce. Bring this memo to Laddie and discuss which part appealed: research, prioritisation, explaining trade-offs or measuring outcomes. Save it in You, then compare with a project- management or data-analysis experiment through Explore. Find your next direction to test. You do not have to choose a product career because you enjoyed one idea; you can investigate whether you enjoy the decisions around it.