How to turn a software use case into an ideal customer profile

A software use case explains a change in work. An ideal customer profile, or ICP, defines the organisations where that change is valuable, feasible and likely to be owned by someone who can act.

The quickest way to weaken an ICP is to start with labels such as “mid-market field services”. That label describes a market, but it does not tell you which companies have the problem, whether the product fits their workflow or what should exclude an account.

A stronger route starts with one use case and turns each part of it into a testable account condition.

1. Write the use case as a before-and-after job

Use four fields:

1. Starting situation: what happens today?
2. Trigger: what makes the current approach harder to sustain?
3. Changed job: what will users do differently with the product?
4. Acceptance condition: what must be true for the change to count as useful?

Avoid product features at this stage. “Mobile forms with real-time sync” is a capability. “A field engineer records the completed visit once, at the customer site, and operations can act on it” is a job.

Fictional worked example

Imagine RelayField, a fictional product for service businesses. Its use case is:

Regional maintenance companies replace paper visit sheets and end-of-day rekeying with a controlled mobile completion workflow, so operations can see completed work before scheduling the next visit.

The example makes no claim about a real company or product result. Its purpose is to show the method.

2. Convert the use case into five ICP gates

A gate is a condition that must be checked, rather than a flattering description of the customer.

Gate A: the workflow exists

RelayField needs work completed away from a central office. A company with only workshop-based activity fails this gate, even if its sector looks similar.

Evidence might include service-area pages, field engineer vacancies, customer instructions or public descriptions of mobile operations. Treat a single clue as a lead for research, not proof.

Gate B: the friction is plausible

Look for complexity that makes the old workflow costly or fragile: multiple daily visits, compliance evidence, remote teams, scheduling dependencies or hand-offs between field and office staff.

Do not state that a company has a problem unless the company has said so. Record the evidence and the inference separately.

Gate C: the change is feasible

A company may fit the problem but still be a poor prospect now. Check for practical constraints such as workforce access to suitable devices, integration requirements, data controls and the ability to run a pilot.

Gate D: ownership is visible

Name the function that owns the workflow and the function that owns the risk. For RelayField, operations might own completion speed while IT or security reviews access and data handling. The right account with no reachable owner is not yet a usable sales account.

Gate E: no exclusion applies

Exclusions protect focus. RelayField might exclude businesses where:

• all work happens at one fixed site;
• field activity is subcontracted with no operational control;
• the required offline workflow is unsupported;
• a replacement project is publicly ruled out;
• the account is suppressed or has objected to marketing.

ICO guidance says UK GDPR can apply when personal data is processed for B2B marketing, including publicly available personal data. It also distinguishes corporate subscribers from sole traders and some partnerships. Its wider direct marketing guidance says to plan data protection from the start, collect information fairly and respect objections. Research and outreach rules therefore need to be checked before activation, not added at the end.

3. Score evidence, not enthusiasm

Use a simple 0 to 2 scale for each gate:

• 0: evidence contradicts the condition or an exclusion applies
• 1: plausible, but unconfirmed
• 2: supported by a current primary source

Do not invent a universal pass mark. Choose the decision rule that matches your sales capacity and the risk of a false positive. A small team might require confirmed workflow and ownership before an account enters research. A broader discovery programme may keep plausible accounts in a separate queue.

Crucially, store the source, publication date, access date and the exact observation behind every score. If the evidence changes, the score should be easy to revisit.

4. Add the buyer only after the account fits

Job titles vary. Start with responsibility:

• Who is accountable for the workflow?
• Who experiences the operational cost?
• Who owns implementation capacity?
• Who can block the change?

Then find current people in those functions. This reduces the temptation to build an ICP around a convenient contact list.

For a broader explanation of software account research, see Hyper’s guide to software sales lead generation.

Use-case-to-ICP worksheet

Complete one row per use case. Do not combine different workflows into one profile.

Before using the profile, check:

• [ ] The use case describes work, not a list of features.
• [ ] Account facts and researcher inferences are stored separately.
• [ ] Every must-have condition has a possible evidence source.
• [ ] Exclusions are as explicit as inclusion criteria.
• [ ] The buyer is defined by responsibility before title.
• [ ] Suppression, privacy and channel rules have been checked.

A use-case ICP will not reveal every willing buyer. It gives a sales team a defensible reason to investigate an account and a clear reason to stop when the fit is weak.

To compare this worksheet with a research-led software growth approach, see how Hyper works with software companies.

Discuss your growth priorities with Hyper