Jeremy Henrickson: belief

Transcript context

…This reminds me you're also, I hear not a big fan of MVPs that you building products to further point. Is that true? And then if so, how do you think about the initial version of a product? First of all, I don't want to knock on MVPs. I think MVPs have their place extremely useful, particularly if you're literally the zero-to-one company that's never done anything before and you don't have clear market validation. I think in our case specifically for Rippling, a minimum viable product would do a disservice to both our customers and to the very team that was building it. And the reason I believe that is that when you design a minimum viable product, you're optimizing for speed. And in that set of optimizations, you are minimizing the deeper product thinking about what can fully differentiate our product based on not only existing kind of capabilities within our products and platform, but based on what it ought to do in the future. And so it sort of limits product creativity, but worse, it leads to building the wrong thing technically, right? So if you're only thinking through the simple cases and you're an engineer and no one's pushing you on saying, "Wait, what about that healthcare hospital administration case where it's mission-critical life," then you're going to make a different set of as architectural assumptions, and then you're going to build on those and you're going to build on those for six months, nine months a year, and you'll have dozens or 100s of assumptions built on top of those. And it's extremely difficult to unwind those decisions once you've built them into the product. And therefore we believe very deeply it's like, sure, understand those simple cases. Understand if you're a two-person company, you don't need all of these other things. And what is the product going to look like for you to approach it but also understand what it would mean to have 10,000 people globally around the world with this ridiculously hard use case? What's the model that would support that? And let's make sure that as we're doing the technical and product design for this thing, that it accommodates that view, even if we're not going to support it in the first version, even if we make the product decision to say, "Look, we actually don't need to handle that case right now." You still build the product in a way that's not going to prevent you from getting there in the future. And does that take a little more time? Sure, yeah. But does it save you time in the long run? Absolutely. Right. And so that's our approach. Is there an example that comes to mind of a product you build at Rippling or Coinbase of just, it could have been this really simple MVP and then ended up being like, no, we did the right thing by building it further along the spectrum.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.