New-Idea Validation Bar
Prove real demand with 'duct tape', then prioritize ideas by pain-point sharpness and reach
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 82%
A lightweight framework taught in LinkedIn's internal Product University for deciding whether a new idea clears the bar to build. It insists on physical evidence that someone will actually use the thing (the 'duct tape' test), a simple expression of the idea, and a way to prioritize a list of ideas against the pain point they solve — distinguishing acute pain from broad reach and defining the data that would validate it.
Origin
Created for LinkedIn's internal Product University bootcamp after a survey revealed PMs felt they lacked the skills to do their job; later opened to the public as Hari Srinivasan's LinkedIn Learning product-management course.
Core principles
- 01A new idea needs proof of real-world demand, not just internal conviction
- 02Validate cheaply and physically before committing to build
- 03Ideas must be prioritized against the pain point they address
- 04Acute pain (deep for a few) and wide reach (shallow for many) are different axes to weigh
- 05Define up front what data would prove the idea good or bad
How to run it
- 1
Prove demand with 'duct tape'
Physically go out and demonstrate to the world that the problem is real and someone will actually do it — a scrappy, held-together proof rather than a polished build.
Pro tip Someone literally going out and trying it is stronger evidence than any deck.
Watch out Skipping this and building on internal conviction alone is the classic way to ship something no one wants.
- 2
Express the idea simply and prioritize against pain
Reduce the idea to a simple expression, then prioritize your list of ideas against the pain point each solves.
- 3
Weigh acuteness against reach
Classify each idea as either an acute pain point (very painful for a narrow group) or a wide-range use (mild pain for many people) and weigh them deliberately.
Watch out Conflating 'deeply painful for a few' with 'mildly useful for many' leads to mis-prioritized roadmaps.
- 4
Define the validating data
Decide in advance what data you'd expect to see to validate the idea, and use tools to confirm you've actually run the process — so a good idea is provable and the process is manageable.
In the wild
After a survey where PMs said they didn't have the skills to do their job, LinkedIn built an internal bootcamp and found you can't teach product through frameworks alone — you need real case studies, so they paired these validation tools with LinkedIn's own use cases including failures diagnosed in post-mortem.
→ The bootcamp became the basis of Srinivasan's public LinkedIn Learning course, teaching PMs a repeatable way to know when an idea clears the bar to build.
Common mistakes
Validating an idea only with frameworks
Frameworks alone don't teach judgment; without real case studies and physical 'duct tape' evidence, teams greenlight ideas that fail in the market.
Not defining validation data before building
If you don't decide what data would prove the idea good or bad, you can't honestly tell whether you've validated it or just rationalized it.
Is it for you?
Best for
Product managers and founders deciding which new ideas clear the bar to build and how to prioritize a backlog against real pain
Not ideal for
Mature, well-understood features where demand is already proven and the validation ceremony adds no information
From the transcript
“you got to prove to to the world why there's there's duct tape in here, right? There's someone actually physically going out and trying to…”
“How you can prioritize a list of ideas against a pain point”
“what's an acute pain point and what's a wide range of people use”
“How we'd expect data in order”
“to validate this”
From the episode
LinkedIn’s product evolution and the art of building complex systems
Hari Srinivasan (LinkedIn)