A capability is not yet a customer use case
A capability describes what the technology can do. A customer use case explains why that capability could matter in a specific situation.
“Detect smaller changes in vibration” is a technical capability. “Help a maintenance team identify deterioration early enough to change a maintenance decision” is closer to a use-case hypothesis.
The second statement gives you something to investigate: who has the problem, what happens today, what outcome could change, what the technology must achieve in the real environment and who would have to trust or act on the result.
Build from the customer situation, not the industry label
For each plausible application, work through the same questions.
Lens · What to explore
- Operating situation: What task, process, decision or event is happening when the capability could matter?
- Problem and consequence: What is difficult today, and what happens if nothing changes?
- Relevant role: Who experiences the problem, owns the outcome or would act on new information?
- Current approach: How is the situation handled today, including workarounds and accepted limitations?
- Capability mechanism: How could the capability change the situation without assuming the whole solution already exists?
- Constraints: What environment, integration, reliability, skills, regulation or organizational conditions could affect adoption?
- Evidence needed: What must real customers, technical tests or market research establish before the use case becomes credible?
The output is a use-case hypothesis, not a market claim.
Compare applications while keeping the capability stable
A technology may support several applications. Compare them with the same underlying capability and the same learning questions.
Ask what problem each application addresses, who needs to act, what the existing alternative is, and which constraints could make adoption difficult.
Do not ask AI-simulated customers to rank industries or choose the commercial winner. One application may appear easier to explain but depend on a weak customer problem. Another may address a more consequential problem but require difficult integration, qualification or workflow change.
Those differences tell you what needs investigation. They do not tell you which market is most attractive.
Example: one sensing capability, two industrial applications
Illustrative example, not a customer result.
An R&D team has developed a non-contact sensing capability that can detect small changes in vibration and movement. Two industrial applications appear plausible.
The first is condition monitoring for rotating equipment. The team explores the situation with maintenance and operations perspectives in a process-manufacturing context. Questions include how deterioration is detected today, who acts on an early warning, where the sensor could be used and what evidence would make the signal trustworthy enough to influence maintenance.
The second is quality monitoring on a production line. Here the team explores manufacturing-engineering and quality perspectives. Questions shift toward inspection practices, acceptable false alarms, where sensing could fit into the process and what would need to happen before production decisions changed.
The same capability sits underneath both applications. The customer problem, workflow, roles, constraints and required proof do not.
Virtual Customer can help expose those differences before the team spends heavily on either path. The next step is still real customer and technical validation.
Separate use-case plausibility from market attractiveness
A plausible use case is not the same as an attractive market.
Simulated exploration can help you ask whether the technology connects to an important customer situation and where adoption questions may appear. It cannot establish how many customers have the problem, how much they will pay, how competitors will respond or whether the economics support a business.
Use customer interviews and observation to understand real problems and workflows. Use technical testing to establish performance in relevant conditions. Use market and commercial research to investigate market size, buying behavior, economics and alternatives.
Turn each application into a validation plan
For every application worth carrying forward, create a short team-compiled record:
Customer situation → problem → role → capability mechanism → constraints → evidence gap → next test
Then identify the assumption that could most seriously invalidate the use case.
For one application, that may be whether the problem is consequential enough to change behavior. For another, the customer problem may be clear but the technical environment may be the real uncertainty.
This makes the next step explicit. You are not choosing a market from simulated enthusiasm. You are choosing what evidence to collect next.
Start with two plausible applications
Take one technical capability and two customer applications that could credibly use it. Keep the technology description neutral, compare the customer problems, roles and operating constraints, and identify what real customer and technical evidence would make each use case stronger or cause you to drop it.