· revenue engine
Technographic data can be useful, but it is not a prerequisite for finding software buyers. In many categories the better starting point is the workflow the product improves, because a named platform does not prove that the target problem exists and an unknown stack does not prove that it does not.
The discipline is simple: research observable work, keep technology inference unconfirmed and use discovery to close the gap.
1. Define the workflow conditions
Write the use case as a set of observable conditions:
- the work being done;
- the team responsible;
- the event or complexity that makes change relevant;
- the information or hand-offs involved;
- the product capability required;
- the conditions that make the product unsuitable.
For example, a case-management product may require several teams to receive, assign and audit customer requests. The current system matters later. The first research question is whether that operating job exists.
2. Use a public evidence ladder
Move from stronger evidence to weaker clues.
Level 1: the company describes the workflow
Service pages, help centres, policy documents, procurement notices, annual reports and role descriptions can show how work is organised. Preserve the exact words and date.
Level 2: several sources support the same operating pattern
A service page may describe multi-site delivery while a current vacancy names responsibility for coordinating the same process. Together they support a workflow hypothesis. Neither confirms the software stack.
Level 3: company structure supports further research
Companies House provides free access to company status, registered office, SIC, filing history and officers. It also says the information is not comprehensive and can contain errors or omissions. Use it to confirm identity and basic corporate context, not to infer operational systems.
Level 4: indirect clues
Job adverts, integration pages, public code or browser observations may mention technology. Check the date and provenance. A historical vacancy may describe a retired system; a script on a website may belong to a peripheral tool rather than the core workflow.
Label every stack conclusion as confirmed, reported but not verified, inferred or unknown.
3. Build an account hypothesis
An account hypothesis should answer six questions:
- What workflow is observed?
- Which source supports it?
- Why might the product be relevant?
- What would make it unsuitable?
- Who is likely to own the workflow?
- What must discovery verify?
The hypothesis earns research attention. It does not justify claims about pain, budget, platform or buying intent.
Fictional worked example
Cedar Compliance is fictional. Its website says regional advisers submit client review records to a central quality team. A current operations vacancy includes responsibility for monitoring incomplete reviews across offices. No public source names the system used.
The research record says:
| Field | Entry |
|---|---|
| Observed workflow | Regional submission and central quality review |
| Primary evidence | Fictional service page and vacancy |
| Product relevance | A controlled review workflow may fit |
| Stack status | Unknown |
| Inference | Multiple teams may need shared status visibility |
| Exclusions to test | Existing solution sufficient, regulated requirement unsupported, no change capacity |
| Likely owners | Operations and quality functions |
| Discovery question | How are review status and exceptions managed today? |
The account can enter a discovery queue without a guessed platform. If discovery reveals an incompatible architecture or no meaningful problem, it should be excluded.
4. Do not let stack uncertainty become false personalisation
Avoid statements such as “you are still using spreadsheets” or “your legacy CRM is holding the team back” unless a current, reliable source says so. Instead, reference the observable workflow and ask how it is handled.
This article provides a research method, not live campaign copy. Before any outreach, recheck the source, select a contact by responsibility and apply privacy, channel, suppression and approval controls. The ICO says that using publicly available personal data for B2B marketing still requires UK GDPR compliance and that the rules can differ by channel and subscriber type. Its current B2B page is under review, so operational teams should check the live guidance.
5. Make unknown a managed state
Unknown is useful when it has an owner and next action. Add these fields to the CRM or research record:
- stack status;
- source and source date;
- who will verify it;
- when it matters in qualification;
- what answers would exclude the account.
Do not delay all research until the stack is known. Do not conceal uncertainty to make the record appear complete.
Workflow-first buyer worksheet
| Question | Answer | Source | Confidence | Next check |
|---|---|---|---|---|
| What work is performed? | ||||
| Who owns the workflow? | ||||
| What complexity or trigger is visible? | ||||
| Why could the product fit? | ||||
| What could disqualify it? | ||||
| What is known about the stack? | ||||
| What must discovery verify? |
Final check:
- [ ] Workflow evidence comes before technology inference.
- [ ] Every source has a date and access record.
- [ ] Confirmed facts and inferences are separate.
- [ ] Stack status uses a controlled label.
- [ ] The account has explicit exclusion conditions.
- [ ] The likely buyer is based on responsibility.
- [ ] Discovery has a specific verification question.
- [ ] Privacy, suppression and channel checks are complete.
The software sales lead generation guide covers the broader market-to-hand-off system. To see how Hyper approaches workflow-led research for software companies, visit the software growth page.
Sources and further reading
- Searching the Companies House register · Companies House
- Business-to-business marketing · Information Commissioner’s Office