CHAPTERS
- 0:01 – 2:19
Emmett’s startup origin story: why “build first, talk later” failed
Emmett opens with lessons from Kiko Calendar and early Justin.tv, highlighting how building without understanding real users leads to weak outcomes. He contrasts being able to build software with knowing what to build.
- •Kiko Calendar shipped but failed to find product-market fit (sold on eBay)
- •They didn’t use calendars and never interviewed calendar users
- •Justin.tv initially succeeded partly because the founders were the target user
- •Being your own user can work but is a limiting strategy for most startups
- 2:19 – 3:51
The Justin.tv pivot and the realization that user insight drives growth
As Justin.tv grew, the team struggled to expand beyond the initial “reality show” use case. The need to pivot forced them to confront a knowledge gap that analytics and intuition couldn’t fill.
- •Justin.tv worked well for a narrow 24/7 life-streaming use case
- •They lacked insight to broaden to new audiences and use cases
- •Pivot options emerged: mobile vs. gaming
- •Gaming required learning from people who actually broadcast games
- 3:51 – 5:52
How Twitch began: interviewing to learn the broadcaster’s world
Emmett explains how Twitch’s product roadmap was shaped by extensive early interviews. The team identified broadcasters as the most strategically important users and built an ongoing user-research function.
- •Large volume of interviews informed years of Twitch product decisions
- •Twitch institutionalized “talk to users” as a company function
- •Broadcasters were the key user because audiences follow content creators
- •Who you interview can matter as much as the questions you ask
- 5:52 – 8:59
Exercise setup: choosing the right users for a lecture note-taking app
Emmett shifts to an interactive class exercise: a lecture-focused note-taking app. Students are asked to ignore features and instead decide who to interview and where to find them.
- •The first step is identifying who can give the most valuable feedback
- •Write down 5 candidate users/user-types and pick the most important
- •Finding interviewees is often harder than writing questions
- •Broad sampling early helps you understand the full space
- 8:59 – 11:47
Audience share-out: students aren’t the only “user” who matters
A student proposes interviewing college students across majors and study styles. Emmett validates this but pushes further: the payer and decision-maker may be different from the end user.
- •Interview across disciplines and note-taking intensity/styles
- •Students reveal habits and pain, but may not be the buyer
- •Potential buyers include college IT/admin or even parents
- •Early-stage research should include all critical stakeholders
- 11:47 – 16:17
Live user interview demo: uncovering behavior, not feature requests
Emmett conducts a short interview with a student (Stephanie) to model effective questioning. The focus stays on current workflows, tools, and real behaviors around note-taking and review.
- •Probe current habits: laptop vs. pen/paper; class-dependent needs
- •Identify tools in use: Google Docs and Evernote, and why both
- •Explore collaboration patterns and personalization preferences
- •Ask about review behavior and when notes matter beyond class
- 16:17 – 18:53
Avoiding the feature trap: learning problems beneath the “horseless carriage”
Emmett explains why early interviews should avoid discussing your product or proposed features. Users’ feature requests feel compelling but can mislead; the goal is to diagnose real problems and motivation.
- •Don’t anchor users by talking about your app or specific features
- •Users often describe incremental fixes (“faster horse”) not solutions
- •A single interview rarely proves a market; patterns emerge after ~6–8
- •Listen for blockers and intensity of pain, not nice-to-have requests
- 18:53 – 21:43
From interview to hypothesis: propose one ‘quantum improvement’
The class is asked to translate what they heard into a single compelling improvement over existing tools. A student suggests bridging Google Docs collaboration with lightweight “small note” capture.
- •A useful exercise: ‘one feature on top of Google Docs’ to win switching
- •Insight: Docs is good for documents; Evernote is better for quick notes
- •Hypothesis: integrated workflow for collaboration + lightweight notes
- •The real question: is it enough to cause users to switch?
- 21:43 – 25:26
Validating ideas without building the whole product (and the money test)
Emmett cautions against asking users if a feature is “good” because they’ll often say yes. He recommends finding ways to cheaply put the idea in front of users—hacks, extensions, prototypes—or using payment as proof.
- •Don’t ask ‘Are you excited?’—it produces false positives
- •Minimum validation often means hacking: e.g., a browser extension
- •‘Find a way to cheat’ to test utility before months of work
- •Charging (even small amounts) is highly validating when feasible
- 25:26 – 27:58
Twitch case study: what current users asked for vs. what mattered
Emmett shares condensed interview feedback from Justin.tv gaming broadcasters—requests heavily focused on detailed feature issues. He explains why these weren’t necessarily the highest-leverage problems to solve.
- •Existing users asked for tactical fixes (ban lists, titles, chat tools)
- •Detailed users often talk in feature-level terms
- •If they tolerate pain and use you anyway, it may not be the biggest blocker
- •You must read between the lines to infer deeper goals
- 27:58 – 29:28
Competitor users reveal adoption blockers: stability, monetization, reach
Interviewing people on competing platforms produced very different priorities. Twitch focused on these because they explained why people wouldn’t switch or adopt in the first place.
- •Competitor users cared about rev share/making a living
- •Video stability and global performance (e.g., Europe) were major issues
- •Feedback differed sharply from existing-user feature requests
- •Focus on what prevents usage/switching, not just polish requests
- 29:28 – 31:30
Non-users expand the market: removing barriers to new behavior
Emmett argues that non-users may be the biggest “competitor” for new products. Their objections shaped initiatives to make streaming easier and more accessible, including partnerships and platform integrations.
- •Most of the addressable market may be non-users, not competitor users
- •Non-user blockers: weak PCs, time priorities, preference for edited video
- •Strategic fears (e.g., broadcasting reveals competitive strategies)
- •Responses included buying equipment, improving tooling, and console integration
- 31:30 – 34:58
Turning interviews into strategy: solve for goals, then win trust internally
Emmett explains that interview outputs shouldn’t be a literal feature list; they should reveal goals (money, quality, reach). He contrasts this with Justin.tv’s analytics-heavy approach and notes how feedback often kills pet ideas before you waste months.
- •Translate feedback into underlying goals: monetization, stability, access
- •Many winning investments weren’t explicitly requested as ‘features’
- •Revisiting interviewees with solutions creates strong early converts
- •User research often disproves pet ideas—painful now, saving later
- 34:58 – 46:27
Q&A: common interview mistakes, recording, channels, and evolving user sets
In Q&A, Emmett lists frequent pitfalls and practical tactics for conducting and scaling interviews. He covers buy-in, recording, why email is weak, international challenges, recruiting channels, and how target users change over time.
- •Mistakes: showing your product; asking leading questions; talking to easy users
- •Record interviews to persuade teammates and reduce note-taking disruption
- •Prefer live calls (Skype/in-person) over email for ‘tell me more’ probing
- •Recruit via onsite messaging, email, events; usually no compensation needed
- •International research is hard; translation skews representativeness
- •Early focus: competitor users for quick wins; user pools shift as company grows
