Go and See: Walking All the Way to Ground
Product leaders become the world's foremost expert in their domain by going to the source themselves.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 94%
A Rippling leadership principle: rather than delegating domain discovery to specialists and consuming summaries, the product leader personally descends to the lowest level of detail — the actual tax code, the engineer writing the code, the county tax administrator's process. Henrickson budgets roughly half a product leader's working hours to this, arguing that top-level communication is structurally insufficient to reveal what matters.
Origin
A codified Rippling leadership principle ('go and see'), with clear lineage to the Toyota Production System's genchi genbutsu / gemba walk. Henrickson pairs it with the Rippling expectation that a PM owns a whole product, not a feature, and is expected to be its world's foremost expert.
Core principles
- 01Top-level communication is inevitably insufficient to reveal what actually matters and what doesn't.
- 02You cannot understand a product until you have gone to ground on it — writing documents is pointless if you don't know what you're talking about.
- 03Hire the domain specialist after you understand the domain, not instead of understanding it: the tax expert is amazing at tax but that does not make them a great product thinker.
- 04The details you cannot anticipate are the ones that reshape the architecture — go and see is how you find them early enough to matter.
- 05Doing it in enough places (not everywhere) sets a company-wide expectation of clarity and forces everyone to raise their game.
- 06Deep domain ownership is what makes fast decisions possible: an expert answers on the spot instead of coming back in three days.
How to run it
- 1
Pick the hardest or most complicated thing
As a leader, resist floating up and assigning hills. Choose whichever problem seems hardest or most complicated and go be in the trenches on that one.
Pro tip You will always learn a lot from the detailed exercise, even when the visit produces no immediate decision.
- 2
Go to the primary source, not the summary
Open the actual tax code. Read the actual county ordinance. Sit with the engineer writing the actual code. Do not accept a briefing from someone who did that for you.
Pro tip A few instances of a domain are enough to become instructive — Henrickson cites just looking at Ohio and Pennsylvania local city and county taxes.
Watch out Do not delegate this to the domain expert and ask them to report back. That inverts the framework.
- 3
Hunt for the unanticipated differences
You already know some ways the domain differs. Go to find the ways you did not anticipate — those are the ones that force you to alter your entire approach.
Pro tip Ask process questions the summary never covers: when a city changes a tax rate unannounced, how will we know, how will we change it, how do we make it effective at the right date?
- 4
Convert the ground truth into system requirements
Back the observed detail into the architecture. 'Every country files taxes slightly differently' becomes 'what tax filing system satisfies every country we will ever run payroll in?'
Pro tip You will not have all the answers at this point. The win is setting the right things in motion months earlier than you otherwise would have.
- 5
Now hire the specialist
With first-hand understanding, make the case for hiring the tax (or compliance, or regulatory) expert. They become an amplifier of a correct model rather than the sole source of a model nobody on the product side understands.
- 6
Budget the time honestly
Treat this as roughly half the job, not a side quest. Henrickson's rule of thumb: of an 80-hour week, about 40 hours goes here. The other half — documents, engineering communication — is worthless without it.
Pro tip This is what lets a product org stay thin: a single leader who has actually gone to ground can hold the full scope of a product.
Watch out Leaders who cannot absorb detail at this rate cannot hold a whole product, and the org fattens with layers to compensate.
In the wild
When Rippling first attempted global payroll, the tempting assumption was that the UK would be broadly similar to the US. The head of payroll went to ground — reading the actual tax rules country by country, and in the US down to Ohio and Pennsylvania city and county level taxes — and returned with the ways the domains differed that nobody had anticipated.
→ Rippling completely altered its approach to entering countries, and backed the ground truth into an architectural requirement: a tax filing system general enough for every country it would ever run payroll in. The design got more precise over time, but the right things were set in motion at a far earlier stage.
Common mistakes
Delegating discovery to the domain expert
The instinct is to hire a tax expert and say 'go figure this out and tell me.' The specialist is excellent at the domain but is not necessarily a product thinker. The product person must get into the same weeds first, then hire the specialist.
Floating up as a leader
It is very tempting to assign hills from altitude. But challenges, problems, and successes are only visible in the trenches, and the detail you never see is the detail that dictates what the product must actually do.
Writing the strategy doc before going to ground
Henrickson's test: what is the point of writing a document if you don't know what you're talking about? Documents produced above the detail line encode confident wrong assumptions.
Is it for you?
Best for
Product leaders and founders entering a domain with dense, non-obvious operational detail — regulation, tax, compliance, logistics, healthcare — where the surface description hides the real requirements.
Not ideal for
Well-understood domains the leader has already mastered, or organizations where the leader's time is better spent on distribution than on product depth.
From the transcript
“of the leadership principles is go and see right so to to to look at the thing and then like walk all the way to…”
“and unless you're getting down there and seeing and understanding it firsthand you don't really understand what your product needs to do”
“so the person with the product thing has to has to get into those same weeds first to really understand it”
“if a job is 80 hours a week it's like 40 of your hours”
From the episode
Moving fast and navigating uncertainty
Jeremy Henrickson (Rippling, Coinbase)