The 10x Lens on New Ideas
For every promising idea, ask where it could go in 3-5 years if it were 10x bigger — and let that reshape it now.
- Difficulty
- Easy
- Time to result
- ~ongoing to results
- Steps
- 3
- Confidence
- 90%
A habit of interrogating each new idea for its maximum reach before locking in its scope. Rather than building the narrow version, ask whether the same capability could apply far more broadly — to more user types and more products — and whether that bigger future should change how you design it today. Born from a costly missed opportunity.
Origin
Megan Cook's lesson from shipping developer automation in Jira too narrowly; Atlassian later acquired a company that had built the broad version.
Core principles
- 01The narrow context you design in can permanently cap a feature's functionality
- 02A capability useful to developers may be useful to everyone, everywhere
- 03Ask the 10x question during design, not only after early success
- 04A big future should change today's design decisions
How to run it
- 1
Ship the proving-ground version
Build the focused version to validate the core value — it's a legitimate proving ground.
Watch out Where you design it can quietly limit its functionality, so don't treat the narrow version as the final shape.
- 2
Ask the 10x question
For the idea, ask: how do we push this further? Is there something here we can 10x? Can we apply it to more types of users and more products?
Pro tip Do this as you build, not just once it's succeeded — Cook believes she should have caught the bigger opportunity during development.
- 3
Project it 3-5 years out and redesign accordingly
Ask where this could go in three to five years and whether that should change how you think about it now.
Pro tip If the answer implies a broader platform, design the broader service rather than the point feature.
Watch out Missing the broad version can mean a competitor builds it and you pay to acquire them later.
In the wild
Cook built automation so developers didn't have to leave their IDE to update work status — Jira detecting a commit and moving the item to 'in progress.' It shipped and worked well, but she designed it as a feature inside a user's workflow editor, limiting it to that context.
→ She later realized automation could power every product and every user type; Atlassian eventually acquired a company that built exactly that broad capability — an expensive mistake she now guards against.
Common mistakes
Designing in a narrow context
Placing a broadly-useful capability inside one narrow experience caps what it can become and forecloses the bigger opportunity.
Is it for you?
Best for
Product builders deciding the scope and placement of a new capability that could generalize across users or products
Not ideal for
Genuinely single-use features with no plausible broader application, where 10x thinking is speculative overhead
From the transcript
“So when I see a new idea, I'm always asking myself, how do we push this further? Is there something there that we can, you…”
“Can we apply it more broadly to more types of users, more products?”
“just where that”
“Where could this go in 3 years, 5 years? And should that change the way that you think about it now?”
From the episode
Lessons from Atlassian: Launching new products, getting buy-in, and staying ahead of the competition
Megan Cook (head of product, Jira)