Nobody Wrote Down the User. Find Them Anyways.

A “request for proposal” document (RFP) lands. It is two hundred pages long. It specifies the cloud region, the encryption standard, the identity provider, the retention schedule, the support term. It gives four pages to integration and many more on many more technical limitations and requirements.

Somewhere around page 90, there are two paragraphs about the people who will use the thing. You can't call them. There is usually a written clarification channel where your questions and answers are circulated to every bidder, and the answer comes back from a procurement officer rather than from anyone who does the work. You will not speak to a user or the person who drafted the requirements until after an award. Maybe in four months, maybe never.

You have three weeks to figure out the solution, build a demo, figure out the technical solution, and the commercials.

That's the job. Not gathering requirements. Not talking to users. Build a defensible picture of the people you cannot meet from a document that was not written about them, and be honest about which parts of the picture you actually have while trying to sell the company’s capabilities.

Product management gets redefined every few years, and every time we treat it as a discovery about the true nature of the role, it never was. Each definition was a response to a constraint set, and when the constraints moved (usually because of new tech), the definition moved with it. Underneath all of them sat three quiet assumptions:

• Aggregation: you have many users, patterns are statistical, and confidence comes from volume.
• Access: interviews, tickets, session recordings, and a support queue, a Slack channel, or a WhatsApp channel.
• Persistence: there is one product, and you will still be here next quarter to fix what you got wrong.

The forward deployment paradigm takes all three away at the start:

• One account, not a market.
• No contact before, and rationed contact after.
• A system that becomes somebody else's to run inside of a year.

Two of the three come back partially after you win the award. Access opens up, though never as wide as you'd like. Persistence exists at the account level for a while. Aggregation never comes back on its own. Nothing inside one engagement hands it to you: which is a real problem, and a bigger one than this piece can settle. What follows assumes you're working without it.

Strip the three away and most of the modern toolkit goes with them. What’s left is the load-bearing part: synthesis from a thin signal, prioritization as persuasion rather than arithmetic, and the transfer of judgment as a deliverable.

A practical example

In this next section we introduce a fictitious “land registry” example to illustrate the point practically.

The kind of text you get:

3.4 Registration Workflow.

• The platform shall deliver, as one integrated solution:
  • automated intake validation
  • examiner decision support
  • an applicant self-service portal and document authenticity verification.
• The system shall support returning applications to the submitting party with structured deficiency codes and free-text notes, and shall maintain the full return-and-resubmission history against the original application reference.
• Recommended disposition shall achieve not less than 90% agreement with historical examiner determinations across a retrospective sample. All processing shall occur within national boundaries. Arabic-first, including diacritics and scanned records.
  Read it the way most people do and it’s a scoping document. Four modules, one number, a compliance line. However, if you read it the way a product manager should and it’s full of people. They just aren’t named.

That’s not carelessness. RFPs are drafted by whoever is accountable for the project, and rarely is that the actual business. It’s usually a support function like IT or AI enablement. The users are missing because they were never the authors’ to own.

Every phrase is evidence of something. Rarely of things it describes.

Start with the dullest sentence in the text: resubmission history. You don’t build a history for something that happens once. The word implies multiplicity and enough of to need its own reference structure. What the sentence doesn’t tell you is how often, or whether anyone contests it.

Follow it anyway. A return, one assumes, carries a code and free text. Codes are for reporting. Free text exists because something case-specific needs to be documented by the person using it. There’s a persona that nobody named. Call her registration examiner. A plausible reading of her pain point is: not deciding, which she probably does quickly. Writing it up is the problem. Plausible. Not established. Here’s the same reasoning with its seems showing.

Row three is the one to sit with. Bilingual output, appeal exposure, citing the regulation. None of that is in the paragraph. I brought it from other engagements. It may well be right. It isn't evidence, and calling it evidence is the exact failure this method exists to prevent.

Then the 90% line. Notice what it assumes: that the goal is a system reproducing the determinations examiners already make. Maybe, but it arrives dressed as an acceptance criterion, so it reaches engineers as a target rather than a question. And agreement conceals things: class imbalance, rare catastrophic errors, examiners who disagreed with each other, policy that has since moved or become stale.

One thing this isn't: a bid strategy. A compliant response addresses every module at the standard asked, disposition included. What follows is an implementation sequence inside that scope, subject to sponsor agreement and change control. Sequencing is ours to propose. Scope isn't ours to quietly reduce.

What the sequence rests on

Rank what you have. And be explicit that the criterion isn't volume.

Frequency is not value. One rare error in a legal determination outranks thousands of drafting tasks. A low-volume citizen journey can be mandatory on legal or equity grounds no matter how few people walk it. When your inputs are medium-confidence readings, the criterion that holds up is different: what does being wrong cost, and how fast do we recover?

Sequence by reversibility.

The working version carries more columns than a blog post holds: intended outcome, contractual criticality, error severity, data readiness, adoption burden, a measurable baseline. This is the spine.

Look at what the spine says. Build a drafting assistant for deficiency notices first, with defect detection feeding it. Two things. Neither decides anything. The module the tender leads with: disposition, carrying the headline number. That comes third.

It comes third because the unresolved branches sit under it. That isn't a hedge. It's the rule. Sequence the uncertain thing behind the certain one, so being wrong stays cheap.

And it's a recommendation, not a verdict. The sponsor owns sequencing; they carry accountability we don't. What the derivation changes is the conversation. Instead of competing assertions about what matters, there's a traceable argument with the weak links labelled weak. Disagree with row three and you're disagreeing with something specific.

Two branches stay open

Who is the applicant? An individual owner selling their apartment needs something guided and explanatory, used once in a decade. A brokerage clerk or a developer's conveyancing team (commonly a large share of submissions in registries like this) needs a bulk queue, an API, status at a glance. Two products. Same three words. No amount of reading separates them. It turns on one number nobody published: the share arriving through registered agents.

Is 90% even coherent? If examiners historically disagreed on comparable files, agreement with "historical determinations" is unachievable or meaningless, and the requirement needs renegotiating rather than engineering. You can't know until you measure inter-examiner agreement on a sample.

Both get flagged, not guessed. This is the part I'd most want a client executive to notice. The method doesn't produce a confident answer. It produces a ranked list of things to verify, ordered by how much each one would change.

Then you win

The door opens. Not wide, but wide enough to and settle the things you flagged.

Week one: the number that settles the applicant question, and a sample to test inter-examiner agreement.

Weeks two and three: return-rate data, and thirty real deficiency notices. This is the fastest way to learn whether row three was a good prior or a bad one. Any of it can falsify the sequence. If returns turn out rare and mostly code-only, phase one is wrong, and we say so in week three rather than month five.

Execution

The pressure starts. Demos generate requests. Each one reasonable, each one from someone senior. Within weeks, velocity is indistinguishable from drift.

Part of the answer is unglamorous: somebody unblocks the engineers. Environment access, the corpus, the SME hour, the credential. That's project management, and pretending otherwise is why these roles get conflated.

The part that isn't project management is holding the boundary. "Out of scope" is weak and everyone knows it. The artifact is strong: here's the persona, here's the evidence, here's what it depends on, here's what we'd displace to fit it. Now the argument is about the ranking, not about who's more senior.

Fast iteration only compounds when each cycle tests something you claimed. Otherwise it's motion.

What you leave behind

We say we're not a dev shop. Concretely: we don't hand a working system to an organization that can't decide what it becomes next.

The transfer includes the usual apparatus: evaluation assets, monitoring, runbooks, ownership, decision rights, an exit plan. Its spine is the decision rationale. Who the personas are. What ranked where. Which readings held, which died, which are still open.

A team that runs its own next phase. A team holding only the software is still running the same version in a year, quietly concluding that AI didn't work for them.

The account is not the unit

Somebody has to own this. That sounds obvious until you look at what this is: reading a document for people it doesn't describe, grading your own inferences honestly, sequencing by what it costs to be wrong, and handing over the reasoning at the end rather than just the software.

None of that is project management. Some of it looks like project management, and part of the job genuinely is, which is exactly why the two keep getting confused.

The accountability can sit with a Deployment Lead, a Product Manager, a Post-sales Engineer, or split across all three. What it can't be is assumed. Because the work is invisible right up until it's missing, and by then you've shipped something excellent that solves a problem nobody had.

So name it. And know what you're naming: whoever holds it is doing product management, whatever the title says.

Nobody wrote down the user. Go and find them anyway.