A pattern showed up repeatedly across a conference floor. Several companies opened their pitch talking about process discovery, current state mapping and human judgment design. The framing worked. The audience responded, because executives inside complex institutions already understand that mapping how work happens is the prerequisite for deciding what AI should do.
Then the product appeared, and processes had nothing to do with it. The discovery language was the door used to enter the conversation.
This is not usually dishonesty. It is a market where the framing that resonates has moved faster than the products built against it, and the gap between the two is a buyer's problem to detect.
Why the narrative and the product diverge
Three mechanisms, and they operate without anyone intending to mislead.
Positioning follows demand, and building follows positioning at a delay. When a framing starts working in sales conversations, it appears in the deck immediately and in the roadmap eventually. A vendor can be sincere about where they are going and the product in the demo is where they are.
Adjacent capability gets described in the language of the problem. A product that analyzes system logs can be described as revealing how work happens, which is true at one level and does not mean it reaches the part of the work that leaves no log. The description is defensible and the buyer hears something broader.
Demos are built to show the strongest path. Every demo is a rehearsed sequence on prepared data. That is reasonable, and it means the demo demonstrates that the path exists rather than that the capability generalizes.
The consequence is that the usual evaluation method, watching a presentation and reading a feature list, cannot separate the three cases below.
| Case | What the vendor says | What exists | Detectable from a standard demo |
|---|---|---|---|
| Built | We do X, here is X on your scenario | X, generally | Yes |
| Adjacent | We do X, here is a path that produces an X-shaped output | Something near X | Rarely |
| Narrative | We do X, here is a vision and a roadmap | A plan | Sometimes |
Pitch vs product
Four layers of a vendor conversation, by how easy each is to verify
| Layer | Example | Verifiable in the room |
|---|---|---|
| Framing | Process discovery is the prerequisite | Not a claim, it is a position |
| Capability claim | We map how work actually happens | Yes, with the right test |
| Demonstration | A rehearsed path on prepared data | Shows the path exists |
| Generalization | It works this way on your operation | Only with your own input |
The second and fourth layers are where evaluations should spend their time. Most spend it on the first and third.
The five tests
Each one runs inside a scheduled demo and takes a few minutes. The value is in the quality of the answer rather than its content.
1. The unscripted input test
Bring one real case from your own operation, in whatever messy form it exists, and ask them to run it live. Not a dataset, one case.
A built capability handles it or explains precisely why it cannot. An adjacent one produces something plausible that is not quite the thing. A narrative asks to take it away and come back.
2. The source question
Point at any specific element on screen and ask where that came from. Then ask to open the input behind it.
This separates systems that carry provenance from systems that generate an output. A product built to be audited answers in one step. A product that cannot answer this is not usable in any decision that will be challenged internally.
3. The negative case
Ask what their product does not detect, and ask for an example of a finding it would miss.
A vendor with a real product has a clear answer and usually gives it willingly, because the boundary is a design decision they made. A vendor without one describes the limitation as a configuration matter or a roadmap item.
4. The operator question
Ask to speak to someone who has run this on a comparable operation, and ask what surprised them.
The second half of that question is the useful one. Reference calls arranged by a vendor produce positive accounts. Asking what was unexpected produces specifics, and specifics are hard to coach.
5. The replication test
Ask them to produce the same output twice, from a different starting point, on the same input.
Rehearsed demo paths are brittle outside their sequence. A capability that generalizes survives being approached from a different direction, and this is the fastest way to tell a product from a path.
What each test reveals
| Test | Built product | Adjacent capability | Narrative |
|---|---|---|---|
| Unscripted input | Runs, or explains the limit | Plausible, not quite right | Asks for time |
| Source and provenance | One step to the input | Summary, no trace | Not available |
| Negative case | A clear boundary, offered | Framed as configuration | Framed as roadmap |
| Operator surprise | Specific, often unflattering | General satisfaction | No operator available |
| Replication | Holds | Breaks outside the path | Not applicable |
Three of the five rows distinguish built from adjacent, which is the harder and more common distinction. Narrative is usually visible within the first two tests.
Three questions that end the ambiguity
Shorter than the tests, and they work in a first call.
What does your product do, in one sentence, with no reference to outcomes? A built product has a mechanical description: it interviews people, it reads event logs, it observes screens, it parses documents. An answer that only describes benefits is telling you the mechanism is not the thing being sold.
Where does your input come from? Every discovery product has a source, and the source determines the limits. Systems supply events and omit reasons. Observation supplies activity and omits why. Conversation supplies reasoning and depends on participation. A vendor who cannot name their input source in one sentence is describing a category rather than a product.
What is the one thing you do, and what do you decline? Products with a defined scope can answer. The answer also tells you whether the thing you need is the thing they build or an edge of it.
Formal standards exist for this kind of assessment and they are rarely brought into a demo. ISO/IEC 25010 defines a product quality model with characteristics such as functional suitability and reliability, which gives a buyer vocabulary for what is being claimed rather than what is being shown. ISO 21502 treats supplier selection and assurance as practices with their own ownership, separate from delivery, which in practice means the verification should have an owner who is not the person who wants the project to start.
Why specialization is becoming a buying criterion
The pattern has a commercial consequence that is starting to show up in how buyers evaluate. A vendor whose product does one thing can be verified on that thing. A vendor whose narrative spans a category has to be verified across all of it, and the tests above get expensive.
That asymmetry favours clearly bounded products in a way it did not a few years ago. When every pitch opens with the same framing, the question that discriminates is no longer which problem the vendor talks about. It is which problem their product takes as input.
| Buyer question | What it used to reveal | What it reveals now |
|---|---|---|
| What problem do you solve? | The vendor's focus | The current market framing |
| What is your input source? | A technical detail | The actual product boundary |
| What do you decline to do? | Modesty | Whether a scope exists |
Where Horizon fits
Horizon is an AI-powered continuous discovery platform, and process discovery is the only thing it does. That is a scope statement rather than a positioning claim, and it is the kind of statement the tests above are designed to check.
The mechanical answer to the first of the three questions: Horizon interviews the people who perform the work, asynchronously and at the scale of the full population in a function, and builds a record of how that work actually runs. The input source is conversation with the people doing it. That source is what reaches the reasoning behind a step and the exceptions that leave no system record, and it depends on participation, which is the limit that comes with it.
Discovery Cycles run those interviews. The Insights Dashboard holds each finding with traceability to the inputs behind it, which is the answer to the source test: any element can be opened down to the conversation that produced it. The Process Library holds the described process including steps with no system record.
At Mercado Libre, a cycle interviewed 2,000 employees across five countries in four days, reaching 100% of the functions in scope against under 1% under manual sampling, and surfaced more than 600 already overlapping initiatives alongside 24 new ones with 2.3 million dollars in projected savings and 76 full-time equivalents avoided. Coverage figures are the kind of claim a buyer can verify, because a vendor either reached everyone in a function or did not. These numbers describe one engagement and they are evidence rather than a guarantee.
The question worth putting to any vendor, including this one: what is your input source, and can I open any finding on screen down to the thing it came from?
Verification checklist
- Did you bring one real, messy case from your own operation to the demo?
- Did it run live, or was it taken away?
- Can any element on screen be opened down to its source input in one step?
- Did the vendor name something their product does not detect?
- Did they describe their mechanism in one sentence without referring to outcomes?
- Can they name their input source, and do you understand the limit that comes with it?
- Did you speak to an operator and ask what surprised them?
- Did the same output reproduce from a different starting point?
- Is the verification owned by someone other than the project sponsor?
- Does the scope of what they decline match the scope of what you need?
Items 5 and 6 can be run in a first call and will remove a meaningful share of candidates before anyone schedules a demo.
Common mistakes
Evaluating the framing instead of the product. Agreeing with a vendor's view of the problem says nothing about what their product takes as input.
Accepting a demo on prepared data. It demonstrates that the path exists. One real case from your own operation tests whether the capability does.
Treating a feature list as capability. Features describe surface. The input source describes the boundary, and the boundary is what you are buying.
Skipping the negative case. A vendor who cannot name what their product misses either has not defined the scope or will not tell you where it ends.
Taking vendor-arranged references at face value. Ask what surprised the operator. Positive accounts are easy to arrange and specific surprises are not.
Letting the sponsor own the verification. The person who wants the project to start is the wrong person to test whether the capability is real.
Assuming a shared vocabulary means a shared definition. Current state mapping means something different depending on whether the input is a log, a screen recording or a conversation.
FAQ
How do you tell a real product from a pitch narrative?
Bring one real case from your own operation and ask for it to run live, ask where any element on screen came from and to open the input behind it, and ask what the product does not detect. A built capability survives all three. A narrative asks for time on the first.
Why do several vendors describe the same problem?
Because positioning follows demand faster than products do. When a framing starts working in sales conversations it enters the deck immediately and the roadmap later, so a vendor can be sincere about direction while the product in the demo is somewhere else.
What is the single most useful question to ask a vendor?
What is your input source. Every discovery product has one, and it determines the limits: event logs give activity without reasons, screen observation gives behaviour without reasons, conversation gives reasoning and depends on participation. A vendor who cannot answer in one sentence is describing a category.
Is a demo on prepared data a red flag?
No, it is normal and it proves a narrower thing than buyers assume. It shows the path exists. Whether the capability generalizes is tested by running an unscripted case and by asking for the same output to be reproduced from a different starting point.
Who should own vendor verification?
Someone other than the sponsor of the project. The person who wants the work to begin has an interest in the capability being real, which is the wrong incentive for the person checking it. Supplier assurance is treated as a distinct practice with its own ownership for this reason.
The framing is free and the input source is not
When every pitch in a category opens with the same problem statement, agreeing with the problem statement stops being information. What remains is mechanical: what the product takes as input, what that input can and cannot reach, and whether any claim on screen can be traced back to something real.
Those are answerable in a single call, and they will tell a buyer more than a quarter of evaluation meetings.
See it. Fix it. Own it.