Vision-to-Value

Here is a common version of the consultant approach. A company spends six months with a top-tier consulting firm. The deliverables look impressive: a long AI strategy document, a technical architecture diagram that could wallpaper a conference room, and a detailed 18-month roadmap with color-coded phases. What they get: No working software. No business impact. No team buy-in. Just a really expensive deck that executives can't explain to their teams and engineers can't build from. This is the classic consultant approach - lots of talk, no action, vision without execution.

The other extreme is just as common. A team buys an AI platform, gets it installed, runs through a two-day training, and then nothing. The tool sits there, no one uses it, no processes change, no value gets created. This is the vendor approach - execution without vision, tools without transformation. Both leave the same gap: organizations stuck between "we should do something with AI" and "this AI thing made us money."

The pattern repeats everywhere. Leadership knows AI matters, they see the headlines, they feel the competitive pressure. So they either hire consultants to think about it or buy tools to implement it. Neither works. Consultants write strategy decks that gather dust, vendors ship software that no one adopts. Both charge a lot, neither delivers measurable value.

The root cause isn't the consultants or the vendors, it's the approach. Strategy without execution creates theoretical futures that never materialize. Execution without strategy creates expensive solutions to the wrong problems. What organizations actually need is something different entirely: partners who deliver tangible value fast, who show rather than tell, who measure business impact instead of just technical functionality, who stick around to ensure adoption instead of just deployment. They need what we call "anti-consultants."

The core philosophy is simple: speed to value. NOT "Here's a 500K proposal for 12 months of work." Instead: "Here's the vision of what's possible. Let's validate and deliver value in six weeks." This shifts everything. Traditional consultants write decks about what could be, anti-consultants build prototypes of what will be. Tangible beats theoretical every time. Vendors ship software and call it done, anti-consultants measure business impact and keep optimizing. Adoption matters more than deployment. Both consultants and vendors focus on deliverables, anti-consultants focus on value.

But value means something specific. Not just "the software works" or "we shipped the thing." Value has five dimensions, and they all matter:

The last two get all the attention. But the first three are what make the last two sustainable. The anti-consultant approach has three North Star principles:

Most AI initiatives fail because organizations apply consultant thinking (strategy without execution) or vendor thinking (execution without strategy). The anti-consultant approach is different: vision and execution together, strategy validated through building, partnerships measured by sustained value. That's the philosophy. Now here's how it works in practice.

The Vision-to-Value framework is how we operationalize the anti-consultant approach. It's a structured pipeline that takes organizations from "we should do something with AI" to "this AI thing made us measurable money." The structure is deliberate:

Each phase answers a specific validation question. Each has clear artifacts and success criteria. Each can stand alone or flow into the next. The framework is designed for speed and iteration, not waterfall perfection. Time-boxed phases force decisions, clear validation gates prevent scope creep, built-in learning cycles allow pivots based on evidence instead of opinions.

And critically, the framework maintains focus on value at every stage - not just at the end, not just when the software ships, but from the first conversation through continuous evolution. Because here's the thing: turning software on isn't value. Getting people to use it is value. Measuring business impact is value. Learning and adapting is value. Building organizational capability is value. The Vision-to-Value framework keeps all five dimensions of value in focus throughout the entire journey. Let's break down how each phase works.

Before investing in discovery, organizations need to know: Can you actually do this type of work? Not "can you solve our specific problem?" That comes later. The question here is simpler: Do you have credibility? Have you done similar things before? Should we invest time learning more?

Traditional consultants would write a proposal, maybe do a pitch deck, and talk about their methodology and their team. The anti-consultant approach is different: we show actual work. We pull relevant case studies (not generic "here's our AI practice" marketing materials, but specific examples of similar problems solved for similar organizations with real outcomes and real numbers). We create quick mockups, prototypes, and flows that make the potential future state visible and tangible, not theoretical.

The key detail: all of this happens without dedicated engineering. Engineering might advise on approach, but they're not building anything yet, which keeps it fast and focused. The goal is rapid credibility check: Can this firm actually do what they're claiming? Have they built things like what we need? Do they understand our type of problem?

This phase takes hours, not days. It's fast because we're showing existing work and creating lightweight artifacts. The investment is minimal, the signal is strong. The validation gate is simple: Does the client believe we can do this type of work? Are they ready to invest in actual discovery? If yes, we move forward. If no, we both saved time and money by finding out fast.

This is the anti-consultant principle in action: show, don't tell. Even before a formal engagement starts.

Most clients arrive solution-oriented: "We need an agent" or "We want to automate this process" or "Can you build us an AI tool for X?" Maybe, but probably not exactly what they described. The job in Phase 1 isn't to validate their proposed solution. It's to validate the actual problem and desired outcome. Is this the right thing to be working on? Is this the right experience or result?

This is problem framing and visioning work. We run rapid discovery, not exhaustive analysis. Not months of research, but fast focused exploration of the actual problem, the current state, and the desired future state. We validate assumptions: Clients usually have theories about what's broken and what would fix it, and those theories need testing. What do the people actually doing the work say? What does the data show? Where are the real pain points?

And critically, we "give them a taste." We make the vision tangible and experienceable, not just theoretical. This means creating artifacts people can react to: mockups showing what the future experience could look like, experience narratives walking through a day in the life post-transformation, and quick prototypes demonstrating key interactions. The artifacts provide rapid feedback, validate the concept, and help stakeholders see the future state instead of just hearing about it.

And like Pre-Sales, many of these can be created without dedicated engineering. Engineering advises on what's possible and sensible, but the artifacts themselves are lightweight.

By the end of Phase 1, three things need to be true. First, consensus: the philosophical buy-in. Do stakeholders agree this is the right problem to solve? Do they believe the proposed outcome would create value? This is the "why" alignment. Second, alignment: the tactical agreement. Are we aligned on what success looks like, on how we'll measure it, and on what we're actually building toward? This is the "what" and "how" alignment. Third, clarity: Can everyone articulate what we're trying to achieve? Is the vision tangible enough that people outside the project team can understand it? Are success metrics defined and measurable?

Without all three, moving to the next step is premature. The foundation isn't solid enough. The value delivered in this phase isn't software. It's clarity, consensus, and alignment. Those are what make everything else possible.

Now we know it's the right problem and the right desired outcome. Next question: Is this the right solution approach? Not "can we build the exact final version?" Just: Is this general technical approach sound?

This is where we demonstrate capability, prove credibility, and show that the envisioned solution is technically feasible. We create sample workflows, show directional UX aligned to the problem statement, and build lightweight demonstrations of the core concept.

The key word is "directional." This isn't the final design. It's not production-ready. It's showing the path, validating the approach, and getting early feedback on whether this feels right. The artifacts might include a presentation with possible shared interactive prototype, sample workflow demonstrations, and directional UX showing key interactions.

And again, this could be created without dedicated engineering. Engineering is consulted and advising, validating the approach is sound, but they might not be building the demo.

The goal is proving credibility and technical feasibility in general terms. Can this type of solution work? Is the technical approach sensible? Are there any obvious red flags? The validation gate asks: Does the technical approach make sense? Does the client believe this could work in theory? Are there technical concerns that need addressing before going further?

This phase de-risks the path forward by preventing investment in full feasibility testing for an approach that fundamentally won't work. And it maintains speed: two to three weeks to get signal on whether the solution direction is sound, not months of detailed planning.

Tech Demo answered "can this be done in general?" Feasibility Test answers a more specific question: "Can this be done for us? In our environment? With our tech stack? For our users?"

This is where we get concrete. Test the concept with the selected tech stack. Validate it works in their actual ecosystem. Confirm the user experience makes sense for their specific workflows. The artifacts shift from sample to specific:

This phase requires deeper technical engagement. We're not just showing what's possible. We're proving it works in their specific situation. The validation questions become pointed: Does this work with our tech stack? Can our users actually use this? Do we have the data and infrastructure needed? Are we aligned on what "success" looks like in our specific context?

The value delivered is concrete feasibility proof. Not theoretical "this could work." Actual "this does work in your environment." And it delivers alignment and buy-in on the future state vision and value. When stakeholders can see it working in their actual systems with their actual workflows, belief shifts from "maybe" to "yes."

Why split Tech Demo and Feasibility Test into separate sub-phases? Because they answer different questions and require different investments. Tech Demo prevents wasting time on a fundamentally wrong technical approach (fast and lightweight). Feasibility Test prevents building something that won't work in the client's specific environment (more involved but still bounded). Separating them allows faster iteration and lower-cost pivots. If the Tech Demo reveals issues, we can adjust the approach without having invested in environment-specific testing. If Feasibility Test reveals environment constraints, we know the general approach works and just need to adapt to context. Together, these two sub-phases provide clear requirements, technical feasibility proof, and success criteria alignment. Everything needed to build with confidence.

This is where it gets real. Not theoretical, not sample. Real. We build a practical application that brings the validated vision to life with the goal of realizing actual value: business impact and ROI.

This phase has multiple names: Proof of Value, Pilot, Minimum Lovable Product, MVP. The common thread is "working solution deployed to real users with real data to measure real outcomes." The deliverables shift from prototypes to products: pilot design documenting the solution, coded application (not production-ready but functional), tangible testable solution in the client ecosystem with client data, usage and impact metrics, and user adoption insights.

This is where dedicated engineering becomes critical. We're building actual software now, not mockups or demos, so the investment scales accordingly. But the timeline doesn't balloon: four to six weeks. Because we've already validated the approach, tested feasibility, and defined clear requirements, we're not figuring it out as we build. We're executing against a validated plan.

The validation question is precise: Does this actually drive business impact and ROI? Not "does the technology work?" (that was Phase 2) or "can users access it?" (that's table stakes). The real questions are: Are we moving the key metrics we defined in Phase 1? Are users adopting this? What's the measured business impact? Is the ROI compelling enough to continue? This is why we call it Proof of Value, not Proof of Concept. Technology working doesn't equal value. Value equals business impact plus user adoption plus measurable outcomes.

This is the critical juncture where most traditional approaches fail. They launch software and declare victory. But launching isn't the goal. Value is the goal. Proof of Value puts measurement front and center. We only succeed if the client succeeds, if the business impact is real, if the users adopt it, and if the metrics move. That's what makes this anti-consultant work: not delivering software, but delivering outcomes.

Proof of Value validated the core concept delivers business impact. Now what? Traditional consulting: End of engagement, hand it off, write the final report, move on. Traditional vendors: Renewal conversation, upsell to premium tier, send to customer success team. Anti-consultants: This is where the real work begins.

Phases 4 through 6 aren't new phases in the traditional sense. They're iterations, versions, continuous evolution of the proven valuable foundation. The structure is simple: Each version builds on the last, each version delivers incremental value, and each version is separated by a QBR (Quarterly Business Review).

Example version evolution: v2.0 might expand scope to more users or additional workflows. v3.0 might add new capabilities based on learnings from v2.0. v4.0 might integrate with additional systems or scale to new departments.

The pattern continues as long as there's value to unlock and partnership to maintain. This is "decades, not deals" in practice: not a one-time project with an end date, but a continuous partnership with ongoing evolution.

We often host Quarterly Business Reviews (QBRs) with clients. The QBRs provide regular checkpoints to review what's working, analyze what's not, measure business impact, plan the next version, and ensure value continues to compound.

The key principle: Don't disappear after proving value. Stick around to ensure it scales and sustains.

At some point, the question becomes: How does this work long-term? There are two paths, and the right answer is often "both."

• Path 1: Managed Services: The client focuses on their business while we handle ongoing technical operations, support, and optimization. This makes sense when the client doesn't have internal capability or capacity, the technology requires specialized expertise to maintain, speed and reliability matter more than control, or the client wants predictable costs and outcomes. This is often billed through a partnership model (not hourly, not project-based) as a sustained relationship with aligned incentives.

• Path 2: Transform to Product Organization: We help the client build internal capability: operating model, AI agents, talent, processes, and tools. The goal is self-sufficiency through transfer of knowledge and ownership, enabling them to maintain and evolve without us. This makes sense when the client has the appetite to build internal capability, the technology is core to their competitive advantage, they want full control and ownership, or they have the resources to invest in talent and training.

• The Reality: Often Both: Most clients need managed services while building internal capability through a gradual transition based on their maturity and readiness. We might handle technical operations while training their team, run the systems while helping them hire and onboard internal talent, and maintain speed while building their capacity. "Possibility for both until client maturity enables self-sufficiency."

This flexibility is what makes the partnership sustainable. We're not trying to create dependency. We're trying to create value, however that best works for the client's situation and timeline. The anti-consultant approach means meeting clients where they are and helping them get where they want to go, whether that's ongoing partnership, capability building, or both.

Understanding the phases is one thing. Understanding the principles that make the phases effective is another.

• "Anti-Consultants" - Show, Don't Tell: Consultants write decks about what could be. We build prototypes of what will be. The difference matters: decks are theoretical, prototypes are tangible. People can see them, touch them, react to them, and decide based on real artifacts instead of abstract concepts.

• "Give 'Em a Taste" Early and Often: Don't wait until Phase 3 to make the vision tangible. Even in Discovery, create experienceable artifacts: mockups, narratives, quick prototypes, things that help clients "see" the future state. A taste of what it could be like, a glimpse of the future, enough to spark imagination and conviction.

• Multiple Types of Validation: The framework has multiple phases because it asks multiple different validation questions. Don't conflate them, don't skip any. Early exploration asks "Can you do this type of work?" Discovery asks "Is this the right problem and outcome?" Tech Demo asks "Can this be done?" Feasibility Test asks "Can this be done for us?" Proof of Value asks "Does this deliver business impact?"

• Engineering as Advisor, Not Always Builder: Early Exploration, Discovery, and Tech Demo often don't require dedicated engineering resources. Engineering advises on approach, validates technical thinking, and ensures we're not proposing impossible solutions. But the artifacts themselves can be created by designers, strategists, and product thinkers, which keeps these phases fast and cost-effective.

• Consensus Before Alignment: Consensus is philosophical agreement (the "why"). Alignment is tactical agreement (the "what" and "how"). You need consensus before alignment. Without philosophical buy-in, tactical agreements are fragile. With strong consensus, tactical disagreements are navigable.

• Value Is Multidimensional: Value is not just "does the software work?" Value is outcome, and outcome has five dimensions: Clarity, Alignment and Consensus, Upskilling, Make money, and Save money. All five matter. Measure all five. Deliver all five.

• Speed to Value as Competitive Advantage: The framework is designed for speed (not rush, but speed): working intentionally and efficiently, measured by four factors (Time, Effort, Energy and Focus, Bodies). Maintain focus on speed to value through phase time-boxing, artifact selection, and the engineering-as-advisor model.

• Decades, Not Deals: Traditional consulting is project-based. Traditional vendors are transaction-based. Anti-consultants are partnership-based with continuous evolution, ongoing value creation, shared success metrics, and long-term relationships. Proof of Value isn't the end. It's the beginning of continuous evolution.

Most teams use POC, POV, Prototype, Pilot, and MVP interchangeably. This creates real problems. The confusion causes scope creep, wasted investment, misaligned expectations, and lost opportunity. The Vision-to-Value framework provides clarity through precise terminology:

Why This Clarity Matters:

Clear language prevents scope creep. When everyone knows what "Feasibility Test" means versus "Proof of Value," expectations align. The client knows what to expect at each stage. The team knows what "done" looks like. Investment matches validation level.

The Rule: If you're not sure which term to use, ask: What question are we trying to answer? Then use the term that matches the question. Match the terminology to the validation question. Eliminate confusion.

Now that you understand the framework, here's how to use it.

Audit Your Current AI Initiative:

Most organizations are stuck somewhere in the pipeline. Figure out where:

Questions to Ask Your Team:

Warning Signs You're Off Track:

Vision-to-Value isn't just a process. It's a philosophy. Anti-consultant thinking means showing instead of telling, building instead of theorizing, and measuring outcomes instead of just outputs. Speed to value means working in weeks instead of quarters, focusing on tangible results instead of theoretical possibilities, and making decisions based on evidence instead of opinions. Partnership thinking means decades instead of deals, continuous evolution instead of one-off projects, and shared success with clients.

What makes it work: Clear validation questions at each stage. Multiple types of proof. Engineering as advisor until it's time to build. Focus on business impact, not just technical delivery.

The organizations that win with AI aren't the ones with the best consultants or the fanciest tools. They're the ones that maintain relentless focus on delivering measurable value, fast. They know the difference between vision and execution, and they do both. They validate assumptions through tangible artifacts, not theoretical debates. They measure success by business impact, not project completion. They build partnerships that compound value over time, not vendor relationships that extract value through renewals. That's the anti-consultant approach. That's Vision-to-Value.

Your next steps: Use this framework to audit where you're stuck right now. Time-box the next 4-6 weeks. Focus on speed to tangible. Remember: The goal isn't perfection. It's progress. Measured value. Real outcomes. The software working is table stakes. The business benefiting is the goal.

Show, don't tell. Give them a taste. Maintain speed to value. That's how you turn AI strategy into results.

Onward & upward 🤘