One-Click Zoom-Out
Step back once from a local task to test the wider problem and assumptions
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 96%
One-Click Zoom-Out is a small systems-thinking habit applied before committing to a local solution. Start with the task you own, then move exactly one level outward: identify the broader customer problem, the assumptions about the surrounding system, and the adjacent use cases the solution may need to support. You do not need to redesign the company's whole strategy or solve every dependency. The purpose is to test whether local progress points in the right direction and whether the work will help colleagues, scale to future needs, and leave the system stronger. Looking at the task from a manager's broader perspective can reveal connections across functions while keeping the resulting action practical and bounded.
Origin
When Lenny asked how people can learn systems thinking, Elizabeth Stone offered a small trick: take each problem and step out one click to question what you assume about the broader space. She then applied it to a hypothetical Netflix feature.
Core principles
- 01Systems thinking begins one level beyond the assigned task
- 02Local progress is wasteful when it solves the wrong broader problem
- 03A solution should leave stronger foundations for colleagues and future work
- 04Breadth does not require solving the entire company strategy
How to run it
- 1
Anchor the local task
Write down the feature, analysis, or system change you are responsible for. Clarify the immediate output before widening the frame.
Watch out A vague task makes the zoom-out too abstract to guide action.
- 2
Move one level outward
Ask what larger consumer, business, or organizational problem the task is meant to solve. Stop after one useful level rather than attempting to solve the entire strategy.
Pro tip Imagine how your manager sees the task alongside the other functions and priorities they coordinate.
Watch out Do not use systems thinking as a reason to boil the ocean.
- 3
Question the assumptions
Surface what must be true about users, content, systems, scale, or future needs for the local plan to work. Check whether those assumptions are credible.
Pro tip Ask whether the same capability could support adjacent teams or use cases.
- 4
Strengthen the local solution
Revise the task so it solves the right problem and leaves a reusable, higher-quality foundation. Then return to forward progress with the broader context captured.
Pro tip Prefer a bounded change that helps colleagues over an ambitious redesign that never ships.
In the wild
A builder assigned a new member-experience feature pauses to ask which broader consumer problem it addresses, what content types it must support, and whether the planned implementation can scale across those types. The builder does not solve Netflix's entire strategy, but uses the wider frame to test the local design.
→ The feature is more likely to solve an important consumer problem and support future entertainment formats.
An engineer considers whether a system change will be useful to colleagues and whether it leaves a stronger platform for later innovations, rather than optimizing only for the immediate team's metric.
→ Local delivery contributes to a more scalable organizational system.
Common mistakes
Boiling the ocean
Zooming out too far turns a practical check into an attempt to solve the whole company strategy.
Optimizing only for the local KPI
A locally successful solution can still damage the broader customer experience or create work for adjacent teams.
Is it for you?
Best for
Individual contributors and managers who want to build systems thinking into everyday product and engineering decisions.
Not ideal for
Urgent, fully specified operational work where widening the frame would not change the decision.
From the episode
Netflix CPTO on AI and the future of product and tech roles
Elizabeth Stone