What changes when users can't leave

Course 1 showed that internal users who can't switch hide their problems in workarounds (Users, customers and stakeholders). Here is the full list of what changes for the PM, because each difference changes a method you already know.

You also have an advantage consumer PMs would pay for. Louron Pratt of Mind the Product (2024) describes internal users as "more accessible and captive". You can stand next to them tomorrow morning at the receiving dock. Use it every week.

Internal tools also absorb a lot of engineering. In Retool's 2021 survey of about 650 developers, respondents said they spend more than 30% of their time building internal applications. Retool sells internal-tool software, so treat the figure as a rough signal, but it matches what most operations-heavy companies see: a large share of engineering goes into products that often have no PM at all.

Because use is mandatory, logins tell you almost nothing. Track five numbers instead, the internal tool scorecard:

• Coverage: the share of the work done in the tool from start to finish. For receiving: deliveries received fully in the app, with no paper sheet alongside.
• Time per task: median and p90, from the app's own timestamps, checked with a stopwatch on a visit.
• First-time right: the share of records nobody corrects later. Today about 1 in 12 goods received notes (GRNs) at Mangrove needs a correction.
• Workaround signals: paper pads still ordered, photos in chat groups, side spreadsheets.
• Support load: tickets per 1,000 tasks, and the top five reasons.

Add one survey question each quarter, asked inside the app after the task: "How easy was it to receive deliveries last week?" on a 1 to 5 scale. Watch the trend and read the comments, which matter more than the average.

Map the workflow before you touch the screen

In operations, the screen is rarely the slowest part. Work crosses teams, and time is lost at the handoffs, where work sits in a queue, an inbox or a printer tray. A journey map follows one person (Watching the work). A swimlane map follows one piece of work across every team that touches it, with one lane per team.

1. Pick one unit of work and follow it end to end: one price change, one delivery, one stock transfer.
2. Draw one lane per team or system. Boxes are steps, arrows are handoffs.
3. Write two times for each step. Touch time is when someone works on it. Wait time is when it sits. Get both from timestamps where you can, and from a stopwatch where you can't.
4. Mark rework loops: where work comes back to be fixed.
5. Mark copies: every place data is retyped or re-entered.

Then add it up. In most operations workflows the waits are far longer than the work. That changes which problem you solve.

Here is Mangrove's price change. About 400 shelf labels change in each store every week. A buyer sets a new price on Monday afternoon. The nightly files reach the tills and the store's back-office PC at 00:30, so the till charges the new price from then. The store manager prints the labels when she gets to it, usually mid-morning, and staff swap them on the shop floor through Tuesday and into Wednesday, about 40 seconds of work per label. For about a day the shelf shows one price and the till charges another. A later price check finds about 4% of changed labels still wrong and sends them back to be reprinted.

Reading the map

The map changes the question. Imran's request said "make the label screen faster". The screen accounts for part of 40 seconds. The day of mismatch comes from a timing rule: prices go live at midnight, and labels are printed the next morning. If buying makes price changes effective at 08:00 and the label file arrives the afternoon before, stores can swap labels in the evening and the gap mostly disappears. That is a decision for the head of buying, plus a small change to when a file is sent.

This happens a lot. The biggest lever in an operations workflow is often a rule, a handoff or a schedule owned by another team. Your product work is then a smaller change that makes the new rule easy to follow, such as labels sorted by aisle so a store can swap 400 in one walk.

Value in minutes, errors, money and risk

To compare requests from different departments, put each in the same unit: money per year, with its assumptions written down. Four parts, minus what the change costs to run:

Annual value = time saved + errors avoided + money recovered + risk reduced - new running costs

time saved      = minutes saved per task x tasks per year x cost per minute
errors avoided  = errors avoided per year x cost per error (time to fix + money lost)
money recovered = cash that stops leaking (refunds, overpayments, write-offs)
risk reduced    = chance per year x cost if it happens (audit finding, fine, outage)
new costs       = support, devices, licences, and every second the change adds

Four rules keep the number honest:

• Separate cash from capacity. Time saved becomes cash only if someone stops paying for it: less overtime, fewer festival temps, a hire you don't make. Otherwise it is capacity. Say what the freed time will be used for (more price checks, faster shelf filling). Finance will ask, and a case that calls capacity "savings" loses trust.
• Count the seconds you add. A new mandatory field costs time in every store, every day. Ten extra seconds on 400,000 checkout transactions a day is about 1,100 till hours a day.
• Use the loaded wage. Mangrove store staff cost about $4 an hour. Use your own figure, and the same one for every request.
• Write ranges and a confidence level. One audit or one store visit is 50% confidence. Data from all stores is 80% or more.

For the label problem, the ledger looks like this:

Label swaps: about 400 per store per week x 320 stores = 128,000 a week

Labels sorted by aisle: 40 s down to 25 s per swap = 15 s saved
  128,000 x 15 s = 533 hours a week x $4 = about $2,100 a week
  = about $111,000 a year (capacity: used for daily price checks)

Till mismatches: about 2 per store per day = 640 a day
  staff time: 640 x 3 min = 32 hours a day x $4 = about $47,000 a year (capacity)
  shelf price honoured, about $0.60 lower each:
  640 x $0.60 = $384 a day = about $140,000 a year (cash)

Total: about $298,000 a year, about $140,000 of it cash
Confidence: 80% (mismatch counts from POS refund codes in all stores)

Route first, then score

Prioritisation that survives the meeting built the front door: one form, a weekly triage and a promised reply. For an internal tool, add two things. Route requests by type before scoring, because a large share of what arrives is not product work. And require a process owner.

Requests driven by law, audit or safety get their own lane. They aren't scored for value, because they must happen, but they are still sized, and you still look for the smallest version that satisfies the rule.

The process owner rule: every workflow change needs a named person on the requesting side who will update the SOP, brief the area managers and accept the result. A request without one is not ready. This rule filters out many nice ideas, and it makes the rollout possible later (Change management and adoption), because somebody outside the product team owns the new way of working.

Scoring internal requests

For the requests that reach triage, check strategy fit first, then score each one on value per person-week: annual value from the ledger, times confidence, divided by effort in person-weeks. Effort includes testing, rollout, training and support, as in pm-12. It is RICE with the impact already turned into money, which makes requests from different departments comparable. For scale, an engineer at about $5,000 a month costs roughly $1,150 a person-week.

The table is a starting point for the conversation, the way any score is. The transfer request also fails the process-owner rule, which tells you something before the numbers do.

Saying no to department heads

Department heads are rarely being difficult. Each is measured on something real: loss prevention on shrink, finance on closing the books on time, HR on staffing, store operations on sales per hour. Your answer lands well when it starts from their measure, and when "no" is one of several answers you can give.

1. Yes, scheduled. It ranks. Give the date range and say what it moves back.
2. Yes, smaller. The smallest version that solves most of the problem: a markdown photo only above $20, which covers most of the value at a fraction of the staff time.
3. Yes, if. It needs something from them first: a process owner, data to confirm the problem, a pilot store, a policy decision.
4. Not now. It ranks below the line. Give the reason, the score, the date you will look again, and what new fact would change the answer.
5. Not us. A better route exists: a report from analytics, a configuration change, an SOP change, a bought tool.

And when a request doesn't fit what the product is for, say no plainly and quote the strategy line (Vision, strategy and why now). A vague "maybe later" is worse than a clear no, because the requester plans around it.

How you deliver it matters as much as the answer:

• Talk first, then write. For a senior requester, call or meet, then send the written answer the same day.
• Show the trade-off. Put the queue on the screen: "If this goes first, the price-label fix moves to May. Which matters more to the business this quarter?" A trade-off they can see is easier to accept than a no.
• Escalate to a forum. A monthly operations product council, chaired by the head of store operations with the department heads, the PM and the engineering manager, owns the capacity split (Outcome roadmaps) and settles conflicts with the queue in front of everyone. Escalation then becomes part of the process instead of a threat.
• Same facts for the most senior people. When the managing director asks, fast-track the request through the same form, ask for the problem, and say what it would displace. Seniority changes the speed of the answer. It doesn't change the facts the answer needs.

Shadow IT: read it, then decide its future

Course 1 said to treat shadow IT as free research (pm-03), and Course 2 showed how to read a side spreadsheet like a spec (pm-06). After reading it, decide what happens to it. Ask four questions: does it do a job your product doesn't? Does it hold money, personal or customer data? Do other people make decisions from its numbers? Does it depend on one person?

Keep a short register of the shadow tools you find, with an owner and a decision for each. Every one is a request nobody filed. Some companies go further and give teams approved low-code tools with sign-in, backups and data access built in, so the next spreadsheet starts life somewhere safe. That is a platform decision (pm-37).