Case Study Bundle

📈 From Manual Workaround to >30% in Total Annual Contract Value

Jump to: The Situation · My Role · What I Did · The Outcome · Hindsight

How I turned a scaling problem into a product and made it a tool for renewal.

THE SITUATION

Bundle—a virtual soft skills training B2B2C startup—was manually supporting 20+ custom learning program configurations; a stopgap that worked at small scale but couldn't survive the hyper growth trajectory. As customer demand for hybrid programs increased, the internal team faced a compounding problem: say no to customers (renewal and acquisition risk), or absorb an unsustainable operational support load (profitability risk).

We were already doing the latter. Account managers were selectively qualifying customers because the support burden was too high. That meant we were suppressing demand we hadn't yet built the capacity to meet.

The manual programs were also our proof of concept. They were working. Customers who had them wanted to renew them and the user experience aligned to customers’ own L&D programs. That told us we weren't betting on an unproven idea. We were betting on whether we could build what customers and users already valued at a scale the business could actually support.

Diagram of the hybrid learning program variants

MY ROLE

End-to-end product ownership across discovery, design, engineering, launch, and post-launch adoption while empowering my product team to support launch execution. I coordinated product, engineering, design, account management, customer success, and the executive team, and I managed the strategic tension between what customers wanted and what our internal strategy team believed we should build.

WHAT I DID

Reframed the manual backlog as a beta test.

Rather than starting from scratch in discovery, I worked with the account management team to map why each of the 20+ permutations existed and what customer need it actually served. This gave us a validated research foundation that compressed discovery time and reduced launch risk. We weren't hypothesizing demand—we were codifying it.

De-risked design before engineering touched it.

I built Figma mockups and ran them through two validation layers: first with account managers who knew the customer context deeply, then directly with customers. The goal was to confirm that our design direction mapped to why customers had originally created custom programs, not just what they'd asked for on the surface.

Held position under internal pressure.

The strategy team pushed back, and their concern was legitimate. Hybrid programs loosened the structured, measurable learning framework that anchored our flagship product. I held the position that the business case was stronger: customers were pulling us in this direction, and the alternative was ceding that segment to a competitor who would say yes. Activate our target audience now and iterate deeper engagement as we learn more because the customer signal outweighed the internal preference for control.

Made a deliberate MVP tradeoff.

I scoped the MVP around the end-user experience and program setup. I deferred admin reporting, trainer tooling, and lesser used variants (V3 and V7 in the diagram above) that we couldn't fully automate without diminishing returns. The deferred experiences remained on a managed manual path—a known trade-off, not an oversight—while I validated the core experience first.

Engineered a surgical migration.

Working with customer success and account management, I designed a transition plan for our initial cohort of ~10 existing manual-program customers. The requirements were strict: zero user experience interruption, zero data loss, and retention of existing admin reporting. Each migration was messaged as a customer experience enhancement, not an infrastructure task.

Turned launch into a pipeline event.

At launch, we immediately identified a dozen more customers who had been held back from hybrid programs because of the manual overhead. Post-launch, that constraint was gone. The new product SKU became a renewal tool giving the team something concrete to offer customers at contract time: a product that had been built around how they actually wanted to work.

THE OUTCOME

MetricResult
User adoption at 12 months36% of all active users on the new SKU
Renewal rate34% tied to hybrid-eligible accounts
Total annual contract value~30% (scaled from ~10% supported manually)
Pipeline unlocked immediately~12 additional customers identified at launch
Internal manual supportReduced to ~40% of prior load

Adoption Curve   % of active users on the hybrid learning SKU

Chart of the percent of active users on the hybrid learning SKU over time

May 2025: Launch. New hybrid learning SKU goes live. First ~10 customers migrated from manual programs.
Nov 2025: Coaching add-on. New 0→1 coaching product built on the SKU's systems-designed structure to expand the addressable base and accelerate adoption.

HINDSIGHT

I built the MVP for the end user first. It was the right call for adoption because customers identified ROI as qualitative feedback from senior/influential individuals’ training satisfaction versus in-depth program impact metrics. But when I returned to build admin reporting and the trainer management experience, I had to rethink foundational elements that hadn't accounted for certain user states and calculations. In retrospect, I would have mapped the full system more comprehensively—user, admin, trainer—before writing any spec. I didn't need to build everything in the MVP, but I should have designed it with that intent.▫