When Editorial Started Hiring Its Own Agencies, That Was Product's Real Status Report

When I joined CoinDesk, the editorial team had stopped waiting for product. They were hiring outside agencies to build the tools they needed, because product and engineering had become so slow that editorial had given up on them – and to be fair, product and engineering were that slow. Projects that should have taken weeks were taking nine months. That was the situation I'd been brought in to help fix.

The agency-built tools usually didn't perform well. And when each contract ended, editorial would try to hand the thing over to CoinDesk's product and engineering team to run: a different tech stack, no knowledge transfer and no capacity on the product side to support it. It was a disaster technically and financially, and the people paying for that disaster were the same people who'd felt they had no choice.

It's one of the clearest signals a product leader can get, and it almost never shows up in a status report. When the people you build for start building around you, they're telling you they've stopped trusting you to deliver. Every roadmap review after that point is describing a relationship that has already broken.

Routing around product is a lagging signal

By the time a stakeholder group hires its own agency, the trust has been eroding for a long time. Nobody does it after one missed date. They do it after months of tickets that disappear, priorities that change without explanation and promises that don't turn into anything, and they do it because it feels like the only way to get their own work done.

That's what makes it a lagging signal. The editorial team at CoinDesk didn't wake up one morning and decide to cut product out. They'd been asking, waiting and getting nothing for long enough that spending their own budget on an outside agency looked like the responsible choice. From inside product, it can look like a turf grab or impatience. From the other side, it looks like survival.

And because it happens in someone else's budget, product often hears about it last. The tool shows up already half-built, or already failing, and lands in the product team's lap as a support problem.

It has never been cheaper to route around you

What worries me now is how much cheaper this has become. At CoinDesk, going around product meant signing an agency contract, which at least took a budget conversation and some time. Today it can mean a smart person with an AI coding tool and a free afternoon.

The numbers are moving fast. In McKinsey's State of AI 2026 survey, 32% of respondents said their organizations had decided against buying at least one software product or feature because they could build it in-house with agentic coding tools. Retool's 2026 Build vs. Buy report, a survey of Retool's own customers (so it skews toward people who build), found that 60% had built software outside IT oversight in the past year. And Bulb Studios' AI Product Builder Study, which surveyed more than 2,000 UK product professionals, found that 27% had shipped AI-generated software without any engineering review.

Most writing about this treats it as an IT governance problem, and it partly is. But I read those numbers differently. Every one of those side projects is someone deciding the official path was too slow, too unclear or too unlikely to say yes. That's a product problem before it's a security problem.

The bill always comes back

The part that doesn't change, whether it's an agency contract or a weekend of vibe coding, is what happens after. Software someone built around you still has to be maintained, secured and connected to everything else, and eventually somebody asks the product team to take it over. It comes with a different stack, no documentation and nobody left who remembers why it works the way it does.

So routing around product doesn't save the company any work. It moves the work to later, adds interest, and hands the bill to the team that was too slow the first time. Each orphaned tool makes the product team a little slower, which makes the next side project a little more tempting.

How we earned the work back

Asking editorial to stop wouldn't have worked at CoinDesk. What worked was giving them a reason to come back.

The first change was making product the single front door. Stakeholders couldn't go straight to engineers anymore; they had to come through me, so I could understand what they needed, get a clear definition of the work, and figure out its real priority and business value before it reached the team. That sounds like more bureaucracy, but it was the opposite for editorial, because for the first time someone was actually responsible for getting them an answer.

The second change was making priority visible. I told editorial plainly where their work sat in terms of priority and business value, including when something wasn't going to happen soon, so they weren't left guessing.

The third was delivering what they really needed, which wasn't always what they'd asked for. When there was something we couldn't build, I went looking for a tool that already existed and solved their problem well enough, so they didn't need an agency to get unstuck. The editorial team ended up happier, even though they weren't necessarily getting the specific things they'd asked for, because they could see they were getting more valuable things.

Underneath all three was something simpler: I did what I said I was going to do, over and over. Trust gets rebuilt through consistent, demonstrated action, not through a single conversation, and once product was reliable again, editorial stopped needing the side door.

Small yeses keep the front door open

The other half of this is what product says when stakeholders do come to the front door. If the answer is always no, or always "it's on the backlog," you've told them the side door is the only one that opens.

I don't think the answer is saying yes to everything. But most of the small asks that come from stakeholders and executives aren't big, and it's uncommon for one to take more than about two weeks to build. If it won't hurt the user, won't distract from the roadmap and won't send people down the wrong path, building it is often a good trade, because it shows you can deliver on their idea and that you're open to their input. I've written before about how saying yes to the small idea is how you buy the right to say no to the big bad one.

And when the answer does need to be no, it lands better as a "no, but" with data behind it: we're not going to build that, but here's something that gets you to the same outcome, and here's why. Editorial at CoinDesk didn't need product to agree with every request. They needed to believe that asking product was going to get them somewhere.

Watch for the side door before it opens

You usually don't need a survey to know whether this is happening in your company. Ask who has built or bought something in the last quarter without involving product, and listen for the stakeholder who says, half-joking, "can't we just build it ourselves?" Those are the moments to go find out what they've been waiting for.

If you're a founder, it's worth asking the uncomfortable version too: when your own sales or marketing team wants something, do they come to product first, or do they go find a contractor? If it's the contractor, they've already told you what they think of the front door.

None of this means stakeholders building their own tools is always bad. Sometimes a quick internal build is exactly right. But when it becomes the default, the side projects are product's real status report, and they're usually more honest than the one on the roadmap.