July 14, 2026

One of the better decisions I made running POSSIBLE / Wunderman Thompson Apps had nothing to do with the apps themselves. We had an analytics team. Good people, good dashboards. But it lived as a service line under delivery. Reports went out, clients said thanks, and the value quietly evaporated. So we pivoted that analytics team into an "App Growth" practice and ran it as its own P&L. That one change reframed everything. When a team has to sell its own outcomes, it stops shipping reports and starts asking better questions. What moves retention? What drives repeat orders? What's the next release actually supposed to change? The measurement stopped being an afterthought and became the reason for the next piece of work. I think about this a lot now. A lot of companies treat data as the thing you look at after you build. The teams pulling ahead give it its own mandate and its own number. Same lesson I keep landing on: the surface changes, the architecture underneath is what compounds. Have you tried running analytics as its own P&L? What happened?

When we scaled the Apps group at POSSIBLE/Wunderman Thompson, one of the harder calls was going distributed. We opened near-shore centers in LATAM and Eastern Europe. Later at Goods & Services, I helped unify delivery across North America, England, Germany, and India. Everyone frames near-shore as a cost play. Cheaper hours, bigger margin. That framing is where most of these efforts break. What I learned running those teams: the value isn't the rate card. It's time-zone overlap and the quality of the seams between locations. The cheapest engineer in the world costs you more if the handoff is broken. So we spent real energy on the boring parts. Shared standards. Overlapping hours where the hard conversations happen live. One definition of "done" across every office. When those seams held, distributed delivery actually got faster, not just cheaper. When they didn't, we paid for it in rework. Same principle I keep coming back to: the hard part was never writing the code. It's clear communication and understanding what you're actually trying to build. If you're standing up global delivery right now, where are you investing first?

Early in my career at Sapient, I helped run delivery on some of Coca-Cola's first mobile apps. Spin the Coke Bottle, Freestyle, Design Machine. Here's what nobody tells you about building the first version of something for a client: There's no benchmark to point at. When a brand already has three competitors doing a thing, the conversation is easy. You show them the market and say "here's the gap." But when you're building their first of anything, the market can't validate you. The client is being asked to trust a picture in their head. The lesson I took from that era, and it's held for 18 years: on first-of-its-kind work, your job isn't a perfect spec. It's conviction plus small proofs. Get something real in their hands fast. Let them react to a working thing instead of a slide. Sequence the risk down. I see the same dynamic now with AI. Everyone wants a roadmap, but nobody has a competitor to copy. The teams making progress are the ones willing to put a small working proof in front of real users and learn from it. If you can't point at the market, you have to build the evidence yourself. How are you validating work when there's no benchmark to compare it to?

Most of the AI conversations I'm in right now aren't net-new. They're expansions inside accounts we've worked with for a while. That's taught me something about how enterprise buyers actually adopt AI. The ones who get it wrong treat AI as a fresh procurement. New RFP, new vendor, new pilot, sitting off to the side of everything they've already built. The ones who get it right start with the data. Because AI is only as useful as the layer underneath it. If your customer data is fragmented, your model just produces confident nonsense faster. Here's what I keep noticing: expansion into data and AI rarely happens because someone bought a capability. It happens because a team already understands your systems, already knows where the data lives, and already earned the right to build the next thing on top. The trust got built on the last project. The AI work is just the next surface it powers. A good chunk of our existing-account growth last year came from added capabilities like this. Not from a pitch. From being close enough to the architecture to see what was possible next. So the question I'd put to buyers: are you selecting an AI vendor, or extending a relationship with people who already know your data?

Every few months someone asks how we're building the net-new pipeline at Stable Kernel. They expect a demand-gen answer. Ad spend, MQLs, a nurture sequence. That's not how it's worked for me. At Acquity Group I grew the Atlanta team from 2 to 20 and built an $18M pipeline. None of it came from buying demand. It came from being in rooms with the right people. Genuine Parts, NAPA, AutoNation, IHG. I'm doing the same thing now. Built a $15M net-new pipeline through partnerships, event attendance, and targeted outreach. The lesson: enterprise buyers don't fill out forms. They congregate. At industry conferences, peer dinners, exec councils. Your job is to be there consistently, bring something actually useful, and be the person they call when the problem gets real. Pipeline isn't a funnel you buy. It's a network you keep showing up for. The trust compounds over time. How are you building pipeline right now, bought or earned?