Don’t Bundle

A few months ago I was at the drawing board with our product team. We were sketching out what the roadmap for the next few months will look like. I asked about a feature I was keenly awaiting — a new metric for our analytics dashboard.

I was told that building it could be done in a few days, but there was a catch. The dashboard itself is starting to feel like a crowded subway at rush hour—it needs a redesign.

Suddenly, a voice piped up: “We shouldn’t bother building the new metric for the old dashboard. Why don’t we wait for the redesign and then launch that and the metric together?”

On the surface, it sparkled with efficiency. Why embed a new metric into an aging design, only to revamp the whole page later, metric included? Woudln’t it be wiser to do it all in one fell swoop?

However, I was leaning towards a “no”. How come? Because this path, as alluring as it seems, is often a rookie mistake. Let’s delve into why.

A bundle of troubles

Bundling tasks together is like Frasier and Niles planning a dinner party: it starts out simple enough but can quickly spiral out of control. Adding the metric might be a quick fix, a matter of days. The redesign, though, is a longer journey, perhaps a month. Bundle them together, and the metric’s debut is suddenly a month away, not days. You’re now faced with explaining to your audience and higher-ups why this ‘simple’ metric we promised is taking so long to deliver.

Bigger projects also translate into more risk. Amidst the redesign, you could stumble into a maze of challenges: unresolved product questions, data migration issues, documentation, new components needing birth and nurture, lengthy QA cycles, and more. Each detour pushes your shiny new metric further and further down the calendar.

This phenomenon has a name in tech lore: Yak Shaving. You set out to build a feature, and a month later, you find your team knee-deep in seemingly unrelated tasks.

Embarking on the bundle journey is like boarding an express train — you’re on it for the long haul and it’s often impossible to get out. The design and code of both features become entwined, inseparable. Deciding to uncouple them later? That might require a golden fleece of its own.

In the startup arena, where I spent most of my career, rapid iteration is your secret weapon—your only weapon, really. It’s what sets you apart in the league, your ability to dart and dash. While you’re tied up in the bundle, you miss out on vital feedback loops. When you eventually release the metric, you might find that nobody cares. Worse, your entire dashboard might be greeted with yawns. By bundling, you’re blindfolding yourself to these critical insights for precious weeks.

Data > efficiency

Releasing the metric first, then marinating in the redesign phase with a richer dataset, is akin to building with a blueprint rather than a hunch. Yes, it may take longer overall, and you may end up rebuilding pieces you’ve just recently introduced, but that month of user feedback is worth its weight in gold.

Is it ever prudent to bundle? Maybe, particularly if one element serves as a foundation for the other. Yet, take a moment to reflect: Is bundling truly inescapable? Now, entertain a different strategy: what if we flip the script? Initiate with the redesign, gather insights from this phase, and then, with a more informed perspective, roll out the metric (or even do something else). This approach could still be slow, but will offer a richer tapestry of data to inform our next steps.

In sum, sidestep the bundle temptation. Embrace incremental, iterative releases. Prioritize data and feedback—they’re the compass and map for your journey. Better to tread cautiously on the right path than sprint down a winding road leading nowhere.