New Product Introduction: Building a Product Function from Nothing

I joined a regional broadband altnet as Product Lead, contracted through my own consultancy, and moved into Head of Product, Growth and New Products about four months in. The business sold connectivity across fixed wireless and fibre, into rural and semi-rural areas the larger operators had been slow to reach.

The existing portfolio had clear drivers and I want to be accurate about that. Fixed wireless was how the business started and was the founding model, with several options running on their own network. The fibre build came through government-backed programmes under BDUK, again with a range of options, and there was a VOIP service alongside it. None of that was an accident, and characterising the business as launching things on a whim would be wrong.

What did not exist was a repeatable way to introduce anything new. The business was sales and marketing led, so anything outside the established portfolio arrived through commercial appetite rather than through a process that established who it was for, what it would cost to run, and what had to be true operationally before it could be sold. There was no roadmap anyone outside a small group could see, and no route from an idea to a live service that worked twice.

That produces two failures and both were present. Products go live before the operational detail is resolved, so support and provisioning pick up the cost of the gap afterwards. And parts of the business that touch a product without owning it, billing, support, the supplier relationships, end up carrying assumptions nobody checked.

The second turned out to be more expensive than anything on the roadmap. Consumer VOIP had no owner once a customer was set up in the portal, so nobody was checking what happened when one left. We stopped billing them, correctly. The service with the upstream supplier was never cancelled, so we kept paying for it, and where handsets and equipment were on rental we kept paying that too, for people who were no longer customers. That is covered properly further down, because it is the clearest argument in this entry for why the business needed a product function at all.

The complication underneath all of it was resourcing rather than structure. I was the product function, so that part was covered. The supporting roles the process needed were filled, but the people in them had neither the spare resource nor the time that a new product introduction asks for, and nobody's objectives mentioned it, so what I was asking for was additional to the job they were actually being measured on. A new process arriving from someone brought in on a contract is easy to deprioritise without ever refusing it. I had to earn the trust and build the relationships that made it work.

The framework was the actual deliverable. The problem it solved was not documentation. It was that the people who needed to act on a new product found out too late to do anything useful, and the people deciding what to build had no visibility of what that decision cost elsewhere. So it was built around getting every stakeholder in the same place, keeping it current, and making feedback standing rather than something that happened when a launch went wrong. It was documented visually, with slides rather than dense specifications, because the audience spanned engineering, provisioning, support, sales, marketing and finance, and a document only product people will read is not a stakeholder tool. I ran regular bi-weekly sessions with the stakeholders and asked support and sales to be part of the feedback loop, so the people closest to the customer fed in continuously rather than only when a launch had already gone wrong.

Roadmap visibility was tiered. Twelve months visible across the organisation so teams knew what was coming and what would be needed from them, twelve to eighteen months to senior stakeholders only, and the strategic layer under weekly review rather than fixed quarterly. That cadence was a response to reality rather than a preference. The organisation changed direction regularly, and a framework that assumes a stable twelve-month plan breaks the first time leadership changes its mind.

Doing it without the supporting resource. It ran on trust rather than authority, and trust took time. I was the product function, so that part was covered, but the supporting roles the process needed were already at capacity and nobody's objectives mentioned new product introduction, so what I was asking for was additional to the job they were being measured on. I wore a lot of hats early, doing parts of the work myself that should have belonged elsewhere, because demonstrating what was needed was faster than explaining it. The 4G relaunch was the first through the framework, and that first launch was deliberate proof of concept: once it existed, every future ask came with something tangible behind it instead of a slide. It compounded. Each launch ran more smoothly than the last, because it became clear what the process needed, what I needed from each team, and what they got back for it. The outcome I would point at ahead of any individual launch is that the business went on to create a Director of Product role. It did not exist when I arrived and would not have been created if the concept had not been proven and the organisation brought along with it.

Helping a launch I did not own. The PMO was launching a 1Gb fixed wireless service with many stage gates and a team unclear on what they had to do at each one. I put it on the roadmap so it was visible alongside everything else, brought the stakeholders together, and worked with the PMO team leads to refine some of the gates and add the detail between each, taking my high-level requirements and filling in what I was unsure of so it was clear to everyone what was needed, by whom, by what date, and what outputs each gate produced. I pushed collaboration as the operating principle rather than sequential sign-off. Then I handed it back once it was moving, because the PMO had their own engineering build process with dedicated resources assigned, and I had the next value-added services to launch.

Five launches in eight months. A consumer cyber security offer built on F-Secure and embedded in the router firmware, partially automated through Salesforce with activation blocked until a firmware change at the vendor completed. Because it attached to connections that already existed, it lifted ARPU, the figure the business watched most closely, without needing a new customer to sell it to. Openreach SoGEA and FTTP, extending the footprint beyond the areas the business had built to. A 4G fixed wireless service relaunched in two weeks, which is not a claim about engineering speed but what happens when the product question has already been answered. And a new router platform.

The supplier decision I lost, and what it cost. When I researched the off-net route, my recommendation was BT Wholesale. Not on price, but because it gave direct access to Openreach engineers, far more detail per premise before we committed to an order, and end-to-end UPRN address checking built in rather than bolted on afterwards. For a product whose entire proposition is that we can serve an address we do not own the infrastructure to, knowing what is actually at that address before selling it is not a nice-to-have.

We went with the incumbent supplier instead, for two legitimate reasons. There was an agreement in place at executive level between the two companies. And the commercial rate we already held was better than BT Wholesale could match, even though we were already a BT partner for leased lines. That mattered because the go-to-market was built on discounted services to win customers, alongside lifting ARPU afterwards, so the input cost was doing real work in the model. I did not think it was the wrong call commercially. I thought it carried a risk that was not being priced, and I said so to leadership before we launched.

The risk landed. Some addresses came back through the portal showing a strong sync speed that the line could not actually deliver. Some had nowhere sensible to install the equipment despite the portal saying the address was fine. It was worse on SoGEA than on FTTP, though FTTP was not immune. Low speed became the main driver of complaints and of cancellations.

The second-order problem was hardware. A cancellation meant a router sitting at an address with no process to get it back, so it was simply lost. I built an automated recovery for that: an API check against the connectivity portal, and if an order had not reached live status inside a set window, it triggered the router supplier's returns process automatically. It does not fix a bad line, but it stops a delivery failure becoming an inventory write-off as well.

I would rather record this than leave it out. The instinct in a portfolio is to describe the decisions you won. This one I lost, for reasons I understood, and the useful part is that the mitigation was built before anyone asked for it because the risk had already been named.

The router platform was a product decision, not a procurement one. Moving from the incumbent halved the per-unit cost, and brought unified cloud management so support could see a connection come up rather than working blind. Every unit carried gigabit throughput as a minimum and some multi-gigabit ports, raising the ceiling on what could be sold over the same connection. The vendor offered a comparable consumer security service to the one we ran on the incumbent firmware, so the cyber security proposition survived the move. It had not quite been available at the time of the router launch, but it was close, and the product and go-to-market work to enable it was already done. And because the same range covered on-net and off-net fibre and SoGEA alongside 5G, we could position 5G as backup against a fixed line, which opens remote workers and anyone needing resiliency as a segment rather than treating mobile as a last resort. We scoped and tested 5G units, and the internal one mattered commercially because the external units needed an engineer to mount them, where the visit costs considerably more than the device. I was also researching Ubiquiti for a business unit, because neither platform fully supported active-active connections, only active-passive failover, and for a resiliency proposition that distinction is the product rather than a detail.

The honest complication is that this did not replace the incumbent. A prior commitment to a large volume of units meant both platforms ran in parallel, and the new units did not natively support off-net Openreach connectivity without manual configuration, so we built a process for that and ran it alongside. Nobody would design that. It is what a prior commitment leaves you with, and the job was making it work.

Automating order to live service. A customer enters a postcode, a UPRN API checker from ThinkBroadBand confirms service at that specific address rather than that general area, and the sales journey proceeds to a website order. We had enabled that checker ahead of time, and their mobile broadband API alongside it, so the same address check could be extended to 4G and 5G when those services launched rather than being rebuilt later. Router ordering had been manual, one customer at a time. I led the team that worked with the supplier's portal API to automate it end to end, with the same API registering the unit in the management platform so a router arrived already visible to support. The remaining manual link was a daily report to the connectivity supplier, only manual because their portal could not yet take it. We stayed inside their development feedback loop rather than waiting, and the point I pushed hardest was address-level UPRN checking, which they had not planned to include. That was still an open conversation when I left rather than something landed. Alongside it I researched an API approach to tie UPRN data to the Openreach network and to mobile coverage for 4G and 5G, so availability could be confirmed at a specific address. Research and design, not implemented before I left.

The next roadmap item was mobile voice and data across EE, Vodafone and O2. We were working with the same supplier on their API to enable mobile voice ordering after the 5G launch, but it was not complete against their Abillity billing platform, so voice stayed a roadmap item rather than something we could put live.

The refurbishment loop. Every churned customer had a router going nowhere. I found and engaged a UK partner who could automate collection, inspection, grading and reissue, with low-graded units going to recycling so it sat inside the environmental commitments the business already had. The argument that made it viable was reuse: the partner would run the same automation we had already built, making it an extension of existing workflows rather than a new project. I designed it, scoped it and presented it, and it was not taken forward at that point. It stayed on the roadmap, waiting on an unresolved decision about the router estate: add Eero, stay as we were, run both, or renegotiate with the incumbent.

The one that was not a product launch. Consumer VOIP was effectively unmanaged once a customer was set up in the portal. Nobody owned it after that, so nobody checked what happened when a customer left. We stopped billing them, correctly. The service with the upstream supplier was never cancelled, so we kept paying. Where handsets and equipment were on rental, we kept paying that too, for people who were no longer customers. The fix was matching supplier accounts against Salesforce records, not building anything. I helped kickstart it and worked with the stakeholder who owned that area, and what I contributed that they could not was leadership backing, because I could show senior people a part of their own business they were unaware of. It was not a hard problem. It was an unowned one, and unowned problems do not surface on their own.

• New Product Introduction framework built from nothing: stakeholder structure, standing feedback, visual documentation, and a tiered roadmap with twelve months visible organisation-wide and twelve to eighteen months to senior stakeholders, with the strategic layer under weekly review
• Twelve to eighteen month roadmap spanning broadband, fixed wireless, 4G and 5G, mobile voice and data, cyber security, VOIP and value-added services, managed through Jira
• Five product launches in eight months: a consumer cyber security offer, Openreach SoGEA, Openreach FTTP, a relaunched 4G fixed wireless service and a new router platform
• A consumer cyber security offer sold onto existing connections, lifting ARPU without needing a new customer to sell it to
• Wholesale supplier evaluation recommending BT Wholesale for Openreach engineer access, per-premise survey detail and built-in address-level UPRN checking, with the delivery risk of the alternative set out to leadership before launch
• Recovery automation for stranded routers: a portal check that triggers the supplier's returns process automatically once an order misses its live-status window
• Router platform business case and migration: halved per-unit cost, unified cloud management for support, pre-built configuration shipped by the vendor, eight months of free platform use and training, and partner pricing among the best given to any UK partner
• 5G hardware scoping and testing across external and internal units, with the internal unit removing the engineer visit that 4G installs needed and widening the addressable customer set
• Manual configuration process for off-net Openreach connectivity on the incumbent hardware, run alongside the new platform to honour an existing large-volume commitment
• End-to-end order automation: UPRN address checking into the sales journey, website order, Salesforce capture, and full API automation of router ordering and management platform registration, replacing a manual per-customer process
• Research into an API approach tying UPRN address data to the Openreach network and to mobile coverage for 4G and 5G. Research and design, not implemented before departure
• A collection-to-recycling loop for returned routers, built with a UK partner on top of automation already in place. Presented and scoped, parked against an unresolved decision on the router estate
• Consumer VOIP leakage identified, escalated with leadership backing, and supported through record matching between supplier accounts and Salesforce

• Changed how new products were found, prioritised and launched, with a function behind it where there had been none
• A permanent Director of Product role was created off the back of it, a position that had never existed there before
• Four products built from nothing and a fifth relaunched inside a fortnight, all within eight months
• Reached customers the owned network could not, through Openreach SoGEA and FTTP, and that pipeline carried the business through at least one month when on-net sales fell
• Flagged in advance that the cheaper off-net supplier lacked the engineer access and address checking the alternative offered. The business went with the existing relationship, and the gap showed up afterwards as inaccurate speed reporting and installations that would not work
• Had the safety net ready before it was needed: a time-boxed check that pulled stranded hardware back into the supplier's returns process automatically, rather than writing it off
• Extended the same approach outside my own roadmap, helping the PMO clarify the requirements behind the stage gates on a 1Gb fixed wireless launch and getting the wider teams collaborating, then handing it back once it was moving
• Halved the per-unit router cost across new connections, added unified cloud management so support could see a connection it previously could not, and gave the business a credible alternative when the committed order with the incumbent came up for replenishment
• Replaced manual per-customer router ordering with full API automation, including automatic registration into the management platform
• Grew ARPU, the metric the business measured itself against, by selling more into customers already connected rather than chasing new ones alone
• Spotted a VOIP billing gap nobody owned: customers stopped paying when they left, but the upstream service and equipment rental kept running regardless
• Framework adopted beyond me, with the B2B business development manager running the business VOIP supplier engagement through it

How it ended. My contract came to an end, and bringing the role in-house on payroll would have placed it at a director or senior leadership pay scale that was not budgeted. The business has since gone into administration and been acquired, with most of the organisation made redundant. That is not a story ending in a thriving business and pretending otherwise would be dishonest. What is fair to claim is that the off-net pipeline broadened the addressable base and lifted revenue beyond what the owned network would have produced on its own, and that the value-added services lifted ARPU, the main KPI the business measured itself against. Whether either influenced the acquisition I cannot say, and the administration is not mine to explain.

On the VOIP finding, the detailed remediation belonged to the stakeholder who owned that area. My contribution was spotting it, escalating it, and getting leadership visibility of a part of the business they did not know was costing them money.