Table of Contents
In the high-stakes world of product management, conventional wisdom often dictates that speed requires cutting corners—shipping Minimum Viable Products (MVPs) quickly and fixing things later. Jeremy Henrickson, Senior Vice President of Product at Rippling and former Chief Product Officer at Coinbase, challenges this narrative. Having overseen 40x growth at Coinbase during the 2017 crypto boom and now steering Rippling’s complex "compound startup" model, Henrickson argues that true velocity at scale comes from doing the hard work upfront.
Rather than simplifying early versions to the point of irrelevance, Henrickson advocates for designing systems that can handle the most complex use cases from day one. By investing in deep platform architecture and maintaining small, autonomous teams, companies can avoid the crushing technical debt that often paralyzes growth stages.
Key Takeaways
- Design for complexity first: Instead of building a simple MVP, design your architecture to handle your most difficult use case (e.g., global enterprise payroll) to prevent insurmountable technical debt later.
- The "Compound Startup" advantage: Building multiple business lines on a single "system of record" creates data fidelity that point solutions cannot compete with.
- Small teams drive velocity: Maintain speed as you scale by deploying "founder-type" leaders with small, cross-functional teams (a designer and 2-4 engineers) to launch new verticals.
- "Go and See" leadership: Product leaders must understand the granular details—such as reading tax codes themselves—rather than delegating foundational knowledge to experts.
- Operationalizing speed: Create a culture where decisions are made immediately rather than scheduled for next week’s meeting.
The Case Against the MVP: Solving for Complexity
One of the most contrarian positions Henrickson holds is his skepticism toward the traditional Minimum Viable Product (MVP) model, particularly for complex B2B platforms. While MVPs serve a purpose for zero-to-one startups seeking market validation, they often do a disservice to companies building platform-grade software.
When you optimize strictly for speed in the early days, you inevitably make architectural assumptions that simplify the world. However, if those assumptions are baked into the foundation, unwinding them when you need to support enterprise-grade complexity becomes nearly impossible. Henrickson suggests a different approach: visualize the most complex customer scenario immediately.
"If you're only thinking through the simple cases... you're going to make a different set of architectural assumptions and you're going to build on those for six months, nine months, a year. It's extremely difficult to unwind those decisions once you've built them into the product."
The Global Payroll Example
At Rippling, this philosophy manifested during their expansion into global payroll. The path of least resistance would have been to copy their US payroll infrastructure and patch it to work for the UK. Instead, they selected six diverse countries with radically different regulatory requirements and designed a single abstract engine capable of handling all of them simultaneously.
While this approach took longer initially, the result was a robust "Global Payroll" engine. Adding a new country is now largely a configuration task rather than an engineering rebuild. By solving for the hard cases first, the system became flexible enough to handle the easy cases effortlessly.
The Mechanics of a Compound Startup
Rippling operates as a "compound startup," a model where the company effectively runs several distinct businesses—payroll, device management, benefits, and time tracking—under one roof. The unifying force behind these disparate products is a single employee system of record.
Henrickson explains that while point solutions (specialized software for just one function) struggle with data integration, a compound startup relies on a unified database. This architecture allows for features that are technically impossible for competitors. For example, a permissioning system can instantly know who an employee's manager is because that organizational hierarchy lives in the same database as the IT and HR products.
Building New Products with "Founder" Teams
To manage this breadth without becoming bureaucratic, Rippling replicates the startup phase for every new product line. The process typically follows a distinct pattern:
- Identify the need: Recognize a new vertical (e.g., Time and Attendance).
- Recruit a Founder-Type: Find a single, entrepreneurial engineer or product leader who thrives on ambiguity.
- Assign a Design Partner: Pair them with a designer who knows the core platform's component library.
- Shield the Team: Give this small unit (growing to perhaps 4 people) autonomy for 6–9 months to build the product from scratch, interacting with leadership only for high-level guidance.
This method allows the company to launch entirely new business units with the agility of a seed-stage startup, while still leveraging the mature distribution and infrastructure of the parent company.
Maintaining Velocity Through Hyper-Growth
Henrickson’s experience at Coinbase during the 2017 crypto run-up—where the company saw 40x growth—taught him that velocity at scale is a function of focus and platform leverage. When a company scales, communication overhead usually slows down execution. To combat this, leaders must invest heavily in the underlying platform.
By abstracting complex technical problems into a shared platform, product teams can build features without reinventing the wheel. If the platform team solves identity management or reporting once, every vertical product team moves faster because they simply consume that internal service.
Navigating Uncertainty
In high-growth sectors like crypto or global HR, uncertainty is a constant. Henrickson notes that leaders often delay decisions while waiting for perfect information. At Coinbase, the question might have been, "Will Ethereum succeed?" In global payroll, it might be about changing regulatory environments.
The solution is to debate rigorously, align on a company point of view, and then execute at full speed toward that viewpoint until data proves otherwise. Henrickson emphasizes that speed of decision-making is a cultural muscle. At Rippling, the culture dictates that if a decision can be made in a slack thread or an ad-hoc huddle today, it should not wait for a scheduled meeting next week.
Leadership Principle: "Go and See"
As organizations grow, product leaders tend to "float up," managing people rather than products. Henrickson argues that this detachment leads to poor decision-making. He champions a "Go and See" philosophy, where leaders are expected to dive all the way to the ground level of a problem.
"It's very tempting to float up here as a leader and say, 'Hey, you take that hill over there'... when in fact where you really learn where the challenges are or the problems or the successes is by just being there with the people in the trenches."
This does not mean micro-managing; it means acquiring first-hand context. When building the global payroll product, the product leader didn't just hire local experts; they personally read the tax code text for different jurisdictions. This deep dive allowed them to understand the fundamental data structures required to support tax filings globally. A leader cannot effectively guide the architecture of a product if they rely entirely on summarized reports from subordinates.
Hiring for Curiosity and Adaptability
When hiring product managers who can thrive in this environment, Henrickson looks beyond standard credentials. He utilizes complex case studies where the candidate cannot possibly know all the answers upfront. The goal is to test how they react when new information changes the premise of the problem.
He places high value on the questions candidates ask during the interview. The best candidates demonstrate a deep engagement with the business model, asking about the implications of the "compound" strategy or platform architecture after only a short time studying the company. This level of insight signals a product mind that is capable of navigating the ambiguity and complexity of building at scale.
Conclusion
The common thread across Henrickson’s career at both Coinbase and Rippling is the rejection of superficial speed in favor of structural velocity. True speed doesn't come from cutting corners on an MVP or delegating understanding; it comes from building a platform that can digest complexity, empowering small teams to operate autonomously, and fostering a culture where leaders are willing to get into the weeds to understand the "ground truth" of their product.
){kind=link}