Stakeholder reference (click to expand)
Stakeholder A
Dana Chen
VP of Support Operations
"My agents spend 40% of their time just figuring out what the problem is before they can start helping. We have 50 agents handling 200 tickets/day. If I could auto-route tickets to the right specialist, I'd save $2M/year. I don't care how you do it — I need tickets going to the right person within 30 seconds."
Success: Faster resolution, fewer transfers between agents.
Stakeholder B
Marco Silva
Head of Product
"I have no idea what our users actually struggle with. Product decisions are based on gut feel and whoever shouts loudest in the Slack channel. I need a systematic way to understand: what are the top pain points? Are they changing over time? When we ship a fix, does the conversation pattern actually change?"
Success: "I can point to data when I prioritize the roadmap."
Stakeholder C
Priya Kapoor
Chief Risk Officer
"Last quarter we had a billing bug that affected 2,000 users. Tickets started trickling in on Monday, but we didn't notice until Thursday when it hit social media. By then we had 500 angry public posts. I need an early warning system. I need to know when a NEW type of problem is emerging before it becomes a crisis."
Success: Detect emerging issues at least 48 hours before they escalate.
Stakeholder D
Alex Novak
ML Research Lead
"I'm interested in whether current embedding models actually capture the pragmatic structure of multi-turn conversations, or whether they just encode surface lexical features. Conversations have structure that single sentences don't — turn-taking, topic drift, resolution patterns. I want to understand what clustering reveals about representation quality. Publication is the goal."
Success: Novel finding about conversation representations, publishable at a top NLP venue.
Work
Scope It Down
Now take each of your research questions and make it manageable — without making it trivial. What are you assuming? What's in scope, what's out? What's the simplest version that would still be useful?
For each of your research questions, write down:
For each of your research questions, answer:
- Assumptions — "What are we taking for granted?" (e.g., that the conversation text is enough, that categories are stable, that 500 labels is sufficient)
- Boundaries — "What's in scope and what's out?" (e.g., English only? Only resolved tickets? Only the last 6 months?)
- Minimum viable version — "What's the simplest study that would still be useful to this person?" Not the full system — the smallest thing you could deliver in a month that moves the needle.
- Similar problems & SOTA — "Who else has faced a similar problem?" Look beyond the obvious — sometimes the state of the art comes from an unexpected field. How would you find it? What would you search for?
- This is where students learn that "every assumption you don't state is a hidden risk." Push groups to be explicit: "You said you'd cluster by topic — you're assuming topics are discrete. Are they?"
- The minimum viable version is key. If they say "build an end-to-end routing system" — push: "That's a product. What's the research question you'd answer first?" A good MVP might be: "Can we beat random routing on a 500-ticket sample using only conversation embeddings?"
- Notice which stakeholders are easier to scope (Dana, Priya) vs. harder (Marco, Alex). Alex's question is especially hard to scope because it's exploratory — "understand representation quality" has no natural boundary.
- If groups are fast, ask: "Which of your four questions is most answerable in three months? Which is least? Why?"