Nobody Wrote Down the User. Find Them Anyway.

A request for proposal (RFP) lands. It’s two hundred pages long. It specifies the cloud region, the encryption standard, the identity provider, the data retention schedule, and the support term. It devotes four pages to integration, and many more to the dozens of other technical limitations and requirements.

Somewhere around page 90, there are two paragraphs about the people who will use the product. But you can't call them. In fact, you will not speak to a user or the person who drafted the requirements until after an award. Maybe in four months… or maybe never.

So how do you define a solution, build a demo, and settle the technical and commercial details, all in just three weeks?

That's the job of a forward deployed product team. It’s not gathering requirements or talking to users. It’s building a defensible picture of the people you cannot meet, from a document that was not written about them, and being honest about which parts of the picture you actually have while selling your company’s capabilities.

Product management gets redefined every few years, and each time the field treats the new definition as a discovery about the true nature of the role. But it never was. Each definition was a response to a constraint set, and when the constraints changed (usually because of new tech), the definition changed with it.

The most recent definition of product management rests on three key 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 radically changes all three of these assumptions:

• You’re dealing with one account, not a market of users.
• You have little to no contact with the core user before development, and rationed contact after.
• You’re building a system that someone internal to the account will soon have to run on their own.

While access may open up after an award, it’s never as much as you'd like. The account persists for some time. But aggregation will continue to be a challenge; a single engagement can’t tell you if a pattern is true across customers.

Strip these three assumptions away and most of the modern product management toolkit goes with them. What’s left is the part that matters: synthesis from a thin signal, prioritizing your solution design based on the cost of an error, and the transfer of your product judgment as a deliverable.

Read the document for traces of people

The following “land registry” example is fictitious but illustrates the method in practice.

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, and a compliance line. Read it the way a product manager should and it’s full of people. They just aren’t identified.

The authors of the RFP aren’t being careless. RFPs are drafted by whoever is accountable for the project, and that is rarely the business itself. It’s usually a support function such as IT or AI enablement. The users are missing because they were never the authors’ to own.

Every phrase is evidence of something, though rarely of the thing 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, with enough returns to require their 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: the decision is quick, and writing it up is the problem. That reading is plausible, not established. Here’s the same reasoning with its seams showing.

Bilingual output, appeal exposure, citing the regulation. None of that is in the paragraph. It came 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 changed.

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.

Sequence by the cost of being wrong

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

Frequency should not be conflated with 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 you recover?

In other words, sequence by reversibility.

The working table needs more fields than this article can fit (intended outcome, contract priority, error severity, data readiness, adoption burden, and a measurable baseline), but you can see the logic.

The ranking says to build a drafting assistant for deficiency notices first, with defect detection feeding it. Neither of those two things decides anything. The module the RFP leads with, disposition, carries the headline number, and it comes third. It comes third because the unresolved branches sit under it. That is the rule, not a hedge: sequence the uncertain thing behind the certain one, so being wrong stays cheap.

This is 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 labeled weak. Disagree with row three and you're disagreeing with something specific.

Flag ambiguities and consider more than one product branch

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. Those are two different products behind the same three words, and 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 rather than guessed. This is the part most worth a client executive’s attention. 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.

Use the first weeks post-win to test the sequence

You win the RFP. The door opens. Not wide, but wide enough to settle the things you flagged.

In week one, get the number that settles the applicant question and a sample for measuring agreement among examiners.

In weeks two and three, get return-rate data and thirty real deficiency notices. These records will test whether row three was a good prior or a bad one. If returns are rare and rely mostly on codes, phase one is wrong. But now you know that in week three rather than month five.

Fight drift during execution

The pressure builds. Demos generate feature requests. Each one is reasonable and each one comes from someone senior. But within weeks, velocity is indistinguishable from drift.

Part of deployed work is straightforward project management: securing environment access, finding the right dataset, scheduling time with a subject-matter expert, or unblocking credentials.

The product responsibility is different. It is maintaining a clear connection between what the team is building, which user problem it addresses, and what evidence supports the priority.

Simply saying that a request is “out of scope” is rarely persuasive.

A stronger response is:

• Here is the user affected.
• Here is the problem we believe they have.
• Here is the evidence supporting that belief.
• Here is what must also be true for the feature to work.
• Here is what we would delay or remove to build it now.

That turns prioritization into a concrete discussion about users, evidence, risk, and tradeoffs.

Fast iteration only compounds when each iteration tests something the team claimed. Otherwise, it is just motion.

What you leave behind

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.

The goal is a team that can run its own next phase, not a team that holds the same version of the software a year later, 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.