Claude in Practice: A Product Manager's Field Report on Six Months of Working with Claude

I lead broadband product management for a telecom and broadband provider. Over the past several months I've set aside time each day to work through different workflows and activities with Claude — deliberately changing my own habit to consult Claude first — partly to get real work done, and partly as a structured way to understand how the product management role, and my team's workflows, need to change as these tools mature. This is a generalized account of that work, spanning broadband, fixed-wireless, and connected-devices, organized by the kind of PM work it represents rather than by when it happened. I've generalized the company- and project-identifying specifics throughout, since the underlying work is proprietary, but kept the substance of each example intact — particularly the hardware and connected-services integration work, which I think gets written about far less often than typical software PM work, and which I hope is useful to fellow product managers and product leaders regardless of industry.

If you've already read one of the many “AI tools for product managers” round-ups this year, this isn't quite that. Most of that content is written from a software-product vantage point — PRDs, sprint summaries, prompt libraries. My day job is broadband, fixed-wireless, and connected hardware that delivers those services, so the work below runs through patent claims, RF antenna placement, and chip power budgets about as often as it runs through product requirements — and it includes a section, further down, on where Claude got things wrong, which isn't the usual framing for this genre either. I primarily used Claude because it was the default at my work, but I found it convenient enough to get a Pro subscription for personal use. Based on my sporadic use of other Gen AI tools, I find the lessons equally applicable to them as well.

Before the Real Work

My first deep, sustained sessions with Claude weren't work at all. Before trusting it with anything real, I ran two personal projects: a karaoke app for Hindi songs (extending later to other Indian languages) that searches YouTube and other sources for sing-along videos and ranks them by whether they're a true lyrics video, a karaoke track, or just the plain song; and a two-player traditional strategy board game with full rule validation, an adjustable-difficulty AI opponent, and genuine peer-to-peer multiplayer. Neither had anything to do with my job. Both were a deliberate test of whether Claude could take a rough idea all the way to a working, deployable product — and both shipped as real, runnable code with setup instructions. Once I'd seen that on something low-stakes, I had an actual basis for trusting it with the higher-stakes work that follows.

At a Glance

Category	What it covers
Daily research & reporting	Competitor/industry tracking, a self-updating dashboard, recurring email-to-summary skills, conference and stakeholder prep
Building & prototyping interfaces	A consumer app redesign taken to an interactive demo and a competitive UX teardown
New-product solution architecture	Early-stage network architecture for new service tiers, an internal proposal document, a market strategy that became an executive deck
Hardware feasibility & engineering	Power/thermal/RF budgeting for new device form factors, regulatory certification mapping, product-vs-operations feasibility calls
Network operations & CX diagnostics	Access-network architecture literacy, field triage tooling, device compliance test cases, NOC org design
IP strategy support (generalized)	Reviewing counsel's drafts, claim-scope strategy, patent drawing QA, cross-border filing research
Where I caught issues	Verifying AI-drawn diagrams and competitive research against primary sources, pushing for complete reviews over partial ones, correcting architecture assumptions with probing questions, and catching a couple of unstated defaults
Role & team implications	Communicating intent faster across CX, engineering, commercial, and executive teams; the vendor chip-documentation gap and the case for vendor MCP access; why hands-on trial beats reading about a workflow

1. Daily Workflows: Research, Monitoring, and Recurring Reporting

The bulk of day-to-day PM work is research and synthesis, and this is where Claude paid off most consistently. A quarterly competitor-tracking tool started as a simple question — which operators to watch and when their earnings land so that I can compare against those of my employer that is going IPO shortly. That work quickly became a self-updating dashboard covering major carriers across the US, Europe, and India, plus satellite broadband as its own category, with region-scoped data fetches, ARPU/ARPA-aware metrics (since operators disclose these differently), and qualitative summaries of what's actually driving each company's subscriber and revenue trends, sourced from earnings calls and analyst commentary rather than invented or interpreted by data alone.

A related build — a persistent, de-duplicated news dashboard spanning broadband technologies from fiber to satellite, and both the wide-area and in-home side of the experience — is worth mentioning for how it went wrong before it went right. Three different architectures failed for the same underlying reason (network restrictions in the hosting sandbox), and each failure taught something the next attempt used. That's a realistic picture of building tools with Claude: iteration through failure, not a single clean pass.

The most quietly valuable use case has been recurring reporting. I built two custom Claude skills that each read a different set of weekly internal report emails and turn it into a structured summary or matrix automatically — one for device visibility across a network, one for a cross-vendor go-to-market status matrix. Neither is glamorous, but they're the clearest “save real time every single week” scenarios I found.

On the research side, a look at telecom operators divesting their media holdings turned into a genuinely useful strategic gut-check — comparing what companies actually spent on media acquisitions against the return they delivered to shareholders, with sourced figures rather than a general impression. And ahead of an industry conference, I had Claude build a full multi-day agenda aligned to specific technical priorities, research the relevant speakers, and draft individualized talking points for the few people I hoped to have an in-depth conversation — compiled into one briefing document I could actually use on-site.

2. Building and Prototyping New Interfaces

A redesign of an existing consumer app started with content, not visuals: digesting the product's actual support/FAQ taxonomy surfaced real information-architecture problems — a single flow (like relocating a connection) duplicated across three different places in the app, and a diagnostics flow that was clearly the most-needed feature but buried two levels deep. That analysis fed directly into a working interactive HTML prototype, complete with a narrated voice-over that was scripted differently for what's shown on screen versus what's spoken aloud, plus a separate 30-second “ad mode” version of the same prototype for stakeholder pitching.

A competitive teardown of a competitor's home-screen redesign is a good example of evidence discipline: the first pass, based on press descriptions, got the layout wrong in several places, and switching to real screenshots caught and corrected a factual claim from the press coverage itself (about where a promotional banner had actually moved). The lesson translated directly to my own product work — verify against the real screen, not the description of the screen. (More on this below.)

3. Early-Stage Solution Architecture for New Products

Several conversations started from “here's a business idea, what would the network actually need to look like” — the kind of early technical-and-business scoping that has to happen before an initiative gets real investment. One worked through what changes a broadband network would need to selectively offer a premium, high-reliability tier over a shared local access point by partnering with a satellite provider — VLAN segmentation, policy-based routing, SD-WAN options, and, importantly, the billing, authentication, and usage-accounting consequences of a traffic path that bypasses the network's normal policy-enforcement point. That last piece is the kind of thing that's easy to miss in a whiteboard sketch and expensive to discover after launch.

Another compared two competing architectures for delivering shared fixed-wireless service into an apartment building — an Ethernet-switch-based model versus a fiber-terminal-based one — then turned that comparison into a full internal proposal document across several review rounds. Each round of feedback caught a real discrepancy between what the document claimed and how the network was actually built (more on this below). Getting those details right mattered more than the eloquence, and Claude was useful for holding the document true to the underlying architecture rather than just making it read well.

A market-strategy conversation about disrupting the smart-home platform space — using device standardization and a partnership to skip building a device ecosystem from scratch — evolved over several sessions into a fully worked flagship service concept built on infrastructure the company already owns, the home router and ended as a sourced executive presentation matching the company's standard deck template.

A smaller but telling moment: reviewing a colleague's devices-strategy deck, I caught that a “this comes at zero incremental hardware cost” assumption for combining routing with camera or voice functions glossed over a real engineering constraint — the silicon that runs vision or speech recognition and the silicon that runs carrier-grade Wi-Fi are different chips, so any such device is really a two-chip integration project, with the cost and risk that implies. Claude helped frame that pushback as reinforcing rigor rather than as a criticism of the author, and it went into the deck as a new slide in the original's own visual style rather than a separate memo.

4. Hardware Feasibility and Engineering Collaboration

A good amount of my work sits at the boundary with hardware and industrial design, and this is where having a thinking partner for fast, specific technical questions mattered most. One thread worked through the power and throughput budget for docking several smart-home accessories (a camera, a speaker, a thermostat, a garage controller) off a single home gateway's USB port — separating what's actually a bandwidth problem from what's actually a power problem. A compressed 2K camera stream, as many of you already know, needs only a few megabits per second even at high quality, while a small speaker needs several watts more than the same port would need to run a thermostat continuously for a year — so the design axis wasn't “which accessories need the most data,” it was “which ones need the most power.” The brief went on to account for a fanless enclosure's thermal limits, the radios each accessory needs to keep, and even the safety-battery-backup precedent already established in the smart garage-door industry — all packaged into a brief and spreadsheet for the industrial design team.

A second thread mapped the regulatory certifications a home gateway and its power accessory need in the US (FCC emissions and radio rules, DOE energy efficiency, UL safety listing, Wi-Fi Alliance interoperability, and California-specific rules), extended that analysis to a PoE-powered variant of the same device, and restructured it into one balanced executive brief treating both power options equally — a good example of turning fragmented compliance research into a single clean reference document for legal and compliance colleagues.

A cluster of narrower physical and RF feasibility questions came up while scoping new device form factors: how much spare capacity exists on a typical wired safety-device circuit, how mesh Wi-Fi extenders and smart TVs budget power internally, where Wi-Fi antennas actually sit inside a TV chassis and why, and — a genuinely novel one — whether embedding a router inside a rotating ceiling fan would meaningfully degrade its Wi-Fi radios (short answer: it depends heavily on blade material and antenna placement, and is a real but manageable design constraint).

A product-versus-operations question tied several of these together: can a renter reasonably self-install a smart light switch (often not, because of the neutral-wire and lease-permission problems), and if not, what technician certification would a national rollout actually require? The useful finding for planning purposes was that electrician licensing in the US is a state-by-state (sometimes city-by-city) patchwork with no single national standard — which changes how a service-operations model for truck-roll installation should be designed from the start.

5. Network Operations and Customer Experience Diagnostics

A cluster of conversations built the kind of access-network literacy that has to sit underneath any product decision touching the last mile. Working through a fiber network's high-level design document clarified why the same physical device carries several different identifiers — a hardware serial number, a service-location ID, a topological port index, and a subscriber session identity — and how those interact with VLAN design and IP-over-Ethernet authentication end to end. Understanding that distinction mattered directly for the solution-architecture work described above.

That literacy turned into two practical deliverables for two different audiences: a field-triage reference — cataloguing the full range of upstream and downstream failure modes an access device can experience, organized by whether the real fault sits in the device, the outside cabling, the central office, or the customer's own home network — built as a spreadsheet for the network operations team; and, reframed for a device-testing audience, a rewritten set of compliance test cases with the handful of tests worth gating a field trial on called out explicitly. A separate, narrower diagnostic thread worked through the likely causes of a short, recurring outage pattern by mapping specific network alarm codes to root causes as a lookup table technicians could use directly.

That same diagnostics work fed directly into an org-design exercise — drafting job descriptions for two new network operations leadership roles (one focused on in-home devices, one on the access network and its northbound systems) meant to build and eventually lead dedicated triage and automation teams. The exercise was also a useful reminder that, at this early stage, “org design” for a brand-new function mostly comes down to recruiting — the deliverable that actually matters is a job description precise enough to attract the right person, not an org chart.

6. Supporting IP Strategy and Precise Technical Documentation

Several conversations supported the patent process on hardware inventions in the optical and wireless access space. Claude helped prepare prior-art comparisons and draft initial patent application content, then, once outside counsel's redraft came back, compare it against the original invention disclosure — checking whether the specific novelty arguments the disclosure was built around had survived the redraft, and catching drafting inconsistencies (an internal contradiction that had been introduced in more than one place, and a broken cross-reference between the drawings and the written description among them).

A related thread worked through claim-scope strategy at a conceptual level: when a patent claim should state a specific engineering value versus a general functional relationship, and what that choice trades off against prior-art risk and future enforceability — useful groundwork before a conversation with counsel, not a substitute for one. I also used Claude across several rounds of patent-drawing revisions (updating figures for clarity, fixing mismatches between drawings and text, adjusting line styles so figures stay legible in black-and-white printing), and to research cross-border patent filing mechanics — foreign filing licenses, rules tied to where an invention was actually conceived, and comparative examination timelines — to help sequence where to file first.

Beyond the patents themselves, Claude was also a useful drafting partner for internal communication that needed to be precise and unambiguous, particularly where something needed to be documented clearly for the record. It's a reminder that careful writing matters as much in a two-line email as in a formal filing.

7. Where I Caught Errors, Gaps, or Quality Issues

Claude was consistently useful, but it wasn't infallible, and a few moments are worth point out — both as genuinely useful lessons for working with any AI assistant, and because catching them is part of the job.

Verify against the primary source, not a description of it. My first pass at reconstructing a competitor's app redesign — built from a written description and press coverage — was plausible but wrong in several details, something Claude itself flagged once I supplied real screenshots. The real comparison then caught a specific factual error that had been carried in the press coverage itself, about where a UI element had actually moved between versions. I now treat “verify against the primary source” as a standing instruction, not a one-off ask.

Check AI-drawn diagrams as carefully as AI-written numbers. When Claude regenerated a pair of technical figures for a filing — a site-deployment map and a performance chart — from a written spec rather than by editing the original files, I caught two real defects on review: supporting visual elements had been placed at decorative positions that didn't actually match the real underlying geometry, and a legend box on the other chart had picked up formatting that broke the intended visual parity between its two halves. Both were genuine mistakes, both were fixed immediately once named, and neither was obvious without a deliberate visual review.

Ask for the full pass, not the convenient one. Reviewing an important document's redraft against my original submission, I had to explicitly push Claude to do a complete line-by-line read rather than the narrower, topic-linked review it had been doing. The full pass caught a real, repeated drafting bug that the narrower review had missed entirely. Claude's default scope is often “enough to answer the question asked,” not “everything you'd actually want checked” — say so explicitly.

Bring the ground truth, and expect the AI to revise, not defend. An earlier architecture recommendation on a network proposal turned out to rest on an incorrect assumption about how a particular identity scheme actually worked in the real deployment. Once I supplied the real operating model, Claude flagged its own earlier reasoning as wrong for the architecture, rather than quietly rewriting around the discrepancy — which is the behavior you want, but the correction only happened because I supplied the real detail rather than accepting the first, more generic answer.

Watch for what wasn't calibrated, not just what was. An early hardware brief calibrated the power budget for a set of connected accessories but not their data-throughput requirements — a gap I caught before we had real component datasheets in hand, and one that changed a design conclusion once we did (the accessory I'd assumed was throughput-bound turned out to be power-bound instead).

Trust your own experience over research alone. Reviewing a colleague's hardware-strategy deck, my own background shipping a comparable multi-function device surfaced a real engineering constraint — that combining a networking function with voice or vision effectively requires two separate classes of chips — that hadn't come up in Claude's own market research on comparable products. Claude is very good at telling you what exists; it's not a substitute for having actually built the thing before.

Question the defaults. More than once I pushed back on a choice Claude made without asking — delivering a working document in a lightweight markup format instead of the polished file format the audience actually needed, for one. Reasonable defaults, not always the right ones for the audience; worth a beat of review before something goes out the door.

8. What This Means for the PM Role and the Team

Beyond the individual workflows, a few broader lessons came out of doing this, deliberately and daily — less about any one project, more about how the product management role and my team's day-to-day work need to change.

Communicating intent, better and faster. The single clearest lesson: GenAI tools like Claude (and Gemini, and others) give product managers a materially better way to communicate intent to the teams we interface with — CX, the different engineering teams, commercial, and executive management. Pushback on a colleague's hardware-strategy deck landed as a new slide built in the deck's own visual language rather than a separate memo; an internal architecture proposal stayed solidly grounded to the real network across several review rounds instead of drifting into prose that merely read well; a market-strategy exercise turned into a sourced executive deck matching the company's standard template on the first real attempt. In each case, the benefit wasn't Claude having better ideas than the team already had — it was Claude removing the friction between having the idea and putting it in the specific form the next team needed in order to act on it.

Training a new person is the same problem as supervising Claude. One thing genuinely bothered me while doing this: if Claude is this good, how do you train someone brand new onto the team? The answer I landed on is that a new hire needs the same kind of apprenticeship Claude did throughout this piece — not fewer corrections because a person is capable, but the same pattern of doing real work, getting it wrong in specific, nameable ways, and building judgment from those corrections over time. Catching a wrong assumption, asking for the full pass instead of the convenient one, probing deeper rather than accepting the first answer — that turns out to be the same skill a new hire needs to build, and the same skill I need to practice teaching, whether the one I'm supervising is an AI or a person.

The vendor-documentation gap — and the case for vendor MCP access. A genuine shortcoming, worth calling out: not having certain vendor chip-spec documents — MediaTek and Qualcomm datasheets, in particular — in a form Claude could work with directly was a real limitation across several of the hardware conversations above. Internal teams and some software vendors have started exposing their own documentation and systems through MCP interfaces, and it made a real difference wherever it was available — accessing that material became as easy as asking a question, rather than a separate research task. At least one chip vendor, Microchip, already runs an MCP server exposing its own datasheets and product data this way — it would be a genuine win for product teams across the industry if MediaTek and Qualcomm followed with the same kind of access to their own chip specifications and reference documentation. This is a capability gap that requires immediate attention from the chip vendors.

Trying it beats reading about it. The last lesson is about adoption, not output. Several of the judgment calls described in this document — when to push for a full review instead of a partial one, when to probe Claude deeper rather than accept its first answer, when a rough prototype beats a polished slide — aren't things I'd have absorbed from a guide. They came from doing the work daily and paying attention to what happened. If you're trying to figure out how your own team's workflows should change, the fastest path is the same one: block the time, and use the tool on real work, not a sandbox exercise.

What I'd Tell a Fellow PM

• Claude is most valuable as a force multiplier on work you already know how to scope. The moments that saved the most time were ones where I had a clear, specific question — not “explore this for me” in the abstract.
• The most valuable output isn't always the answer. Several examples above were valuable because Claude caught a factual error or an unstated assumption — but just as often, it was my own review that caught the error, as the previous section shows. Treat it as a second set of eyes, not just an execution engine, and keep your own eyes on it too.
• For anything customer- or legal-facing — device certifications, patent claims, technician licensing — Claude was best at organizing the landscape and flagging what to verify. Final sign-off still belonged to counsel, compliance, or the relevant subject-matter expert.
• A rough, working prototype moves a conversation further than a polished slide describing the same idea — true both for actual work (the interactive app-redesign demo) and for the two personal test apps that first proved the point to me before I trusted Claude with anything real.
• Small, recurring workflows compound the most over time. The two weekly-report skills look unglamorous next to a patent or an executive deck, but they're the ones that pay out every single week.
• Budget real review time for anything that will be manufactured, filed, or shown to a customer. Every catch in the previous section was cheap because it happened before the diagram, the document, or the deck went out the door — not after.

If you're a fellow PM experimenting with where Claude fits into your own work, I'd start wherever you already feel the most friction — a recurring report, a research question you ask yourself every quarter, or a document that's due for a fact-check against reality. That's where the leverage showed up fastest for me.

I'd genuinely like to hear how this compares to your own experience. What's the sharpest mistake you've caught an AI assistant making on real work? And if you lead a team: how are you thinking about training someone brand new now that the AI does so much of the heavy lifting? Tell me — in the comments, or wherever you're reading this.

The Argument for Open Access in High School

In many high schools—and even in middle schools—entry to certain courses is restricted by "gating rules". These may take the form of minimum grades, qualifying exams, standardized test scores, or teacher recommendations. The intent behind such rules is often noble: to protect students from overextending themselves and losing confidence. On the surface, this seems reasonable. But beneath that good intention lie several flaws.

The Problem with Preventing Failure by Preventing Risk

First, gating policies attempt to prevent failure by preventing students from trying at all. They implicitly teach that risk-taking is dangerous, not rewarding. This message, delivered during the formative years of adolescence, discourages intellectual courage—the very trait that education should cultivate.

The Misalignment of Incentives

A deeper issue is the misalignment of incentives. In most decisions, those who make the choice also bear the consequences. Here, however, administrators and teachers decide who may enroll, but it is the students who bear the cost of exclusion. Worse, the negative consequences of denying access are nearly invisible. When a student is turned away, we rarely see what opportunities were lost or how their academic path might have changed. The result: the decision-makers’ incentives and the students’ outcomes are misaligned.

A Thought Experiment

Consider a thought experiment. Suppose we have 100 students to divide between a standard and an advanced course. Whatever the criteria—grades, tests, or teacher judgment—we set a threshold. Now, imagine a group of ten students, each with a 50% chance of succeeding in the advanced class. If all ten are admitted, we’d expect about five to succeed on average. But probability theory tells us that in any given year, that number could vary between three and seven.

When only three succeed, administrators and teachers must support the seven who struggle or transfer them to other courses—creating significant extra work and stress. When seven succeed, however, there’s no crisis, no meeting, no parent complaint—just quiet success. Because the negative outcomes are loud and memorable while the positives are silent, people recall the failures more vividly. This is availability bias at work.

How Availability Bias Shapes School Policy

This bias causes educators to overestimate the likelihood of failure. To avoid future turmoil, they raise the bar: increasing the threshold to admit only students with a 75% or 90% or even 99% predicted chance of success. Even at 90%, as many as two students could fail. It's only at 99% that one can get closer to certainty! The higher the threshold, the fewer students fail—but also, the fewer ever get the chance to stretch themselves.

The Cost to Students

This risk-averse approach carries a hidden cost. At the 50% threshold, five out of ten would succeed, and as many as seven might thrive in a given year. Raising the threshold to ensure near-perfect success locks those potential seven out entirely. We forget that predicting human performance—especially that of teenagers in a period of rapid emotional and intellectual growth—is a perilous exercise. Between placement decisions in spring and the start of classes in fall, students change in ways no algorithm or test can capture.

A Better Approach

So what can educators do instead? Open access doesn’t mean abandoning standards; it means shifting who makes the final choice and how.

1. Use thresholds as guidance, not gates. Let teachers and counselors use these indicators to advise students rather than restrict them. Explain the risks honestly. Then let the student and family decide. Ownership of that choice is itself a powerful learning experience.
2. Provide a grace period. Allow students to drop the course within the first few weeks without penalty. This safety net reduces anxiety and teaches students to take calculated risks—a valuable life skill in itself. 
3. Transition gradually. If a school currently uses strict gating, it may need to loosen rules slowly. Over time, families and students will adjust to a culture that accepts occasional failure as a normal part of learning.

The Role of Parents

Some worry that parents will push too hard. But parents, by and large, have their children’s long-term interests at heart. With transparent information and shared responsibility, they become allies in fostering resilience, not obstacles to it.

The Case for Open Access

Open access is not a call for chaos. It is a call for trust—in students’ capacity to grow, in families’ ability to make thoughtful choices, and in educators’ willingness to support risk-taking. When schools stop trying to pre-empt every failure, they open the door to a far greater success: cultivating young people who are confident enough to try.

Amazon's Eero Acquisition and the Future of Home

Amazon's announcement of its agreement to buy Eero, one of the early players in the mesh WiFi systems, a couple of weeks ago was hailed as a significant event for the smart home market. As the CNET article on the news rightly points out, it is a clear indication of Amazon's ambitions to control as many aspects of the connected home as it can. But, there is much more to this acquisition than just another device in the house. Of course, it's about the smart home ecosystem. But, it's much more than that. It speaks to Amazon's service ambitions. Amazon is likely going after some of the subscription services such as the eero Plus subscription for $99 per year providing threat scanning, ad blocking and content filtering. Subscription services today are just the beginning of this new opportunity.

What Makes Routers Special in the Smart Home?

I have always believed that the router was a special and important device in the smart home. As the first stop in the connectivity path inside the home, routers (and mesh WiFi systems) are different from other devices at home. They are the first stop for all traffic and security - a device that allows connectivity to other devices and also, protecting them from the big bad world out there. Over the years, this quality is the basis for the router incorporating features such as internet security, parental controls etc. With the popularity of smart home devices now, especially the WiFi devices, we can add home automation, home security to the list. All these services are on top of the device management and firmware update services that are necessary for the healthy functioning of the device.

The advent of the mesh routing has added to the work load on the old girl! Spotty WiFi has been the bugbear of the large homes in the US and remedying it has been lucrative to Google, Linksys and Netgear lately and has been in the eyes of the internet service providers every where. While today the emphasis in mesh routing is on the coverage, as the internet speeds continue to climb, optimizing throughput performance across the home and among the devices will be the name of the game in 2020 and beyond, in the US and everywhere. We should expect to hear a lot more about Self Organizing Networks (SON) shortly.

Modular OS for the Home

With this explosion of services managed by the router, prior models of the custom devices with custom operating systems (OS) has outlived its purpose. While many vendors have contributed to and depended on OpenWrt, most commercial products are only loosely based on OpenWrt. Specific needs of roadmap of services required deviation from the OpenWrt standard release. But, over the years, as the number of services grew, this model was not sustainable any more.

Complexity of delivery of multiple services over different versions of hardware is driving the need for a modular OS. A modular OS could allow for a write-once-and-done client applications which will improve the user experience, decrease the time to market and maintenance cost for service delivery. This has been recognized very early by many of the service providers which led to RDK and softathome. More recently, prpl has also jumped on the bandwagon trying to solve this same problem, but, based on the OpenWrt base code.

At a high level, RDK, softathome and prpl are all implementing some version of the modular OS layers shown in the figure below. It accomplishes two things. By introducing a hardware abstraction layer (HAL), the OS becomes largely independent of the hardware. Application frameworks and containers further free the applications from both the hardware and the OS, allowing the application developers to be able to "write-once-and-done".

Modular OS for Home Device

History is Repeating!

If this diagram feels familiar, it should be! Other than the routing and WiFi services, it resembles a typical smartphone OS today. The similarity in the model is not accidental! Similar to the services on the home devices today, the services on the cellphones (now called feature phones) increased back in the early 2000's. In response, the cellphone manufacturers like Nokia, Blackberry, Motorola and others started experimenting with modular operating systems for the cellphones.

Home devices are at the same crossroads as the cellphones were in 2005/ 2006. Evidently, several options of OS are already available. So, what can we learn from that era?

The Battle of the Phone OS'

Mobile operators, just like today's internet service providers, were incentivized to control the devices and the services that flowed through them. And, they have had a history of working together to create inter-operable, standards based network technologies through the 3GPP. Options, then as now, were abundant. Apart from Symbian from Nokia, Windows from Microsoft and Blackberry, multi-vendor initiative LiMo and open source MeeGo were contenders. Yet, iOS and Android prevailed.

Creating 3GPP standards, I would contend, is different from creating a modular OS. The careful orchestration of the roadmap for application frameworks and HAL as the needs of the developers evolve and the technology behind the hardware leaps is difficult to achieve without a strong entity investing in the OS by employing thousands of software developers, which Google and Apple were. The ecosystem required not just the initial standardization and coding, but, continuous support to all the ecosystem partners. This needed leadership that is difficult to achieve in a collective process such as the 3GPP or a Linux Foundation. Google and Apple nicely filled in this role.

We also can not downplay the importance of the outsider status of Google and Apple in that battle. While service providers and chipset and hardware vendors participated, Google was the outsider and the lead protagonist in Android. Every service provider, chipset and hardware vendor knew that none of their direct competitors had an advantage with the Android platform.

How Will the Home Devices Battle Shape Up?

These two lessons are important for the home devices OS market. While RDK and softathome are driven by different service providers, prpl is driven by chipset and hardware vendors. None of them enjoy the same advantages as either Google or Apple had in the phone OS.

So, who are some contenders this time? Amazon is clearly throwing its hat in the ring with the Eero acquisition and its vast experience with Fire OS. We can not discount Apple and Google, despite Amazon's lead in smart speakers. Their vast experience with phone, computer OS' and obvious ambitions in smart home make them difficult to ignore.

So, who might be our dark horse? I nominate Facebook. Why? Facebook already dipped its toes in the smart home market with the Facebook Portal. With Terragraph, it has some street cred in internet service provider market. The icing on the cake is Oculus Go, the OS for VR headsets Facebook has acquired. So, OS experience covered there. With 5G, the time is ripe for the convergence in VR experience between home (fixed) and mobile experiences. So, the question is not whether Facebook would want to step into this market. The question is why would it not?

Last Mile Considerations: Cable, Fiber and 5G

As 5G gets closer to reality and is expected to pay a major role in home broadband, it is interesting to compare it to the current home broadband options, particularly with respect to the user experience and cost of servicing the customer in the last mile.

While 5G promises low latency (10's of milli seconds) and high throughput (excess of 1Gbps), current cable and fiber offerings already offer the same benefits to the customer. 5G's improvements are really relative to the 4G mobility performance and provide similar capabilities as home broadband has had, but, in the context of mobile devices. For mobile devices, this is indeed a quantum improvement. But, for home broadband, it is not. So, 5G fixed wireless will have to innovate in cost and user experience to win over customers from their current alternatives. Hence, this comparison is topical and interesting.

Current Economics of Broadband Market

Comcast, the US broadband market leader, has close to 26M broadband subscribers while Charter has close to 23M subscribers. Both operate at EBITDA margins of roughly 40% each. The alternative service providers, AT&T and Verizon have close to 14M and 6M broadband subscribers respectively and operate at EBITDA margins of roughly 20% each.

Some of the difference in the EBITDA margin can be attributed to the scale advantage of the industry leaders. The overhead cost and higher negotiating power definitely provide an explanation. Another advantage the cable industry has over the rest of the competition is the fact that they routinely share development costs, either through Cable Labs standards or directly with each other. Since none of them compete with each other, there's little friction in this cooperative model. While Comcast and Charter together have almost 50M subscribers, their power (and cost advantage) is multiplied by the fact that the same infrastructural architecture and customer equipment is used by cable operators world wide.

I suspect that these advantages do not explain everything. Some of the difference is likely explained by the custom customer equipment that AT&T and Verizon launched, trying to keep up with the industry leaders. As a side effects, ease of installation and upgrade has been lost. What do I mean? Let me explain by first detailing the last mile in cable and then, comparing it to that of fiber, as an example. I will then explain the implications for 5G.

Cable Last Mile

Figure 1: Cable connection

In a typical broadband household, cable connection comes from a piece of neighborhood cable equipment, called the cable head-end unit. The bandwidth of the coax cable connection is shared by the customers in the neighborhood. For the broadband connection, once the coax gets into the house, a cable modem translates that coax (DOCSIS) connection to the Ethernet and WiFi devices connected to the router. The connection to the modem is via the standards-based coax connector.

Consider what happens when a customer needs a modem upgrade. When the DOCSIS standard that determines the speed of the connection is upgraded in the infrastructure along with the cable head-end, customers can simply be shipped a new modem. Unscrew the old modem, screw  the coax connector into the new modem and the customer is done upgrading to the latest technology.

Missed Opportunity in Fiber

Figure 2: Fiber connection

Contrasting this to the fiber connection, we will quickly see how the fiber upgrade experience results in much higher costs. A typical fiber broadband to the home starts with the optical splitter that splits the optical signal from the Optical Line Terminal (OLT). Optical Network Terminal (ONT) is the device at the customer's premises. ONT converts the optical signal into an electrical signal, either coax or Ethernet. A modem and/or a router takes in the electrical signal and connects the devices in the house using WiFi or Ethernet.

Unfortunately, the way ONT has been designed does not lend itself to an easy upgrade. Optical lines are directly inserted into the ONT during the installation. It is understandable that optical cables with a standard optical connector can not be shipped, given the uncertainty of the length of the cable required. But, if the cables were installed with the optical connector as a part of the installation, the ONT could potentially be user replaceable. Instead, a technician needs to visit the customer to replace it. Given the customer's disdain for the wait involved with an installation and the proprietary hardware, these design choices are difficult to fathom. Not only does this add cost, but, it also results in much worse customer experience.

Implications for 5G

Figure 3: 5G connection

Why does this matter for 5G? As you will see, 5G is, in some ways, similar to the fiber connection above. 5G fixed wireless connection will come to the customer's premises from a 5G base station mounted on a pole in the neighborhood. Fixed wireless 5G will use high band RF in the 20 and 30 GHz range. This signal needs line of sight to the 5G customer premises equipment (5G CPE) and hence, the installation will be critical. The 5G CPE needs to be mounted to account for the altitude, the location and the angle of its mount with respect to the 5G base station. Like other implementations, this 5G CPE, then, needs to communicate in some form to the router that connects to the customer's devices.

If an upgrade were to be painless, what needs to be true? It should be easy to unmount the 5G CPE which means that the mount has to be standardized and be foolproof. Also, the connection to the router needs to be standardized so that the customer could potentially replace the equipment themselves.

Given that the equipment is just a means of delivering the service, standardization will also enable lower costs by allowing others to build it. If standardization can be achieved, it will also erase the scale power of the cable giants and allow the 5G fixed wireless operators to compete on an even keel. The key question is how does one go about this!

Fallacy of Current Cost Accounting Of Data Service at Wireless Carriers

Service pricing at all major carriers betrays the underlying cost accounting method. Even in Unlimited plans, for example the T-Mobile footnote for Unlimited plan says that “…the small fraction of customers using >50GB/mo. may notice reduced speeds until next bill cycle due to data prioritization.” Essentially, the carrier is using GB of data usage as a means of assessing the long term value (LTV) of the customer and ergo, what is economical and what is not. But, GB of data usage based cost accounting isn’t accurate and has consequences going forward.

Why isn’t it Accurate?

It’s isn’t accurate because the underlying assumption is that GB of data usage represent a close approximation of the cost involved in delivering those bits. Cost of carrying the bits can be split into cost of carrying the bits from the customers’ device to the cell tower and from the cell tower to the internet. Cost of carrying the bits from the cell tower to the internet is the same irrespective of the type of device used by the customer. The cost of the backbone data transport pales in comparison to the billions of dollars spent in acquiring the spectrum and constructing the cell towers. So, let’s ignore it for the moment.

Given that spectrum is a scarce resource, cost of carrying bits to the cell tower is based on the amount of spectrum used and the amount of time that the spectrum is used. This isn’t the same across all the devices. The amount of spectrum used is a function of the available spectrum at the cell tower and the quality of the chipset on the device – typically, the more expensive (and premium) the device is, the better the chipset is and the more spectrum it can use at the same time – technically called carrier aggregation. The amount of time spectrum is used is a function of the distance of the customer to the cell tower and also, the quality of the antenna on the device. The less signal the device receives (whether the device is far away from the cell tower or the antenna is bad), the more time the device spends occupying the channel in the spectrum.

Why Wasn’t the Cost Accounting a Problem Before?

Ok, the cost accounting might be inaccurate. Why wasn’t it a problem before?

Pre-2006 when voice was king, there was no carrier aggregation. Mostly, all devices used the same limited spectrum available. The amount of time the spectrum was used was a direct function of the number of minutes a customer used that month. If customer had a crappy antenna or was too far away from cell tower, due to the real time nature of the voice packets, the call quality would degrade. But, the amount of time spectrum is used closely mirrored the number of minutes a customer used that month. So, cost accounting based on minutes of voice calls matched the actual costs very well.

Why is it a Problem Now?

When smartphones took over and data started to be billed by GB, the device subsidy model masked the inaccuracy of the data usage based cost accounting. Subsidy enabled the customers to buy the best phones at an affordable price, which meant most customers had similar and good phones. Also, the better the phone was, typically, the higher the subsidy. So, subsidy amortization and more homogeneous device capabilities masked the cost-price matching problems of the data usage based cost accounting.

What is the Impact?

With the correct cost accounting, network planning teams at carriers will be able to allocate capital for cell tower construction better. The network planning teams can trade-off between capital cost allocation vs. lower operating costs for those customers helped by the new cell towers.

Also, without the correct cost accounting, carriers cannot expect to compete in the hyper segmented world that wireless carrier market soon will be. If the costs are wrong, how can the price be right?

With BYOD coming in a big way and consumers conscious of the cost of the devices, not all devices will be of the same quality. A customer consuming the same amount of data on a device with low quality antenna will have dramatically higher cost than a customer consuming the same amount of data on a much better device. This is why, in the hyper segmented world, the price will be a function of the device as well. A customer using a high amount of data with the latest phone (say, an iPhone X or a Samsung Galaxy S9) might be paying the same as someone with a Moto G. That's similar to the guy with a Ferrari paying the same insurance rate as the guy with Honda Civic! It's still fair because of the different costs they put on the network. In the car world, the vendors wiped that difference by improving reliability. The device vendors can similarly wipe the difference off by ensuring that the antenna is not compromised due to cost.

Unlimited - What Comes Next for the US Wireless Carriers?

The more things changes, the more they remain the same! The wireless market play till now was similar to the dial-ups of old days with data limits and multiple competitors. Could that offer a window into the future of wireless carriers?

A Brief History of Landline Business

The customer access and economics were similar. Service providers had to invest in bandwidth locally, similar to wireless carriers today that have cell towers and spectrum. Customers weren't typically mobile, but, could connect from anywhere. So, service providers like AOL, could service customers anywhere as long as the customers had a local service number the carrier had invested in. Otherwise, it was too expensive for the customers due to the long distance charges. Customers were able to self select initially based on which service provider was cheaper overall. Over time, service providers built capacity across all local service areas.

Two key things that made this a competitive market were regulations that allowed any business to have a local service number and sufficient peer to peer bandwidth (that telephone carriers built) for anyone to provide service. This made the connection commodity. Internet service was the differentiation and the service providers were able to segment their customers based on usage. The more you used, the more you paid. This was the world of wireless carriers till Unlimited came around.

Then came the shorter range technologies such as DSL, cable and fiber that were no longer peer to peer. No regulation was enacted to ensure that local connection was universally accessible. So, anyone other than the service provider that built it couldn't provide an alternate service. Internet was commodity, but, the local connection wasn't any more. Something else had changed. For the service provider, it really didn't make sense to segment the customer based on usage any more. The real costs were based on speed rather than the usage as the cost of carrying bits over long distance became extremely low. Higher speeds required higher investment in the local access infrastructure. So, speed, instead of, usage became the segmentation parameter. This also had parallels to wireless as I will explain later.

Economics of Unlimited

Coming back to wireless, unlimited is tough on the carriers. With spectrum still the primary cost driver and revenue limited to the line access charge, revenues from customers don't match up with the costs of customers that consume disproportionately. With every carrier now offering unlimited, US customers are likely to "super size" on data. Of course, every carriers has come up with a band-aid patch for this with network prioritization over a certain level of usage. That only regulates perhaps the top users of data. Affecting a significant portion of the customers with a low threshold for network prioritization would likely risk customer dissatisfaction and backlash. You can create speed and usage tiers, but, pricing can become quickly complicated. So, what's a carrier to do to match pricing to the costs?

A New Model for Wireless?

Let's now look a little farther away to another retail market. Consider that the service plan revenue is a given and the carriers don't know how much risk a prospective customer presents in terms of network cost. If we consider the service plan revenue as premium and the data usage cost as risk cost, the wireless market looks a lot like a huge market we know very well - the consumer auto insurance market.

Consumer auto insurance companies are able to assess the risk posed by different segments of the population and present a personalized quote to individual customers. The costs are matched to the price, thanks to hyper-segmentation and data analytics on each potential customer.

In a market such as this, it's important for the company to know which customers to bring on and how to get them off the insurance, if the risk profile changes. This is why Progressive has an insurance comparison site - it helps convert prospective customers that fit a risk profile become current customers and later encourage current customers to go away, if they no longer fit the risk profile that Progressive wants to insure. Segment purity might be a key differentiating factor in keeping the churn low - an important factor for investors.

Segmentation and Future of Retail Wireless

Taking a leaf out of the auto insurance market, wireless carriers need to be able to segment the customers based on usage and speed needs and offer the pricing that caters to them. A customer that consumes lot of video presents a different risk profile from a voracious reader of news and e-mail. To be successful, the wireless companies need to be able to hyper segment the customer base, just like the insurance market. This will avoid the morass of ever complicated price offerings.

In a world of such hyper segmentation, each brand might mean different things to customers. One that is known for its customer service will not likely be the cheapest. You might argue that it's true today too. But, retaining segment purity will require the right combination of the channel, customer service, network service and of course, pricing along with the means of identifying the customers that belong to the segment. A carrier going after the urban millenials might have a purely online/ mobile presence, might advertise on social media, might make it easy for the customers to BYOD, focus on WiFi offloading and will look very different from a carrier that is going after baby boomers that might use TV and radio ads, provide phone and store support and provide low cost phones. This is no different from how Esurance or AARP Auto Insurance target their customers. Identifying the customers in the segment requires not just demographics, but, also, data usage and data type behaviors, device ownership etc. This ensures that the discover, evaluate, buy, use, support and exit phases of a customer journey are properly matched to the customer segment.

Unlike auto insurance market that depends on the reinsurance companies to insure the insurance companies, wireless carriers, today, are their own re-insurers. So, that's where the similarity might end. But, the interesting thing about the auto insurance market is that it is a whole lot more competitive than the wireless carrier market. To compete effectively and maintain segment purity, would a carrier need more than one brand - perhaps as many as three or four to ensure a match between customer journey and the segment? Or, a carrier could spin off its retail operation, become a pure network operator (the re-insurer of the wireless market) and let the others duke it out!

An interesting question is what happens to customers when carriers can hyper segment this way? How do the customers compare the service/price combination with their friends? The consumer auto industry again provides a clue: they can't! If they can't, would that lead to more churn or less?

Potential Disruptors

Who could help upend this happy story? Clearly, carriers need help prospecting new customers and understanding their data usage. Nielsen and other data collectors will be happy to help. Retail carriers that can best use predictive analytics to understand the customers will win.

The interesting players are Google and Apple that have a hold on the OS and the underlying amount and type of data. Could they potentially use that information to either stand their own retail carrier or help others compete? Given my previous prediction about Google, you can guess who I think will jump into the fray!

The biggest disruptor, though, might be technology again, similar to how the landline market unfolded.

5G: A Rewind?

5G, as is currently implemented in the US, is based on shorter range frequencies such as 28GHz and 39GHz with the potential of providing up to 3Gbps. But, the range of 5G cells is much lower than a typical LTE cell tower, closer to 200m, not the 20km of LTE. This means only highly urban areas will have dense deployments necessary to enjoy the high throughput. Coverage will vary wildly across the US. It will take a long time for a country like the US to attain 5G coverage similar to that of LTE. Countries such as Korea and Japan that are highly urbanized would have much better coverage than a country such as the US. As with the shorter range technologies in landline, 5G will have a profound effect on the cost of mobility. Will 5G change how the industry evolves in the short term?

So, What Comes Next?

My bet is that, in the US, 5G adoption will not be fast enough to impact the industry forces discussed before. So, I expect that the US wireless market will evolve into hyper-segmented multiple brands within the next four years before 5G could ever become dominant.

Driverless Cars: End of Road Rage?

A recent BBC article got me thinking about driver etiquette in the presence of driverless cars. Would drivers really be rude to autonomous vehicles (AVs)? I am more optimistic than Matthew Wall from BBC about the prospects of AVs and the behavior of human drivers. Here's why ...

Prospects of AVs

Let us first address the potential skepticism of people towards driverless cars. The demand for driverless cars will be driven (pun intended) by people that don't want to drive - people that either don't already have a car, or don't want to have a car. If you are a skeptic of driverless cars, sorry, you really don't have a choice. Barring a legislative initiative to outlaw driverless cars (for which there's scant evidence), you just have to live with the AVs. Consideration of safety, the huge number of cab rides taken and the right of mobility for the elderly likely will trump the resistance of the skeptics.

Driver Behavior

Clearly, AVs are still learning to deal with human drivers. Yes, it might be frustrating for human drivers to deal with AVs, especially, on local roads with slow and unexpected traffic.

But, I am optimistic that there will not be bullying of the AVs by human drivers for too long. Why? Like most technology products, we should expect that AVs will collect a lot of data, including, the places they were at a particular time, the people, cars and other sights they have seen etc, nicely meta-tagged and searchable. This will be a treasure trove for all manners of governmental agencies.

The transportation departments would want some of this information to predict traffic patterns and to plan for future construction. Welfare departments would want to understand passenger patterns and the improvements in services they can provide.

The most intriguing use in the context of driver behavior is the video footage collected by the AVs. Similar to (private) video recordings of public spaces, the video footage of the AVs can likely be asked to be presented for a police investigation through a subpoena. Even more intriguing is the use of meta--tags. Can the law enforcement agencies be able to search and quickly get through all the AVs' video footage at a certain time and place? I don't see why not! In fact, we shouldn't be surprised if the law enforcement directly submit the subpoena to the manufacturer (or software provider) of the car itself, regardless of who owns the car. I am sure there will be other uses for law enforcement analysis such as improvement in gun shot detection and other major crime detection.

Coming back to driver behavior, if you think you are going to have a bout of rage at the AVs, you might want to think of all the video footage captured. :) You should expect the video of the incident ready and packaged for the police, before you are done with your rage.

I don't know about you, but, once AVs become prevalent, I am going to put my legs up on the dashboard and let the machines do the driving. I love driving, but, it won't be as much fun with big brother watching!