We scan new podcasts and send you the top 5 insights daily.
Care.com's new CEO paused new feature rollouts for 18-24 months to address a "very outdated" tech stack. This "infrastructure era" focused on replacing the entire backend—from authentication to payments—to enable future speed and innovation, despite the painful short-term slowdown.
Aiming for complete feature parity between an old and new system is a trap. It forces the business to halt innovation for an extended period, and by the time the 'perfect' replacement is ready, the market has moved on, rendering the new system already outdated.
From an executive viewpoint, a key realization is that technically outdated products are often "printing money." While teams want to modernize, senior leaders must balance this with the inconvenient truth that these highly profitable legacy systems fund the company's future bets.
Founder-CEO Kristo Kärman believes the company with the best infrastructure will win long-term. He is committed to reinvesting billions into the platform to build an unassailable advantage in speed, cost, and reliability, even if it depresses near-term margins.
While engineers manage technical debt, leaders often ignore its business equivalent: process debt. Bloated, outdated workflows can stall even the best products. Simplification and consolidation are often faster levers for growth than shipping new functionality.
To get executive buy-in for technical debt work, visually demonstrate how it blocks high-value future features. Present it as a choice: we can do this necessary refactor now, or we forfeit the ability to build the things that will make us money later.
Don't let technical debt accumulate until it cripples your ability to innovate. Product should proactively treat it as a feature to be prioritized. Use natural lulls in the product cycle to pay down debt, ensuring you can move fast when the next big market opportunity arises.
To keep pace with rapid AI advancements, the company intentionally operates on a two-year horizon for its technology stack. This forces them to be dynamic and adapt to new research, rather than getting locked into outdated architectures, having completed four such evolutions so far.
The mantra "don't be married to features" is insufficient. Product leaders must now be willing to abandon entire underlying architectures if a new approach allows for significantly faster value delivery. This may require pausing roadmaps to re-platform, a risk worth taking for long-term velocity.
To transition to AI, leaders must ruthlessly dismantle parts of their existing, money-making codebase that are not competitively differentiating or slow down AI development. This requires overcoming the team's justifiable pride and emotional attachment to legacy systems they built.
To justify pausing feature work at TripAdvisor, the product team got buy-in by clearly framing the long-term problem it would solve. They also appeased engineering by reallocating their time to tackle technical debt that was directly related to the future North Star, ensuring valuable progress was still being made.