Stop Delivering Recommendations

For the past 15 years, my job was to help teams think differently. Facilitate workshops. Run sprints. Help people understand their users, generate ideas, and prioritize what to build next. And I was good at it. The workshops were energizing. The ideas were often genuinely brilliant. The clients left feeling like something important had happened.

Then most of it died in a drawer.

Not because the ideas were bad. Not because the teams lacked commitment. But because there was always a gap between the sprint and the moment someone actually started building. Weeks turned into months. Momentum faded. Priorities shifted. The beautiful prototype deck sat in a shared drive while the organization moved on to the next quarter's fires.

Two years ago, something changed. I started building things myself — not as a side project, but as part of the sprint. Working software, during the same week as the discovery and ideation. And it changed everything about what innovation consulting can deliver.

What a Sprint Used to Deliver

Let me be honest about what the output of a typical innovation sprint looks like. At the basic level, you get a concept deck — a well-structured presentation with recommendations for what to build and how. It's professional, it's thoughtful, and it needs six to twelve months of implementation work before anything real exists.

A step up from that: you get a clickable prototype. Something in Figma that looks like a real product but doesn't actually do anything. It's useful for testing concepts with users, but it's still a representation of an idea, not the idea itself.

The third level is what became possible when I added building to the facilitation. A working tool — with a database, real business logic, and an interface that actual users can operate. Not a mockup that simulates the experience. The experience itself. Deployed the same week the sprint happened.

The Gap Where Ideas Go to Die

I've watched this play out at dozens of organizations. The sprint ends on Friday. Everyone is aligned. The executive sponsor is enthusiastic. And then the results enter the corporate immune system.

Budget approvals. Architecture reviews. Security assessments. Vendor selection. Resource allocation. Each one reasonable on its own. Together, they form a gauntlet that most sprint results don't survive. By the time someone gets green-lit to start building, the champion who drove the sprint has often moved to a different team. The context that made the idea urgent has shifted. The energy is gone.

This was the most frustrating part of my work for years. Not the workshops — those were always good. The aftermath. Knowing that the quality of the insight was there, the alignment was there, and it would probably still come to nothing.

What Changed

When I started using AI-assisted coding tools, I realized something: the gap didn't have to exist. Not because the tools are magic — they're not. But because they collapse the time between "we understand the problem" and "here's something that works" from months to hours.

In a recent sprint, I spent the first two days doing what I've always done — observing operations, talking to the people who do the work, framing the problem with the team. Classic facilitation. By Wednesday morning, I switched from facilitating to building. By Thursday evening, the team was using a working application on their devices. Not clicking through a prototype — entering real data into a real tool.

The feedback on Friday was unlike anything I'd experienced in years of sprints. Not "I imagine this could work" but "this field is useless, move the status indicator to the top, and can we add an alert for overdue tasks?" Concrete, specific, immediately actionable — because the tool was real, so the feedback was real.

Why This Isn't About Coding

I want to be careful here. This isn't about coding. Large consultancies build things too — Accenture, Deloitte, McKinsey Digital all have development teams numbering in the thousands. The building capability exists. What doesn't exist is compression. In a typical large consultancy engagement, the strategy team runs the sprint. They produce insights and recommendations. Then there's a handoff: a brief gets written, a requirements document gets created, a development team that never met the users starts building. The original insight gets compressed into a PowerPoint, translated through a specs document, and diluted through three layers of project management. By the time something gets built, the understanding that made the idea good is gone. The difference isn't having developers. It's having zero handoff. When the same person who watched the user struggle on Monday is writing the code on Wednesday, nothing gets lost in translation. No brief can capture what it feels like to watch someone check three screens before making a decision they should be able to make in one tap. That context lives in the builder's head — but only if the builder was in the room.

The facilitation is still essential. Understanding the problem space, running good discovery, synthesizing insights, facilitating alignment — none of that changes. If anything, it becomes more important. Because when you can build fast, the quality of what you build depends entirely on the quality of your understanding. Speed without insight just means you build the wrong thing faster.

What changes is the second half. Instead of handing over a deck and hoping someone builds it, you complete the loop yourself. Understand → Design → Build → Test. All in the same sprint. All with the same team. All informed by the same conversations with real users.

What This Means If You're Buying Consulting

If you're an innovation lead or head of transformation, here's what I'd want you to think about: the next time you brief a consulting team for an innovation sprint, ask what the deliverable will be. Not conceptually — literally. Will you have a slide deck? A Figma prototype? Or a working tool that your team can use on Monday?

The answer to that question tells you everything about what kind of value you're buying. A concept deck buys you alignment and ideas. A prototype buys you validated assumptions. A working tool buys you a head start on implementation — and sometimes, the implementation itself.

The best consulting doesn't end with a recommendation. It ends with something you can use. Not evaluate, not review, not approve — use.

I still facilitate. I still run discovery sessions and ideation workshops and prototype sprints. That work matters as much as it ever did. But now it's half of what I do, not all of it. The other half is making things real. And that combination — the ability to understand a problem deeply and then build the solution in the same breath — is the thing that finally closed the gap I'd been staring at for 15 years.