CoinDesk: From 9-Month Delays to 3x Productivity
How CoinDesk went from 9-month delays to 3x productivity and rebuilt trust across Product, Engineering, and Editorial. Delivery Diagnostic case study.
CoinDesk's product and engineering teams had lost the trust of the entire company. Engineering would commit to work, then nothing would ship. Projects that should have taken weeks were taking nine months. Leadership blamed engineering. Engineering felt blamed for problems that weren't their fault. I joined as Senior Product Manager, ran a delivery diagnostic in my first weeks, and spent the next two years rebuilding delivery, trust, and strategic direction. Within 90 days: 3x productivity, people going home by 5pm on Friday, and a team that could finally build new things.
The Challenge
When I arrived at CoinDesk, the relationship between Product, Engineering, and the rest of the company had completely broken down. There was no trust left.
The company had been through a series of leadership mistakes that compounded on each other:
A CPO who mandated a disastrous platform migration. She signed a multi-year contract to move from WordPress to Arc XP without involving engineering, gathering requirements, or even evaluating the platform. When the implementation team told her it would take 12 to 18 months to migrate, she mandated they do it in five months. They flipped the switch on editorial one morning – everyone woke up to a different CMS. The site's SEO tanked because it wasn't optimized and performed poorly. The fallout led to all of Product and several key engineers quitting.
Consultants acting as product managers. After firing the CPO, leadership brought in contractors from an agency that had sold them as product managers. They weren't. They were more like junior project managers who didn't understand product management and weren't delivering any product value.
A VP of Product who implemented pods. The next product leader broke the group into pods – the same play from their previous company. It's one of those ideas that often makes sense on paper. Spotify published a similar model, it made a lot of noise, and people got excited about it. Then Spotify never fully implemented it and later retracted it because it didn't work. Like often happens with retractions, no one noticed that part and the idea keeps being promoted.
Part of the problem was that CoinDesk's pods were too small. They lacked the full skill set needed to deliver all the work. Pods were aligned to particular feature sets, which made the skill gap worse and meant some pods had too little work while others had too much. Any siloing like this, especially with small teams that don't have all the skills needed to deliver, tends not to go well.
From leadership's perspective, Engineering was the problem. From Engineering's perspective, they were working incredibly hard, working long hours, and constantly getting blamed for things that weren't their fault.
What the Diagnostic Revealed
I was hired as Senior Product Manager. In my first weeks, I ran what was effectively a Delivery Diagnostic.
On day one, I walked straight into sprint planning and watched the pattern unfold.
Product had repeatedly failed to deliver clear requirements. Engineering tried to figure out requirements themselves, but that wasn't their discipline or skill set. Jira tickets lacked acceptance criteria. The same pattern kept playing out – unclear work went into sprints, engineers built what they thought was right, stakeholders rejected it, and the cycle restarted.
Code reviews were inadequate because pods didn't have the right skills distributed across them. The false boundaries created by pods prevented collaboration between engineers who needed to work together.
Decisions weren't getting made. Key decisions kept getting tabled "until the next meeting." Standing meetings were perfunctory – time that could have been spent doing real work.
But the linchpin was deeper: lack of a clear strategy, vision, and mission, and the lack of leadership who could make a decision, own the consequences, and then learn and iterate.
How We Fixed It
The execution took about nine months. I took it slow deliberately – this wasn't a situation where you crash through changes. The team had been through enough disruption.
Rebuilt trust through consistency. If I told someone I was going to do something, I did it. I led bi-weekly retrospectives and when the team said there were ways to improve, I followed through – made sure it happened. Broken promises had eroded trust. Kept promises rebuilt it.
Became the firewall. I took on the work of talking to all the stakeholders, gathering requirements, and making sure they were clear before anything reached engineering. Stakeholders couldn't go directly to engineers anymore – they had to go through me so I could evaluate the work, get a clear definition of it, and determine its true priority and business value. That alone made a huge difference. Engineers could focus.
Managed work in progress. I limited WIP so engineers could focus on fewer things and do them well. When I started, the percent of defects going into a sprint was probably 70-80%. I looked at what was coming in as defects and said, "These aren't bugs and they don't matter. We're not doing them." A slight color change, a pixel alignment issue – nothing the end user would actually notice, nothing negatively impacting their job to be done. Nobody else had been willing to put their foot down. I was willing to say, "None of this work is valuable. We're not doing it." We focused on real user problems instead.
Slowly dissolved the pods. I took leadership of one pod, then a month later merged a second pod into my team. A month or two after that, a third. We slowly reduced the contracted product managers – they were from the same agency as several contracted engineers who were absolutely brilliant, and I didn't want to burn the relationship with the agency. The slow pace maintained that agency relationship, and we retained the engineers. Everyone was happy.
Rebuilt trust with editorial. The editorial team had reached the point of trying to bypass product entirely. They were hiring outside agencies to build solutions because they felt CoinDesk's product and engineering moved too slowly – which, admittedly, they were. These outside systems often didn't perform well, and once the contract ended, editorial would try to hand them to CoinDesk's product and engineering team. Different tech stack, no knowledge transfer, no capacity to support it. Disastrous from both a technical and financial perspective. I rebuilt that relationship by demonstrating I understood what editorial needed, communicating clearly where work sat in terms of priority and business value, and getting stuff done that they really needed. When there was something we couldn't build, I found quick solutions they could use without hiring outside agencies – tools that already existed, where product and engineering could be happy with the approach.
Maintained a reasonable work schedule. People were working weekends. That stopped. Sustainable pace, fewer fires, better focus.
The Results
Within 90 days:
| Metric | Before | After |
|---|---|---|
| Productivity | Baseline | 3x baseline |
| Work schedule | Nights and weekends | Home by 5pm Friday |
| Sprint defect ratio | ~70-80% defects | Focused on valuable feature work |
| Product-Engineering trust | Broken | Rebuilt on clear communication |
| Product-Editorial trust | Bypassing product entirely | Collaborative and positive |
| Employee morale | Burned out, demoralized | Energized, retention improved |
The team could finally build new things because they were no longer wasting time on solvable problems that had plagued them for months.
Over the full two-year engagement:
- Promoted from Senior Product Manager to Director of Product within 6 months
- Managed 30 concurrent projects
- Led the replatform from Arc XP to Sanity and Vercel – the migration that should have been done instead of Arc XP five years earlier. Reduced 80+ components to 23, improved Core Web Vitals across all page types, and cut development cycles from months to weeks.
- Redesigned the cryptocurrency price page strategy using Jim Collins' Hedgehog Principle – identifying CoinDesk's unique value as a journalism company that could tell the story of price movements, not just display charts. Presented the strategy to the CEO, president, and senior executives. It became the mission for price pages and drove eight phases of feature development.
The Backstory on Defect Management
A lot of what looked like poor quality was actually a classification problem. Stakeholders would look at something and say, "Here's a bug – fix it." Engineering would divert time to fix it, but the "bug" might be a slight color change or a pixel alignment. Nothing the end user would notice. Nothing impacting the user's job to be done.
I decreased the defect rate by drawing a line nobody else had been willing to draw. If we needed to fix alignment issues, there had to be a real reason – mobile performance or accessibility – and we'd bundle them together so people weren't task-switching between a bunch of tiny defects. They could commit to something meaningful in a sprint and do creative, valuable work.
Doing that made a difference for everyone. The editorial team was actually happier, even though they weren't necessarily getting the things they'd asked for. They realized they were getting more valuable things thanks to the product work.
What This Means For You
CoinDesk's situation had layers: a broken trust relationship, a series of leadership missteps, organizational structures that prevented collaboration, and a team that was burned out and demoralized. No single fix would have worked. It required someone who could diagnose the systemic problems, rebuild trust across multiple teams, and execute over time.
If your organization has gone through leadership changes, failed process implementations, or trust breakdowns between teams – the diagnostic process reveals what's actually broken and gives you a specific plan to fix it.
Frequently Asked Questions
How long did the full engagement take?
The delivery diagnostic portion was about two to three weeks. The execution took about nine months to get the team fully restructured and functioning well. Over that time, we slowly dissolved the pod structure, released the contracted product managers, and rebuilt how the team worked. I was at CoinDesk for just over two years total, during which I also led major strategic initiatives including the site replatform and price page strategy.
Why did it take nine months to implement?
I took it deliberately slow. The team had been through enough disruption – a disastrous CPO, rotating consultants, a pod restructuring that made things worse. Crashing through another round of changes would have destroyed whatever trust was left. I took leadership of one pod first, merged a second a month later, then a third after that, and so on. Each step gave people time to adjust and see that the changes were actually working.
Was the pod structure the main problem?
It was a significant contributing factor, but the root cause was deeper: lack of clear strategy, vision, and mission, and the lack of leadership who could make a decision, own the consequences, and iterate. The pods were a symptom of someone applying a trendy organizational model without understanding the underlying problems it was supposed to solve.
Did you have to let people go?
The contracted product managers were eventually released, but it was handled slowly and carefully over months. They came from the same agency as several contracted engineers who were brilliant. The gradual pace maintained the agency relationship so we could keep the engineers. Everyone was taken care of.
How did you rebuild trust with editorial?
By doing what I said I was going to do, over and over. Demonstrating that I understood what they needed. Communicating clearly about priorities and timelines. Actually delivering on commitments. And when we couldn't build something, finding solutions that worked for everyone instead of just saying no. Trust is rebuilt through consistent, demonstrated action – not through a single conversation.
More Case Studies
- Stride: 3x Productivity in 90 Days – Delivery Diagnostic for an 80-person team that was 5 months behind schedule
- Tallo: Strategic Clarity in 2 Weeks – Strategy Diagnostic for a career platform with plateauing growth
Ready to Find What's Broken?
The Delivery Diagnostic Sprint is $15,000 for a complete 2-week diagnostic with 30 days of follow-up support.
Email matthew@fieldway.org to schedule a discovery call.