Why it matters
What this principle is for.
Thinking big is how you challenge assumptions about what is possible. It shocks people out of hunting for the problem with a simple patch, and it is often the only way to invent out of a dead end.
Look for a vision that is bigger than current reality, and for a path that is bold, rational, and still achievable. "Good idea. What would it look like at 50x?" is a thought stimulator, not a threat. The answer is usually a different approach, not a louder version of the same plan.
Why is a good question. Why not is just as good. Short-term math will talk you out of the durable bet. Over a decade, the thing that raises how often customers return, how much of their work they do with you, and how satisfied they stay is often the thing the quarterly model rejects.
Thinking big is disruptive. It is not accepted quickly. It raises problems with no known solution, it asks people to change, and it usually requires influence beyond your span of control. If someone only optimizes the process in front of them, they are not thinking big. If they cannot name how they would get from here to there, they are daydreaming.
Calibration
Under, just right, over.
Use the rows to score whether someone sets a bold, defensible direction, or whether they either sandbag or boil the ocean. Look for a stretch goal with a path, not a slogan.
| Situation | Under | Just Right | Over |
|---|---|---|---|
| Scoping this week's work | Treats the ticket as the whole job. Does not ask what larger outcome the work is for. | Names the larger outcome, then cuts this week to the smallest slice that tests it. The team can see the ambition and still finish something real by Friday. | Inflates a one week ticket into a program before anyone has tried a small version. Nearby commitments slip while the plan grows. |
| A customer asks for a tweak | Builds exactly the tweak and stops. Never asks whether the request points at a bigger gap. | Ships a useful fix this week and writes down the larger need it hints at. The customer is helped now, and the next bet is informed instead of locked into a dead end. | Pauses the tweak to redesign the whole product around one request. The customer waits, and the team spends the week on a vision that nothing can test yet. |
| Writing the proposal | The writeup only covers what the team already knows how to do. The ask is safe and easy to forget. | States a destination that would matter if it worked, then proposes a cheap first proof. Reviewers can argue both the ambition and the first step in the same meeting. | The proposal is all destination and no first step. The room agrees with the vision and leaves with nothing to build this week. |
| When a constraint feels fixed | Treats headcount, tooling, or policy as immovable and shrinks the idea to fit. Nobody asks whether the constraint should change. | Names the constraint, checks whether it is real, and either works around it or makes a specific ask to lift it. The idea stays large enough to matter, and the ask is concrete enough to answer this week. | Insists every constraint come off the table before any work starts. The team waits on permissions while a smaller proof could have run. |
| The standup update | Reports only the task. Teammates cannot tell what larger bet the work belongs to. | Ties today's task to the larger bet in one sentence, then says what will be true by Friday. People leave knowing the direction and the week's proof. | Uses standup to restate the long vision. The update runs long and nobody knows what is shipping. |
| Reviewing a design | Approves a design that only clears the current ticket. Does not ask what happens if the bet actually works. | Asks how the design would hold if usage grew, then accepts a simpler first version if the path to that scale is visible. The author leaves with a small build and a named next constraint. | Rejects every simple design until it handles imagined future scale. The first version never ships, and the team keeps redrawing. |
| Picking the next experiment | Picks the safest test, the one that cannot change anyone's mind. The bigger question stays untouched. | Chooses an experiment small enough to run this week that would change the larger bet if it failed. The team accepts a clear no in exchange for a clearer direction. | Designs an experiment so large it needs new infrastructure first. The question that could have been answered this week waits. |
| A workaround shows up | Notes the workaround and moves on. Treats it as a one-off instead of a signal of a larger unmet need. | Eases the immediate pain, then spends a short pass asking what job people are hiring the workaround for. A bigger opportunity is named without dropping this week's work. | Throws out the current plan to chase the workaround as the next platform. Focus scatters and committed work slips. |
Examples
What it looks like in the work.
Ask what 50x looks like
A team has a good idea that would make a painful step faster. The leader asks what the work would look like if the goal were 50 times larger. The team stops speeding up the step and designs a way to remove it. That is thinking big. The question changed the approach; it did not just inflate the slide.
Bet on what is durable
Short-term math says do not invest, because this quarter will look worse. The leader still makes the bet because the thing is durable: it raises how often customers come back, how much of their work they do with you, and how satisfied they stay. A strategy built on a fad has to be rewritten every year.
Solve it so other teams can use it
The team could ship a one-off that only they can run. Instead they build a service that solves their problem and is simple enough for other teams to adopt. The bold part is not the feature list. It is the decision to create a platform instead of a local fix.
In the role
Individual and manager.
Individual
An individual who thinks big does not wait for a vice president to issue a vision. They reframe the problem they were handed, name a bigger customer outcome, and show a path that is bold and still defensible. They can say what they would do if the problem were 10 times larger, and they can say what they would stop doing to make room.
Manager
A manager who thinks big sets a small set of medium and long-term objectives, communicates them so the team can repeat them, and still protects near-term customer needs. They hire and aim people at the larger problem. They do not run a science project that never ships, and they do not let the team hide in month-to-month tactics.
Go deeper
Questions that make the principle concrete.
- Are you letting the current state define the solution, or are you looking for something that removes the pain point altogether?
- What would the work look like if the problem were 10 times larger than it is now?
- Which assumptions about team size, capability, market, or customer behavior are you treating as facts, and how are you testing them?
- Who is not your customer today, but should be, and what would it take to serve them?
- Is cost, history, or a failed attempt somewhere else constraining the idea before you have invented around it?
- Are you building a me-too product, or are you thinking big on behalf of the customer?
- How often do you run a session that is about possibilities rather than risks, and whose voice is missing from that room?
- If this idea still has to make sense in ten years, what part of the current plan is transient and should not be load-bearing?
- Can you explain how to get from the current charter to the bold direction, or are you asking the team to take a leap of faith?
- What would you stop, so the bigger bet has the people and time it needs?
From the blog
Writing that goes deeper.
- Biases and Fallacies Lead to Smol Thinking
The quiet ways a bold direction gets sanded down into a local patch.
Related