Turn a Customer’s Requirements List Into a Product-Fit Presentation

By pitch.dogFoundation13 min read20 September 2026

Business

A requirements spreadsheet arrives with the buyer’s own numbering, their own wording, and their own idea of what matters. The fastest way to answer it is to open your product, tick what matches, and build the deck in your own navigation order. That produces a session where the buyer can’t find their own row numbers and can’t see the two lines that would change the purchase.

The workable alternative has five moves. Keep the buyer’s criteria exactly as written, including their identifiers and their stated importance. Group those criteria into a sequence of work the buyer recognises, and carry the identifiers into the grouping so nothing becomes unfindable. Label each item with the kind of fit it actually is. Hand the genuinely arguable equivalences back to the person who wrote the requirement. Close on what is still open rather than on a coverage percentage.

That is a presentation, not a checkmark column. It is also the only version in which the buyer can audit you.

Preserve the customer’s criteria before reorganizing them

Before you can reorganise anything, you need something stable to reorganise. That is the buyer’s list, in the buyer’s words.

Here is the fictional example I’ll use through the rest of this piece. It is invented teaching material, not a real buyer, product, or commitment: a service desk at a fictional facilities company, Meridian Facilities Group, sends four requirements from a longer excerpt.

Service desk requirements — excerpt (fictional)

SR-01 — Record an incident with reporter, category, and time of first contact. Mandatory.

SR-02 — Assign ownership to a named person at triage. Mandatory.

SR-03 — Export a monthly report of incidents by category and resolution time, in the layout shown in Appendix B. Mandatory.

SR-04 — Show the asset record from Atlas, our asset register, on the incident screen. Mandatory.

Four rows, four identifiers, one attachment. Everything else in this article happens on top of that block.

The temptation is to improve it. “Export a monthly report … in the layout shown in Appendix B” becomes “Advanced reporting and analytics.” “Assign ownership to a named person at triage” becomes “Intelligent routing.” Both slides are true in a general sense and neither answers the row. The buyer asked for a named person; routing to a team queue is a different arrangement, and if you show it under SR-02 without saying so, you have quietly downgraded a requirement by renaming it.

Two rules keep this honest. First, keep the identifier attached to every appearance of the requirement, including later slides and the closing summary. Second, keep the original wording somewhere visible on the slide — as a quoted line under your headline, or in a narrow column beside it. Your headline can be clearer than theirs. It cannot replace theirs.

Importance labels and evaluation notes get the same treatment. If the excerpt says mandatory, keep mandatory. If it says preferred, keep preferred. If it says nothing, don’t supply a category on the buyer’s behalf; ask. The one exception is when the buyer’s own materials do distinguish, and you are simply preserving a distinction they made. An inconvenient “must” is not yours to soften.

There is a subtler erasure. If the product happens to satisfy in one button what they wrote as two rows, don’t merge the rows. If the product needs four steps for one of their rows, don’t split it. The count of their requirement items is part of what they are evaluating.

Group the criteria into a recognizable customer task

A list of four rows is not a presentation. But the grouping has to come from the buyer’s work, not from your product’s menus.

The test is simple: can the buyer walk your deck from “a user reports a problem” to “the monthly pack goes out,” and find each of their obligations on the way? If instead they have to translate between Tickets / Queues / Reports / Settings and their own Monday morning, the deck is a tour of your software.

For the fictional example, the four rows happen to line up along the buyer’s own sequence:

Intake — SR-01
Triage and ownership — SR-02
Handling, with asset context — SR-04
Monthly review — SR-03

Two things are doing work in that structure. First, the identifiers travel with it, so a buyer holding the spreadsheet can follow along and see when you skip a row. Second, the grouping makes a relationship visible that a flat table hides: SR-04 sits inside handling, which means anything you say about it delays or changes the flow around it.

Say why you grouped it this way. A one-line rationale under each heading — “these are the two things that must happen before anyone owns the ticket” — lets the buyer audit your logic instead of taking it on trust. It also gives them an easy place to say “actually, ownership happens after the asset check.” That correction is worth more than a tidy slide.

Grouping fails in one direction in particular: it can hide an exception. If SR-04 gets folded into the handling section and then never mentioned again, the deck implies it was handled. An exception belongs in the flow, marked as an exception, and repeated in the closing summary.

Not every requirements list has a workflow hiding in it. If the excerpt is a list of security clauses, contract terms, or licensing conditions, forcing them into a four-step journey invents a process the buyer doesn’t run. In that case, group by the buyer’s own categories and skip the journey. The grouping exists to help them understand related items together; if it doesn’t, a faithful table is better.

State the kind of fit, not a decorative checkmark

This is where most of the risk lives, because a checkmark is a single symbol that can mean six different things.

Use distinct states, and use them in the buyer’s vocabulary rather than your product’s:

Current capability. Available in the product as it stands, for a customer like this one. For SR-01 and SR-02, the evidence is a live demonstration of that exact step — recording an incident with those fields, assigning a named owner at triage — plus a documentation link. Not a screenshot of an adjacent screen.

Supported configuration. The product can do it, after someone builds or changes something. SR-03 is the case here: the product exports incidents by category and resolution time, and the Appendix B layout requires a mapping built by an implementation team. Say who does that work and when it lands. If you don’t know the date yet, say you don’t know the date yet; that is a better answer than “shortly after onboarding.”

Defined external work. The buyer or a third party has to do something. If the Atlas assessment later comes back positive, Meridian’s own team has to expose a read endpoint before anything appears on the incident screen. That is real, it is on their schedule, and it is not a product feature.

Proposed future development. It’s on the roadmap. It is not a checkmark. A roadmap item can move, and a demo can be given on a build that includes unreleased work — or a module the buyer hasn’t bought. Neither is available.

Unmet. The product can’t do it, and no amount of configuration changes that.

Then there is a sixth state that isn’t a fit category at all: not yet assessed. SR-04 is in exactly that position in this example. The product has an API; nobody has tested whether the Atlas record can be retrieved and shown on the incident screen, or what that would take. “Possible” is not a state. Neither is “we have an API.” Those describe the seller’s side of a question the buyer asked about an outcome. Put “not yet assessed” in the deck as its own clearly marked row, with the name of the person who will assess it and a date. The buyer can work with that. They can’t work with a green tick they later discover meant probably.

Attach evidence to each state, and match the evidence to the claim. A demonstration proves a current capability. A written estimate from the implementation lead is the right evidence for configuration, and a demo is not. For the unassessed item, the evidence is an open action, and the deck should show it as one.

This is where the seller-led alternative goes wrong, and it goes wrong attractively. The demo opens on dashboards, suggested resolutions, a mobile app, a chat integration. The final slide says Requirements coverage: 4/4 ✓. All four of Meridian’s rows are technically mentioned. SR-03 appears as a report in the product’s default layout — not Appendix B. SR-04 appears as a line on an architecture diagram labelled API — flexible. The buyer leaves with the impression that all four are handled, and two questions that could decide the purchase have been buried: who builds the Appendix B mapping, and whether Atlas works at all.

Run the arithmetic honestly. At the moment of the meeting, the count is not four covered. It is two available today, one conditional on configuration, one unknown. Written that way, the buyer can go and close the two open items. Written as 4/4, the closing conversation happens after the contract, when the schedule is already committed.

Return disputed equivalence to the buyer

Some of the gaps have more than one possible answer, and those are not yours to settle.

Take SR-03. There are at least three routes to a monthly report, and they are not the same thing:

The implementation team maps Appendix B into a scheduled export. Configuration work on the seller’s side; after that it runs automatically.
Meridian’s own analyst builds the layout in the product’s report builder and saves it as a view. No seller work; the analyst owns it; the output is a view someone opens rather than a file delivered to an inbox.
Someone exports the default CSV each month and reformats it in a spreadsheet. It works today. It also adds a recurring manual step, and if that person is away the report is late.

Each of those accomplishes the request differently, and each changes who does the work, when, and what comes out the other end. That is what you show: the alternative, and what it changes in effort, process, and output. What you don’t do is announce that the buyer will accept the third one, or that a saved view is “effectively” the Appendix B export.

The person to ask is the person who wrote Appendix B. Not the procurement lead, not the programme sponsor, not whoever is in the room. Requirements have owners, and the owner of SR-03 is whoever drew that layout and will be judged on the monthly pack. Same for SR-04: the asset manager, not the service desk manager, is likely to care whether the incident screen shows a validated asset record or a text field an agent typed by hand.

Workarounds deserve their own honest sentence. If the fallback for SR-04 is “the agent copies the asset ID into a custom field and opens Atlas in another tab,” show what that changes: a manual step on every incident, no validation that the ID exists, and no link from the incident to the asset record. It might be entirely acceptable at Meridian’s ticket volume. That is a judgment for the people doing the work, and it is theirs to make in writing.

One formal reference point is worth keeping in view, with its limits stated. The UK’s Procurement Act 2023 guidance on assessing competitive tenders — the procure-phase document updated 17 August 2026 — connects assessment to the criteria the buyer specified and to an assessment methodology the buyer communicated. That is UK public-procurement context, and it is the only formal reference I’m resting on here. It does not establish a rule for US commercial sales, and it certainly does not mean an informal presentation can change published criteria. What it supports is narrower and more useful: in a formal procurement, follow the stated process, and treat the buyer’s published criteria and methodology as the frame rather than something your slides can waive.

End with the remaining fit decision

Close on the open items, and make them easy to inspect.

A closing summary that works has three parts. One: the workflow, with the four identifiers and their labels — SR-01 current, SR-02 current, SR-03 configuration, SR-04 not yet assessed. Two: what is still open, with names and dates attached. For SR-03, that’s the configuration estimate and the implementation owner. For SR-04, it’s the assessment itself and whatever Meridian has to build if the answer is yes. Three: who decides each one, so the next conversation has a scheduled home.

Then leave the register accessible behind the presentation. A spreadsheet with the buyer’s own rows, an added column for the fit state, and a reference to the slide or evidence for each claim is more persuasive than any screenshot, because it lets the buyer check. Selected screenshots invite the reader to infer completeness. A register shows them what completeness actually looks like.

The deliverable is not a deck in which every row became a positive answer. It is a deck from which a buyer can say, precisely: this one is supported, that one is conditional on work with a named owner, this one is an external dependency on our side, and this one we still can’t call. If your presentation can’t produce that sentence in the room, the buyer will produce one of their own — usually the assumption that the checkmarks meant today.

Frequently asked questions

Because the buyer can no longer find their own row numbers and may miss the two lines that would change the purchase. The workable alternative is to keep the buyer's criteria exactly as written, including identifiers and stated importance; group them into a sequence of work the buyer recognises while carrying identifiers into the grouping; label each item with the kind of fit it actually is; hand genuinely arguable equivalences back to the person who wrote the requirement; and close on what is still open rather than on a coverage percentage.

What does it mean to state the kind of fit instead of using a decorative checkmark?

A checkmark can mean several different things, so the article recommends distinct states in the buyer's vocabulary: current capability, supported configuration, defined external work, proposed future development, unmet, and not yet assessed. Evidence must match the claim: a live demonstration proves current capability; a written estimate from the implementation lead fits configuration; an unassessed item should be shown as an open action with an owner and date. 'Possible' and 'we have an API' are not fit states.

How should disputed equivalence, such as the report layout requirement, be handled?

Show the alternative routes and what each changes in effort, process, and output. For the fictional SR-03, that could include implementation mapping, the customer's analyst building a saved view, or exporting a default CSV and reformatting it manually. Do not announce that the buyer will accept one route, or that a saved view is effectively the requested Appendix B export. Ask the person who wrote the requirement, since requirements have owners.

What should a closing summary contain?

It should have three parts: the workflow with the buyer's identifiers and fit labels; what is still open, with names and dates attached; and who decides each open item so the next conversation has a scheduled home. The article also recommends leaving an accessible register behind the presentation, using the buyer's own rows, an added fit-state column, and a reference to the slide or evidence for each claim.

What formal reference does the article rely on, and what are its limits?

It cites UK Procurement Act 2023 guidance on assessing competitive tenders, identified as the procure-phase document updated 17 August 2026, which connects assessment to the criteria the buyer specified and to an assessment methodology the buyer communicated. The article states this is UK public-procurement context and the only formal reference it rests on. It does not establish a rule for US commercial sales, and it does not mean an informal presentation can change published criteria.