TL;DR
LENS is a technique that extracts from an interview transcript not only what was said outright but also what was left between the lines. It works in two steps: first it collects the explicit requests, then it looks at the same words through the lens of "what tools do we already have?" and generates hidden opportunities the speaker never put into words.
The key finding: people describe pain but don't ask for a solution. They say "we spend two hours a month manually listening to call recordings" and leave it at that. An LLM without context will stay silent too: it has no idea you've got a chatbot that can transcribe. But give the model a list of your tools and it will put two and two together and suggest an automation nobody thought to ask for.
How it works: Step 1: extract the explicit requests from the text (what was actually said). Step 2: feed the same text along with a description of the available tools and ask for hidden opportunities with a justification: what the problem is, how to solve it with the existing stack, what the payoff is.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1 (separate request): Extract explicit needs
Input: transcript/text
→ List of user stories: "As a [role], I want [goal] so that [reason]"
→ Reference to the source in the text
STEP 2 (separate request): Infer latent needs
Input: transcript/text + explicit needs from Step 1 + list of available tools
→ List of new user stories (no repeats from Step 1)
→ Justification for each: problem → tool → expected effect
Two separate requests. The output of Step 1 becomes input for Step 2.
Example in Action
Task: You're a product manager at an HR SaaS startup (think something like Greenhouse or Lever). You've run a series of customer discovery interviews with HR managers. You want to surface not just the explicit asks but also the opportunities customers never articulated, knowing you already have a Slack integration, a built-in resume parser and funnel analytics.
Prompt (Step 1):
You are a product requirements analyst. Your task is to extract explicit needs
from a transcript of a user interview.
An explicit need is something the person directly stated as a request,
a wish, or a problem they want solved. Do not interpret or fill in gaps.
For each need, write a user story using the template:
"As a [role], I want [specific action/capability] so that [reason/benefit]."
After each user story, give the quote from the text it was extracted from.
If you encounter any of the following, do NOT create a user story:
- A description of current manual work with no intent to automate
- A description of something already done/automated
- Clarifying questions like "this already works, right?"
Transcript:
{paste the interview text}
Prompt (Step 2):
You are a product analyst. Your task is to find hidden automation opportunities
that the user did not state but that follow from the processes and pain points they described.
Context: the tools and capabilities available to us:
{list of tools with a short description, for example: "Slack bot: can send
notifications and collect replies. Resume parser: extracts structured data from LinkedIn.
Funnel analytics: calculates conversion by stage."}
Explicit needs already identified in the previous step:
{paste the result of Step 1}
Interview transcript:
{paste the same interview text}
For each hidden opportunity:
1. Write a user story: "As a [role], I want [action] so that [benefit]."
2. Add a justification using the template:
"Automating [action] helps solve [problem/inefficiency] in [context].
Right now this is done [manually / partially / with another tool].
The automation can be built with [available tool] by [how exactly].
As a result, [expected effect: time, quality, workload]."
Do not repeat the explicit needs from the previous step.
Only propose what can realistically be built with the available tools.
Result:
Step 1 returns a list of user stories with direct quotes: only what the HR manager explicitly asked for. Step 2 surfaces 3-7 hidden opportunities with a justification for each: what to automate, with which of your tools, how much time it saves. The wording is tied to your stack rather than abstract.
Why It Works
LLMs are good at looking forward, generating links between what exists and what could be. But without the "what exists" context, they're working blind. The tool description isn't just a list. It's a constraining frame: the model doesn't daydream about an ideal world, it looks for opportunities within your real stack.
The explicit and latent steps are separated for a reason. Ask for everything at once and the model blends the literal with the inferred, and the line between "the customer asked" and "I filled that in" disappears. Two separate requests keep that line intact: Step 1 records the facts, Step 2 builds hypotheses.
The justification template is a strong move in its own right. When the model has to fill in the "problem → tool → mechanism → effect" structure, it can't write a vague "this would be useful." The structure forces specificity and makes hidden suggestions testable rather than abstract ideas.
Control knobs: - Tool list: the more precisely you describe each tool's capabilities, the more concrete the suggestions - Rules for Step 1: the three false-positive patterns from the paper (manual work with no intent, descriptions of existing automation, clarifying questions) are worth listing explicitly in the prompt - Justification template: adapt it freely: drop the "how to build it" part if you only want ideas, or add "priority" if you need a backlog
Prompt Template
Step 1: Explicit needs
You are a product requirements analyst.
Extract the explicit needs from the text below. An explicit need is only
what {interviewee role} directly stated as a request or wish.
Format for each need:
User story: "As a [role], I want [action] so that [benefit]."
Source: [quote from the text]
Do NOT create a user story if the text:
— describes manual work with no intent to automate
— describes something that already works/is automated
— asks a clarifying question ("that's already how it works, right?")
Text:
{interview transcript or notes}
Step 2: Hidden opportunities
You are a product analyst. Find hidden improvement opportunities
that were not named explicitly but follow from the described processes and pain points.
Available tools and capabilities:
{tool name 1}: {what it can do}
{tool name 2}: {what it can do}
...
Explicit needs already identified (do not repeat them):
{result of Step 1}
For each hidden opportunity:
1. User story: "As a [role], I want [action] so that [benefit]."
2. Justification:
"Automating {action} helps solve {problem} in {context}.
Right now this is done {how it's done today}.
The automation can be built with {tool} by {how exactly}.
As a result, {expected effect}."
Only propose what can be built with the listed tools.
Interview text:
{the same transcript}
Placeholders:
- {interviewee role}: HR director, customer, team lead, etc.
- {interview transcript or notes}: text in any format: verbatim transcript, brief notes, email threads
- {tool name}: {what it can do}: keep it short: "CRM: stores deal history and can change statuses automatically"
- {result of Step 1}: copy the output of the first request
🚀 Quick start: paste into the chat:
Here is a template for a two-step method for extracting requirements from interviews.
Adapt it to my task: {your task, for example: "I want to analyze
notes from meetings with customers of our delivery service"}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask about the interviewees' roles, the text format and your list of available tools, because without that context Step 2 produces abstract recommendations instead of concrete ones.
Limitations
⚠️ Temperature: The study showed that too low a temperature (0.0) produces lots of noise, while too high (1.0) loses precision. The sweet spot is in the middle. In ChatGPT and Claude the chat temperature is usually fixed, but you can compensate with explicit instructions: "Don't fill in gaps, rely only on the text" (Step 1) and "Be specific, rely on the tool list" (Step 2).
⚠️ False positives in Step 1: The model tends to turn three kinds of statements into requirements: descriptions of manual work ("we do X by hand"), descriptions of existing automation ("we already have X"), and rhetorical clarifications ("that's already automated, right?"). Spell out these exclusions explicitly in the prompt and check the output.
⚠️ Quality depends on the context description: The hidden opportunities (Step 2) are only as good as your tool list is precise. Thin context → bland suggestions.
⚠️ Preliminary study: Tested on 12 interviews at a single company (cybersecurity). The results are promising, but there's not much data yet.
How They Tested It
A team from the University of Ottawa, together with the Canadian cybersecurity company eSentire, took 12 real work interviews, each about an hour long, averaging ~9,000 words, with three participants. No synthetic data, no textbook examples: live conversations about performance analytics, threat investigation and routine SOC processes.
They ran LENS on Claude Sonnet 4.5 at four temperature levels: 0.0, 0.35, 0.7 and 1.0. Interesting finding: the extremes lose to the middle. At temperature 0.0 the model pulled in a lot of noise (50% precision). At 1.0 it was even worse (41%). The optimum turned out to be 0.7: precision 73%, recall 100%, F1 = 84.4%. A nice argument that determinism in LLMs isn't always a virtue.
The latent requirements were rated by two independent experts from eSentire, people who know the tools and processes from the inside. They rated on the scale "would this save time if implemented." 75% of the suggestions got a positive rating. The two experts agreed moderately (κ = 0.54), which points to genuine subjectivity in judging "usefulness" rather than a weakness of the method.
Adaptations and Extrapolations
🔧 Adaptation: analyzing reviews instead of interviews
The method isn't limited to transcripts. The input can be any text where people describe processes: App Store reviews, support tickets, messages in a WhatsApp group with customers, team retrospectives.
Example: Collect 20-30 reviews of your product. Run Step 1 and you get the explicit complaints and wishes. Feed them, along with a description of your stack, into Step 2 and you get ideas for automations and improvements users didn't ask for but that will solve their pain.
🔧 Adaptation: surfacing hidden risks instead of opportunities
Step 2 doesn't have to look for opportunities; you can point it at threats and risks instead.
Replace the Step 2 instruction: "Find hidden opportunities" → "Find unspoken risks and potential problems"
The justification template adapts accordingly: "The risk of {situation} arises because of {cause}. Right now it is not tracked / handled manually. It can be mitigated with {tool} via {mechanism}. Without this, {consequence}."
Useful for analyzing employee interviews before launching a new process, or reviewing customer calls before a major rollout.
Resources
Paper: LLM-Based Discovery of Latent Requirements from Stakeholder Conversations: Preliminary Results from Industry
Authors: Mithila Sivakumar, Martin Lochner, Shiva Nejati, Mehrdad Sabetzadeh
Organizations: EECS, University of Ottawa (Canada); eSentire, Inc. (Canada)
Related concepts: Conversational RE (Requirements Elicitation), User Story format [Cohn, 2004], Few-shot prompting