Go-Go-Go Plus Long-Term Compounding
Sprint to a proof of existence today; slow down to build the thing you will never regret owning
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 92%
Weinstein's core operating philosophy: default to maximum optimistic urgency ('can we turn tomorrow into today?'), but deliberately pair it with a compounding investment thesis about what will still be true in ten years. The tension is the point — some goals cannot be brute-forced with energy, and pouring more effort into them produces a flat line. The resolution: use go-go-go for proof-of-existence and for the individual steps, and use compounding for the platform underneath.
Origin
Jeff Weinstein's own temperament ('go go go' is a phrase he says so often that colleagues repeat it back to him), tempered by a formative failure at Stripe. For seven or eight years Stripe's rate of adding new countries and payment methods was flat despite enormous effort and headcount. The team's instinct was to 'lock everyone in the basement' and sprint from 10 payment methods to 50. Stepping back to a 10-year view instead — building internal platforms, physically relocating people around the world — flatlined the curve for a while, then broke it nonlinear.
Core principles
- 01Work expands to fill available time, so shrink the time: we'll do the work the night before it's due, so let's make it due tomorrow.
- 02Injecting energy is contagious — it ignites the same urgency in other people and feeds back on itself.
- 03Some outcomes are icebergs. They require layers of infrastructure, services, applications, UI and partnerships that no amount of intensity can compress.
- 04The compounding question is: what will we never regret spending time on? (Faster payment API latency. More reliable IRS filings.) Those investments always pay.
- 05Expect the curve to flatline while you build the platform. That's the cost of the strategy, and you have to hold your nerve through it.
- 06Proof of existence beats proof by theory or proof by debate — get one thing working, once, immediately.
How to run it
- 1
Default to go-go-go and compress the deadline
Take immediate action on whatever is in front of you and pull the due date in. The assumption is that the work will get done the night before it's due, so shorten the runway and see what energy produces.
Pro tip The urgency is socially contagious in a way that plans aren't — it ignites the same interest in others and compounds.
- 2
Notice when energy stops converting
Watch for the signature failure: a lot of very hard work, a lot of people, real desire from the market, and a flat line. That is the signal that the problem is structural, not effort-limited, and that going faster will not help.
Watch out This is the moment where teams double down on intensity — 'lock everyone in the basement' — and burn a year. The flat line is telling you to change strategy, not to press harder.
- 3
Zoom to a ten-year question
Ask: what is the world going to look like in ten years, what will need to be true, and how can we start going there now? Then look at the individual components of what it takes to get there and be honest that they will require going slower.
- 4
Name what you will never regret
Identify the investments that always pay regardless of which future arrives — lower API latency, higher reliability on a critical filing, an internal platform. Those get continuous compounding investment, no re-litigation each quarter.
Pro tip When you commit, commit properly: on 83(b) filings Stripe decided it would do this forever, as a piece of infrastructure for the rest of the internet — which is what justified the intense vendor SLAs, backup vendors, alerts and playbooks.
- 5
Use go-go-go for the proof of existence inside the slow bet
Within a multi-year platform bet, use urgency on the smallest demonstrable step. On 83(b): one engineer's job that day was to send a single piece of paper to the office via a third-party mail service — no reason given, just do it today.
Pro tip Holding the physical proof — the piece of paper that arrived — is a far more powerful argument than any deck. That engineer went on to lead all of the 83(b) work.
- 6
Be rigorous on the compounding half
Where the long-term bet lives, be deliberately heavy: third-party vendors and backup vendors, explicit promises, SLAs, reporting systems, alerts, playbooks, backup processes. Re-examine annually — Stripe writes a document each year literally titled 'should we do this ourselves?'
Pro tip Using an external vendor forces you to actually verify it works (OCR the results, checksum everything) — an instinct teams lose when they build in-house and assume 'we built it, it must be working'.
In the wild
For years Stripe's country and payment-method additions were flat, despite enormous effort. Rather than lock everyone in the basement to sprint from 10 to 50, the team took a ten-year view: build internal platforms, send people around the world, uproot their lives, pay for apartments, get them on planes, and use the payment methods in the real world.
→ The line flatlined for a while and the team questioned the strategy — then it turned nonlinear. Stripe hit 50 quickly and skyrocketed to over 100 payment methods.
To start the 83(b) automation, Weinstein told one engineer: today, your job is to send a single piece of paper to the office through a third-party mail service. Don't ask why. She did it, and brought back proof that the paper had arrived the next day.
→ 'The 83(b) election is just sending this piece of paper to the IRS — we just did it.' The proof of existence carried the project. Three years later, Atlas had filed 10,000+ 83(b) elections, 100% on time, and company formation became a single click.
Common mistakes
Answering a flat line with more intensity
When a lot of energy is producing no returns, the instinct is a sprint. But if the constraint is structural — you need platforms, on-the-ground presence, partnerships — energy just burns people. The correct response is to slow down and build the compounding layer.
Only compounding, never shipping
The inverse failure. Weinstein is explicit that he still struggles to balance them and that go-go-go is what generated the 83(b) proof of existence inside a three-year bet. Long-term strategy without an immediate demonstrable step never gets the internal momentum to survive.
Assuming in-house means working
When you build something yourself there's a natural feeling that it must be working, and alerts and playbooks get deferred until there are problems. Outsourcing a critical step forced Stripe to define interfaces, verification and failure handling up front.
Is it for you?
Best for
Product and engineering leaders whose team is working extremely hard on a market that clearly wants the thing, yet the growth curve is stubbornly flat
Not ideal for
Situations demanding pure reliability discipline — Weinstein notes 'let's make some mistakes' does not apply to the nines of reliability on a payments API
From the transcript
“before it's due so let's just make it due tomorrow can we turn tomorrow into today”
“so actually the optimistic as soon as possible go go attitude was not working right”
“is the world going to look like in 10 years what was going to need to be true and how can we start to go…”
“where can we always invest what what what will we sort of never regret spending time in”
“engineer hey it's your job today to send one piece of paper to the office with this third-party uh mail service why doesn't matter today…”
“each year we write a document called should we do this ourselves”
From the episode
Building product at Stripe: craft, metrics, and customer obsession
Jeff Weinstein (Product lead)