App 04 of 08

Product Simulator

Think like a product manager: four short scenarios.

Think like a product manager

Illustrative scenarios with invented products, people and figures, not real client situations. A way to show how I think, not an assessment.

01. The Prioritisation Challenge: Five requests. Room for three.

Five requests, a sprint of 10 points, and a goal for the quarter: keep customers, win new customers, grow key accounts.

• Fix a recurring user-facing issue (2 points). Data sometimes fails to sync. Support logs it every week.
• Improve the onboarding experience (3 points). Many new users stop before finishing setup.
• Add a highly requested reporting feature (5 points). The most-requested feature, mostly from larger accounts.
• Introduce a new dashboard (5 points). A new overview screen leadership would like to see. Needs the reporting feature's data layer.
• Improve internal administrative workflows (3 points). Setting up a new account takes the operations team days.

How I'd approach it:

• Keep customers: Fix a recurring user-facing issue, Improve the onboarding experience, Improve internal administrative workflows. The sync issue reaches users every week and is cheap to fix, so it goes first. Onboarding is next: people who never finish setup are the easiest to lose. Admin workflows take the last three points only if support time is the bottleneck; otherwise I'd keep them as buffer.
• Win new customers: Improve the onboarding experience, Fix a recurring user-facing issue, Improve internal administrative workflows. Growth stalls where new users drop out, so onboarding leads. The fix still goes in: it is small, urgent and new users hit it too. Faster account setup helps new customers start sooner, and leaves two points of buffer.
• Grow key accounts: Fix a recurring user-facing issue, Add a highly requested reporting feature, Improve the onboarding experience. The large accounts asked for reporting, so it earns its five points, but the fix still goes first: an expanding customer who keeps hitting a bug won't expand. That fills the sprint exactly, so I'd agree the smallest version of the report that answers their question before committing.

02. The Stakeholder Challenge: Two leaders, two priorities, one roadmap.

Head of Sales: "A custom data export, ready for a prospect's demo in three weeks." Head of Support: "The next sprint for stability fixes. Tickets about failed syncs have doubled this month."

• Prioritise the most senior stakeholder. The demo goes ahead. Support keeps absorbing the failures, and the next disagreement goes straight to whoever has the bigger title. Watch out: Decisions by hierarchy teach everyone to escalate.
• Collect more evidence. The picture sharpens: the demo needs one view of the data, not a full export, and the failures hit about one user in ten. Watch out: Without a deadline for the evidence, it becomes a way to avoid deciding.
• Align the decision with product objectives. With retention as the objective, stability wins on its merits, and Sales can see why. The disagreement becomes about the goal, not the people. Watch out: If the objective is vague, it settles nothing.
• Negotiate a phased solution. Both leaders get something real and a date for the rest. The demo shows a narrower export, agreed in advance. Watch out: Phasing without clear scope leaves two things half-done.

How I'd approach it:

• Evidence first, quickly: A day or two, not a study: what the demo actually needs and how many users the failures reach.
• Let the objective decide: Put both requests against the product's objective with the trade-off visible, so the call is about the goal, not the person.
• Phase where it helps: If both matter, split them: the fix that protects most users, then the smallest slice of the request that meets the deadline.
• Record it and report it: Log the change, what moved and who agreed, the way I run change control in ClickUp, then report progress to both sides.

03. The Delivery Challenge: The release is close. A critical requirement just changed.

Release in ten days. The client's compliance team changes a critical requirement: every exported record must now carry an audit trail. The team has room for about two thirds of the remaining plan.

• Scope: What goes into the release? Options: Everything, plus the change; Add the change, cut lower-priority items; Ship as planned; change in a follow-up.
• Timeline: What happens to the date? Options: Hold the date; Move it by a week, by agreement.
• Quality: How do you test it? Options: Full regression on everything; Risk-based: the change and critical paths in depth; Trim testing to make the date.
• Communication: When do stakeholders hear about it? Options: Now, with options and their cost; Once the plan is certain; At release.
• Release readiness: What decides whether it ships? Options: Acceptance criteria and security checks; The date.

How I'd approach it: I'd add the audit trail and cut lower-priority items to make room, keeping the date if the smaller release still does the job. I'd tell the client now, with the options and their cost, and test where the risk is. The release goes when it meets its acceptance criteria and its security checks pass: it is how I set release dates on AttendEase, where security (VAPT) findings decide readiness.

04. Build Your Roadmap: Sequence a backlog against capacity and dependencies.

A lesson-booking app for a swim school. Pilot at one pool at the end of Now: parents can sign up and book a lesson.

• Parent sign-up (2 points)
• Instructor availability (2 points)
• Book a lesson (3 points), needs Parent sign-up and Instructor availability
• Online payments (3 points), needs Book a lesson
• Lesson reminders (2 points), needs Book a lesson
• Waitlist for full classes (2 points), needs Book a lesson
• Progress reports for parents (3 points), needs Instructor availability
• Revenue analytics (3 points), needs Online payments

How I'd approach it:

• Start from the release goal: The pilot needs sign-up, availability and booking, and nothing else. That is exactly the first phase's capacity, so nothing else goes in.
• Respect dependencies: Payments, reminders and the waitlist all need booking; analytics needs payments. Sequencing follows that chain, not the order requests arrived in.
• Leave room: A phase planned to 100% has no room for what the pilot teaches you. Later is a list of options, not promises.
• Estimate before committing: Feasibility and effort come before a phase is promised: the same way I accepted projects at the R&D unit only after estimating them.