Mike Bogdan

Election Night, Quietly

The Associated Press runs the vote-tally infrastructure that powers national election calls. Election cycles are their highest-stakes operational window of the year — and a primary cyber-target window.

This was less a project than a posture. AP didn't need a deck about how prepared we were. They needed to know — before the night, in concrete terms — that the operating model behind the platform would hold up if something went sideways at 2 a.m. on November 5th.

I worked with global support leadership to design a 48-hour staffed-coverage plan: TAM handoffs at fixed intervals, a joint escalation channel that internal and customer-side stakeholders were already in before the night began, and a real-time internal coverage rhythm so that any escalation had a clear owner at any hour.

The right outcome here was the absence of drama. Election night ran. The customer's operational view of Cloudflare during that window was steady, predictable, and well-staffed.

The judgment call worth naming: most of the value happened before the night. The work was not the heroics — it was making sure heroics weren't needed.

The hard part was deciding what would be on the plan and what would be off it. The night was the easy part, because the plan had already done its work.

The Customer Map and the Upsell Engine

A digital experience platform (DXP) partner with a large, complex embedded customer base. The partner had account teams ready to grow the relationship — they just didn't have a usable customer-level view to act on.

Part A — The upsell engine

The partner's account team wasn't blocked on willingness; they were blocked on view. Every conversation with a customer required someone to manually pull usage data, manually cross-reference entitlements, manually figure out what services might fit, and manually frame a commercial pitch — and that work didn't scale. The result was that obvious upsell opportunities went unaddressed because the operating layer underneath the account-team conversation didn't exist.

I built it. Working with Claude and the internal MCP connections, I pulled SQL against customer-usage data and started piecing together the broader picture — total traffic, blocked traffic, bot traffic, API patterns. I mapped per-service entitlements so the team could see what each customer was actually using out of what they'd already paid for. Then I had Claude analyze the patterns and look for upsell signals — sustained attack traffic suggesting bot management, payment-processing domains suggesting page-shield, API-heavy traffic suggesting API gateway.

I closed the loop on the commercial side. The signals fed into the established package pricing, so the engine produced a per-customer quote the account team could discuss without going to deal desk. The whole view rolled up into a single web page the team could pull up for any customer — twelve months of usage on a Plotly graph, the upsell signals called out, the pricing tied to specific package fit. Best of all, they could export a clean PDF report for the customer with or without pricing.

Part B — The migration tracker

The migration wasn't a single move — it was three parallel paths, and which path each customer landed on depended on technical details that no one had at customer level. DNS readiness was the first question. NS-lookup details determined which customers would hit the static-IP requirement, which was the single biggest source of migration friction. Active order state, renewal timing, and revenue trajectory determined whether moving a particular customer made commercial sense in that quarter or the next.

I built the layer that made each of those questions answerable at the customer level. The migration tracker shared the same data plumbing as the upsell engine — so the partner's account team was running both motions off the same operating view, with the same customer records, the same per-customer history, and the same pricing context. The migration view also surfaced where the heaviest lift was concentrated, so the team could sequence customers on operational difficulty rather than reacting to whichever escalation got loudest.

The dashboard isn't the artifact. The artifact is the operating model — per-customer usage, signals, pricing, and migration state in one view, runnable by the partner's team without me in the room. Anyone can hand a partner a dashboard. Giving them an operating model is the work.

Holding the Roadmap to Account

An enterprise cloud platform partner where the majority of ACV came from the partner's own consumption of the underlying service. New product introductions kept stalling on missing feature requests — and the conversations that defined those asks were scattered across half a dozen tools.

The deals weren't blocked on price. They were blocked on a specific set of essential features that had been requested, discussed in the right rooms, occasionally committed to, and then somehow drifted. The reason the drift was hard to manage from the partner-success side was structural: the context for each request lived everywhere except in one place. Some of it was in email. Some in a Google Chat thread between three engineers. Some in a Jira ticket that hadn't been updated in two months. The shape of what the partner actually needed — and why — got lost between systems.

I built the tracker that lived where that context belonged. Pulling from email, chat, and Jira via Claude Code, it captured each feature request with its technical detail and — critically — the partner-stakes context: what deal was waiting on it, what customer was affected, what commercial outcome was downstream. It tracked which PMs had committed to which updates and when, and auto-tagged them on Confluence so the accountability lived in their own working surface, not just my notes. It pulled Jira and GitLab status on the underlying engineering work, so progress against commitments was visible without a separate check-in.

The tracker reframed the conversation. The partner could see what the product team had committed to, the product team could see what was at commercial stake, and I could re-engage product the moment a commitment started slipping — with specifics rather than impressions. Several of the blocked features shipped on accelerated timelines once the accountability layer was visible.

The product team wasn't the problem. The lack of a shared operating layer was. Once both sides had one, the meetings got shorter and the roadmap moved.

What the Field Knew

T-Mobile. Apple's brief was to drive iPad attach across the carrier. T-Mobile's actual problem was something different — but you only heard it if you spent enough time in their stores to surface it.

The Apple brief was straightforward: drive iPad attach across the T-Mobile territory. The field told a different story. Spending real time on store visits and in district leadership meetings, what kept surfacing wasn't an iPad problem — it was an SMB lead-generation problem T-Mobile owned internally, with their own targets and their own pressure to hit them. iPad with Apple Pencil was a near-perfect tool for that exact use case, but the store associates didn't know how to bring it into a conversation, didn't know how to showcase what it could do, and didn't know how to read SMB-shaped intent in a customer who'd walked in for something else.

The brief and the partner's problem didn't intersect. The enablement program had to.

I worked with Apple's SMB development team to build the SMB Speaker Series — an enablement workshop with talk tracks, hands-on demos, and conversion skills built specifically for the SMB-conversation moment in a carrier-retail context. When we walked T-Mobile's NYC district leadership team through it, what they heard was Apple paying attention to their internal commercial pressure, not just selling them on Apple's product roadmap. They committed to a 4-day workshop for the full team at their Times Square office.

The lift showed up immediately — roughly 20–30% in SMB leads within the NYC patch, with a meaningful iPad sales lift tracking the same training cohort. The success was strong enough that Apple's training team picked it up, revamped it for virtual delivery, and ran it nationally. Once the AT&T and Verizon alliance managers saw the model, they pulled the content into their own carrier programs.

The hard part was hearing the partner's actual problem instead of the one Apple's brief assumed. The rest was design work. Knowing the partner's business better than they sometimes know it themselves is mostly a function of showing up, listening to the field, and treating what they tell you as the data.