Research-to-Product Lens
Turn technical potential into a product people demonstrably want
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 94%
Start with a technical capability, but refuse to treat novelty as proof of value. Identify a concrete user need, collect signals that people genuinely want the outcome, and design a complete product around that evidence. Researchers should work through the lens of how their advances fit the product being shipped, rather than operating as an isolated laboratory. The mechanism moves from potential capability to observed demand, then to integrated product design, reliable execution, and customer adoption. Steve Jobs exemplified this by combining existing ideas such as graphical interfaces, object-oriented programming, and networking into products that worked as coherent experiences. The framework rewards translation and integration: the scarce skill is not merely inventing technology, but turning it into something useful, dependable, and desirable.
Origin
Extracted from The Shawn Ryan Show
Core principles
- 01Technical novelty is not evidence of demand
- 02Research should connect to a shippable customer outcome
- 03A complete solution matters more than an isolated invention
- 04Customer behavior provides stronger evidence than technical possibility
- 05Product teams must translate potential into reliable utility
How to run it
- 1
Identify the potential capability
Describe what the technology makes possible without assuming that possibility itself creates value.
Pro tip State the capability in terms of a changed user outcome rather than an engineering milestone.
Watch out Do not confuse technical difficulty with customer importance.
- 2
Find demand signals
Gather evidence that users experience the problem and want the proposed outcome. Favor observed behavior, commitments, or repeated pain over compliments.
Pro tip Ask what data or signal demonstrates that people will use the result.
Watch out A blank answer to why people will use the product signals unresolved product risk.
- 3
Design the whole solution
Integrate the capability into a coherent product that solves the need from end to end. Account for usability, reliability, distribution, and supporting infrastructure.
Pro tip Compare the proposed experience with the user's current complete workflow.
Watch out An isolated feature or laboratory demonstration is not yet a product.
- 4
Bind research to shipping
Organize advanced work around how it will enter the product and support its story. Give researchers direct product context and concrete delivery constraints.
Pro tip Pair research milestones with prospective product applications.
Watch out A detached research division can produce breakthroughs that never reach customers.
- 5
Validate real-world utility
Ship a testable experience and observe whether users repeatedly choose it. Use those results to refine both the product and the underlying technology.
Pro tip Measure retained use and completed outcomes, not just initial curiosity.
Watch out Do not mistake a compelling demonstration for sustained adoption.
In the wild
A computer company combines networking, object-oriented development tools, and a graphical interface into one operating system. Rather than presenting the technologies independently, it gives developers a practical environment for creating networked graphical applications.
→ Existing research becomes a usable platform capable of supporting products such as the World Wide Web and later Apple devices.
An enterprise software team has an accurate document-analysis model but little evidence that customers want another dashboard. It observes users manually transferring extracted terms into review tables, then embeds the model in that workflow and measures repeat use.
→ The technical capability becomes a complete workflow tied to demonstrated customer demand.
Common mistakes
Celebrating possibility as demand
A capability being newly possible does not establish why anyone will adopt it. Require an independent signal of customer need.
Shipping a technology demo
A striking demonstration may omit the workflow, reliability, and infrastructure necessary for continued use.
Isolating advanced research
Researchers without product context may create valuable inventions that never become part of a coherent customer experience.
Is it for you?
Best for
It is best for founders and established technology organizations commercializing advanced research.
Not ideal for
It is not ideal for routine improvements where customer demand and the implementation path are already established.
From the transcript
“But like it was technology. It wasn't a product. It wasn't something that like you plugged it in and it just worked and it delighted…”
“the question I always ask is like, what data do you have? What signal do you have that people want this?”
“everybody who's doing that pioneering research, you need to be doing it with the lens of how are we going to build this into this…”
From the episode
NeXT (Live show at the GeekWire Summit)