Three-Year Build, Nine-Month Ship

October 2016. Unitymedia was 3+ years into building a cloud-based B2B communications product — and it still hadn't shipped. The VP of Product brought me in with a two-option mandate:

Launch the product. Or come back with a different approach.

That framing told me more than any brief would have. The sponsor already suspected the product wouldn't launch in its current form. He wasn't asking for optimization. He was asking for a judgment call.

The external problem was simple. B2B cloud telephony was becoming table stakes in the German market. Unitymedia had a coverage footprint, a B2B customer base, and a compelling case to enter the category — but no shippable product.

The internal problem was the kind that kills more products than any market force ever does. Engineering insisted on building it themselves. The product manager kept optimizing. Both sides were doing what their incentives rewarded — engineering was demonstrating capability, product was perfecting the spec — and together they had built a system in which neither side was responsible for actually launching.

Three years of effort. A product that could be described in detail but could not be sold.

The technical answer was obvious to anyone outside the team: integrate a vendor. The political answer was not.

Convincing central units — Liberty Global's B2B governance, including the B2B CTO — that a three-year internal investment should be wound down and replaced with a third-party core was the real work. Every month of that work meant another month of no product in the market.

We chose Voiceworks as the vendor partner. Over nine months, we ran the full stack in parallel: negotiated and signed the Voiceworks contract; stood up operations (not without friction — operations integration was the hardest part of the programme); integrated the Voiceworks core into Unitymedia's IT systems for sales and support; and kept the original internal-build team informed and, where possible, redeployed onto the integration work.

Billing integration was the one piece we couldn't deliver in the nine-month window — and the way we handled that is the part worth paying attention to. From day one we had all the usage data. What we didn't have was automated invoicing against flat-rate contracts. So rather than hold the launch, we turned the three-month gap into a commercial move. The base fee was free for early customers through the billing-integration window, while excess usage beyond the flat-rate scope stayed billable and was captured explicitly in the contracts. Customers knew exactly what the deal was. Sales had an acquisition incentive they wouldn't have had otherwise. Finance had a three-month close-plan agreed up front.

What could have read as “they shipped something incomplete” read instead as “early-adopter window for customers who move fast.”

1. Over-engineering is rarely an engineering problem. It's a governance problem. When engineering and product both optimise for their own definition of quality, nothing ships. The job of senior product leadership at that point isn't to ask for more optimisation. It's to change what the team is being asked to do. Sometimes the best product decision is to stop building your own.
2. Constraints become features when you design around them consciously. The billing gap we couldn't close in time wasn't a compromise we hid; it was a free-base-fee window for early adopters, with excess usage still captured commercially and a finance-agreed close plan attached. The gap you can't close in time is often the lever you didn't know you had.
3. The first install is part of the product. Not a metaphor: the first paying customer went live at month nine, and the install happened by train, in person. Launches happen because someone specifically walks a specific customer through the door. The earliest customer-facing motion is where the launch is finally distinguishable from the project.