Dharmesh Shah: belief

Transcript context

…I love this. The algorithm for seating is a good example of this. Is there any other examples, either in the product or strategy, where you pushed for simplicity and that ended up being right? Yeah. So on the product side, in the early years, and Brian gets credit for the actual implementation of this. So we had a relatively broad product, and we can talk about that, pros and cons of that even in the early years, but we were solving for simplicity, and we got this from Apple, we can talk a little bit more about genesis of this, but we had a rule in the HubSpot product as the product grew in those early years that every time you added what we thought of as a knob or dial, called a feature, you had to take one out somewhere else. That's a net amount of... And this is a very coarse measurement. It's like, "Okay, well, not every radio button, checkbox, drop-down, whatever menu item that you put in your nav is necessarily equivalent, but it's better than nothing. It's better than having no constraints. And so once again, this goes to the binary thing, it's like it just at least forces you to think about it, versus the... The other mistake I think people make in product all the time is that we measure the cost of a feature based on the, usually, or even a new product, based on the cost of implementation. That's the first-order thinking, it's like, "Oh, it's going to take six months to develop, it's going to be Y engineers and Z designers or whatever." Second-order thinking is thinking through the maintenance of that feature. It's like, "Oh, it's not just the first version that goes out, it's like now we have this code base and we have to support and improve or whatever." I get that. The third-order thinking, which I think is the most nuanced, and it turns out to be the most important, is the other costs that complexity adds. Okay, we'll come back to this. So when you go from product number one to product number two, it's like, "Okay, product number two is going to cost us this much to develop, it's going to have this risk associated with whether it's successful or not, all these things. So there's going to be this carrying cost for product number two." What companies don't think through is that that is... And the maintenance of that, it's like, "Oh, we're going to need a team to maintain that new product." No, what actually happens is that now when you go from product one to two, you have added dimensional complexity to your business. What I mean by that, it's not an incremental increase like, "Oh, we went from one to two," it's like, now every decision you make has to be made through the lens of, "Now we have two products. We just hired an engineer, do they work on product number one or product number two? We're going to launch a marketing campaign. Do we spend five minutes talking about product number one and two minutes talking about product number two? How do we do anything?" Every chart you look at in terms of the growth, revenue per whatever, it's all of it. Now, every chart that you ever had now has to be sliced by product one and product two in order to really capture that precision. look at in terms of the growth, revenue per whatever, it's all of it. Now, every chart that you ever had now has to be sliced by product one and product two in order to really capture that precision. And so now you have this new dimensional complexity that you just hadn't planned on. And this applies, once again, every level of abstraction. So everything you do in your business should factor in the long-term cost of that complexity. And it should be worth it. Of course, you need, and I can make the case that you need to build product number two and product number N, N plus one over time, but you should be mindful about the cost of that complexity. [inaudible 00:43:39].…

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