Vijay Iyengar

If you are the leader in some core product, our takeaway here is you should continue to out invest everyone else in that core and then invest the profits that come out of that core into the next venture. Invest profits and not people, or venture capital, which is maybe net present value of profits or something to that effect.

The issue for us at the time was that we took people away from the investment in our core product to go do those other things. We moved people, right? And so the trap there is that you leave yourself ripe for disruption in your core because someone else can out invest you in that core.

There's not that many people that need the sixth best CDP or the eighth best feature flagging or the 10th best message targeting tool. And it ends up being, in aggregate will contribute five to 10% to your revenue, won't seriously accelerate your growth rate, and then takes engineers away from the core product.

What this created was this culture where all engineers and designers could consume that raw feed of direct points of customer with no gatekeeper, no process to access it, no pre-aggregation, right?

Engineers will go into that channel and react with a message with an email emoji, which means I'm going to email this customer and find out more, right? And they'll just email the customer and say, 'Hey, I'm the engineer that built this feature. I saw you said this specific thing. Can you tell me more? I'd love to understand.'

You can't mow your lawn while your house is on fire. You kind of put out the fire and then deal with everything else.

It's also 10x more painful than you think to cut mild successes than anything else, and just organizationally painful. And there's teams that have whole roadmaps, and it's a really painful experience, so you have to think really hard before you kick those off.

I think the core problem with estimation is you're asked to estimate things before what the thing is, and it's just a strange output to be expected to produce.

I think the biggest mistake is setting up analytics using client side SDKs, client side tracking. So, web and mobile SDKs, putting a mixpanel.track or segment.track in your web app or your mobile apps.

What we recommend instead, and that we've seen a lot more customers adopt recently is just track events from your servers instead of your clients. And that has three benefits. One, it's instantly cross platform. Web and mobile and TV and whatever other platform, they're all going to go through your servers, so you instantly get a hundred percent reach.

Engineers have been tracking events from servers forever. It's called logs, right? And events are just logs where they user ID in them. And so they don't need to deal with learning a new SDK and dealing with all of that.

Instead of making the estimate an output of planning, you make the time box or an appetite the input, and you say, 'We want to solve X problem and we're willing to invest six weeks solving that problem.'

Pick a reasonable sounding appetite and just explore the two to three options around it. Pick six weeks, and then say, 'What would we do differently if we only had four weeks or eight weeks?' And you'll kind of naturally find the efficient frontier of cost and impact.