Your Questions, Answered

Why Transformation Fails

  • They fail because people solve the right problem in the wrong order. A startup that builds a sales team before validating who they're selling to will generate pipeline activity that looks productive — and produces nothing. A corporate innovation team that runs a pilot without aligning internal stakeholders on success criteria will produce results nobody acts on. The pattern is consistent: organisations jump to downstream execution before upstream dependencies are resolved. My work focuses on diagnosing where that sequencing has broken — which is almost always earlier in the chain than people expect.

    → Read about the Critical Path Layers framework

  • It means the problem you're working on depends on a prior problem you haven't resolved yet. Pricing strategy depends on competitive positioning. Competitive positioning depends on ICP clarity. ICP clarity depends on whether the problem you're solving is real and specific enough to anchor a buying decision. When founders or corporate teams skip ahead, they don't get wrong answers — they get answers to the wrong question. The work looks productive. The metrics move. But the underlying dependency stays unresolved, and everything built on top of it is fragile.

  • Three signals. First, effort is high but outcomes don't compound — each win feels isolated rather than building on the last. Second, the same strategic questions keep resurfacing in different guises. Third, your team debates execution details (which channel, which message, which hire) without agreement on the fundamentals those decisions depend on. If you're arguing about how to sell before you've converged on who you're selling to and why they'd buy, you're downstream of your actual bottleneck.

    → Take the diagnostic

The Critical Path Layers Framework

  • The Critical Path Layers is a diagnostic framework I developed from coaching mutiple startups/scaleups across accelerator programmes. It reorganises 17 common coaching themes into five sequential dependency layers — from Foundations (Layer 0) through Market Clarity, Validation, Commercial Engine, to Scale Readiness (Layer 4). The core principle: each layer depends on the layer beneath it. Working on Layer 3 problems (sales, brand, pipeline) before Layer 1 is resolved (ICP, positioning, pricing) doesn't just waste time — it produces misleading signals that feel like progress. The framework exists in two editions: one for startup founders and one for corporate innovation teams.

    → Explore the full framework

  • Start from the bottom and work up. At each layer, test the gate criteria — specific conditions that should be true before the next layer becomes productive. Layer 0 asks: is the problem worth solving, and does the product address it at a basic level? Layer 1 asks: do you know exactly who buys, why they choose you, and what they'll pay? If you can't answer those with concrete, current evidence — not aspiration, not assumption — that's your layer. Most founders I work with believe they're at Layer 2 or 3. The diagnostic usually places them at Layer 1.

  • You get what I call downstream gravity — a pull toward the work that feels most like progress. In the accelerator cohorts I've coached, 49% of sessions focused on sales and scale (Layers 3–4); 11% on validation (Layer 2). The result is predictable: startups that invest in go-to-market before their ICP is validated build pipeline to the wrong buyers, produce case studies that don't generalise, and burn through runway generating activity rather than evidence. Skipping a layer doesn't produce failure — it produces something worse. It produces the illusion of traction.

POC and Pilot Failure

  • Because the technology was never the risk. The risk sits in the organisational machinery around the POC: unclear success criteria, no budget pathway from pilot to contract, a champion without decision-making authority, or a procurement process that takes longer than the pilot itself. I've seen POCs where the technology performed exactly as promised, the client contact was enthusiastic, and nothing happened for nine months. The blockers were internal to the corporate — budget validation cycles, stakeholder alignment gaps, competing priorities. The startup assumed the product needed to prove itself. The product wasn't the problem.

    → Read: Why Your POC Succeeded and Still Failed

  • It's a self-assessment tool I built for founders and corporate innovators navigating the gap between a successful pilot and an actual contract. Eighteen questions across five dimensions — from success criteria definition through stakeholder alignment to commercial readiness. The scoring uses what I call the "yes constraint": only concrete, current truths count as yes. "Not sure" counts as no. Aspiration counts as no. The value is in the pattern of your answers, not the total score. A POC that scores high on technical validation but low on internal champion strength has a specific, addressable problem — and a very different intervention from one where the scores are reversed.

    → Try the POC Lifecycle Diagnostic

  • Ask yourself five questions. Do you have written, pre-agreed success criteria — defined by the client, not by you? Does your internal champion have budget authority, or just enthusiasm? Is there a named procurement pathway from pilot completion to contract? Do the people evaluating the pilot include the people who would approve the purchase? And is the timeline for the pilot decision shorter than the corporate's next budget cycle? If more than two of those are "no" or "I'm not sure," the pilot is at risk regardless of how well the technology performs.

The Founder Bottleneck

  • You're the bottleneck when every critical decision routes through you — not because the decisions require your expertise, but because you haven't built the conditions for anyone else to make them. Symptoms: you're in every client call, every hire interview, every product decision. Your calendar is full and your team is waiting. The diagnostic question isn't "am I busy?" — everyone is busy. It's "what stops happening when I'm unavailable for a week?" If the answer is "most things," the bottleneck is structural, not circumstantial. It appears at every layer of the Critical Path, but the intervention changes depending on which layer you're in.

  • It's a cross-cutting dynamic in the Critical Path Layers framework — meaning it doesn't sit in one layer, it recurs across all of them with different diagnostic meaning each time. At Layer 0, the bottleneck is the founder's attachment to a specific solution rather than the underlying problem. At Layer 1, it's the founder selling on instinct rather than validated ICP data. At Layer 3, it's the founder as sole salesperson in a business that needs repeatable commercial processes. Same symptom (founder overload), different root cause, different intervention. Treating it as a time management problem misses the point entirely.

  • Not when they're tired of it — when the sales process is documented, repeatable, and validated against a defined ICP. If you hand off sales before those conditions are met, you're not delegating — you're outsourcing the discovery process to someone who doesn't have your context. The right sequence: the founder sells until the pattern is clear (who buys, why, what objections arise, what the cycle looks like), then codifies that pattern, then hires someone to execute it. Handing off sales is a Layer 3–4 move. If Layer 1 isn't resolved, the hire will fail and you'll conclude the problem is the salesperson. It isn't.

Diagnostic-First Coaching

  • It means the first job isn't solving a problem — it's making sure we're looking at the right one. Most founders arrive with a presenting problem: "I need to improve my pitch deck," "I need a go-to-market strategy," "I need to hire a CTO." The presenting problem is real, but it's usually a symptom of something upstream. Diagnostic-first coaching redirects the conversation to the actual dependency — the unresolved question that, if answered, would make the presenting problem either solvable or irrelevant. It's slower at the start, faster overall. You spend less time building things you later discard.

  • A consultant delivers answers. A coach helps founders find their own. In practice, my work sits at the intersection: I bring a diagnostic framework (the Critical Path Layers) and domain expertise (20+ years in strategic data and digital transformation), but I use them to sharpen the founder's thinking rather than replace it. The goal is to build the founder's capacity to diagnose their own situation — not to create dependency on external advice. If a founder leaves a session knowing what to do and why, the coaching worked. If they leave with a slide deck someone else made, it didn't.

  • Un-coaching is the philosophy underneath my practice. The premise: founders carry inherited assumptions about how business "should" work, how leaders "should" behave, what success "should" look like. These assumptions are often invisible — absorbed from previous employers, from startup mythology, from well-meaning mentors. They show up as reflexive decisions that feel like strategy but are actually conditioning. Un-coaching means surfacing those assumptions, testing them against the founder's actual situation, and releasing the ones that don't serve the current problem. It's not about adding more frameworks. It's about removing the ones that are getting in the way.

    → Learn how I work

  • Four mechanisms, which I collectively call the organisational immune response. First, initiative orphaning: the executive sponsor moves on, and no one inherits the mandate. Second, pilot-to-nowhere syndrome: pilots complete successfully but have no pathway to procurement or scale. Third, innovation theatre: the programme generates activity (events, scouting, reports) without accountability for outcomes. Fourth, the slow death of unfunded mandates: the initiative is "approved" but never resourced, left to compete for bandwidth against established priorities with established budgets. Each of these is a structural failure, not a people failure. The intervention is organisational design, not motivation.

    → Explore the corporate framework

  • t's my term for the pattern where large organisations neutralise new initiatives through structural mechanisms rather than deliberate opposition. Nobody kills the project — the project dies because the organisation's operating system isn't configured to support it. Governance cadences that don't match pilot timelines. Budget cycles that can't accommodate mid-year commitments. Success criteria defined by people who won't use the output. Stakeholder alignment that's assumed rather than built. The immune response isn't malicious. It's a feature of how large organisations maintain stability. The problem is that stability and innovation require different operating conditions, and most organisations haven't designed for both

  • Clock speed mismatch is the most common cause. A startup operates in weeks; a corporate operates in quarters. A pilot that takes the startup three weeks to deliver takes the corporate six months to evaluate, approve, and resource. By the time the corporate is ready to proceed, the startup's runway has shortened, the founding team has moved on to other priorities, or the technology has evolved past what was piloted. The fix isn't "move faster" — it's designing the collaboration so that the startup's value delivery cycle and the corporate's decision-making cycle are explicitly mapped and aligned from the start.

Corporate Innovation

Scaling Too Early

  • Test the gate criteria between Layer 2 and Layer 3 in the Critical Path Layers. You need at least one completed pilot with pre-defined success criteria met. The results must be packaged so that someone other than you can sell from them. The technical integration should be proven at pilot scope. And the path from pilot to contract should be mapped with organisational support on the buyer side. If any of those are missing, scaling will amplify the gaps rather than the traction. The most expensive mistake in startup growth isn't failing to scale — it's scaling before the foundation holds weight.

  • It's the pattern where founders and corporate teams gravitate toward downstream activity — sales, marketing, brand-building, hiring — before the upstream dependencies that make those activities productive are resolved. I call it a trap because it doesn't feel like a mistake. Building pipeline feels like progress. Launching a content strategy feels productive. Hiring a sales team feels like growth. But if your ICP isn't validated, your pipeline targets the wrong buyers. If your positioning isn't sharp, your content amplifies noise. The Layer 3 Trap is working hard on the right activities at the wrong time.

  • Because the sales team will optimise for closing — which means they'll pursue whoever is willing to buy, not necessarily who should buy. Without a validated ICP, the early deals look like traction but create a customer base that doesn't share common needs, can't be served efficiently, and generates case studies that don't generalise. The founder then faces a choice: keep serving a fragmented customer base that's expensive to support, or reset the ICP and explain to investors why the early customers don't represent the actual market. Both options are painful. Validating the ICP first — even when it feels slow — avoids the choice entirely.

Working with Aieutics

  • Three audiences. First, startup founders — typically post-product, pre-scale — who need to diagnose what's actually blocking growth rather than layering more activity on top of an unresolved bottleneck. Second, corporate innovation teams running programmes with startups, where the sticking points are usually organisational rather than technological. Third, VCs or accelerator and incubator programmes that want a structured coaching methodology grounded in evidence rather than instinct. I work as a solo practitioner — the thinking, the diagnostics, and the coaching all come from one person with 25 years of experience across Google, Microsoft, L'Oréal, P&G, and 30+ other organisations.

  • It depends on the context. For founders, it usually starts with a diagnostic session using the Critical Path Layers — identifying which layer you're actually in and what the binding constraint is. From there, we build a short intervention plan focused on the upstream dependency, not the presenting problem. Engagements range from a single diagnostic to ongoing coaching over several months. For corporates and programmes, the entry point is often a POC Lifecycle Diagnostic workshop or a programme design consultation. I don't do retainers for the sake of continuity — the engagement lasts as long as the diagnostic work justifies it.

  • Both, and the work is often connected. Corporate innovation teams and startup founders face the same structural problem from opposite sides: sequencing dependencies correctly. The corporate version of the Critical Path Layers adapts the framework for internal initiatives — where the "customer" is an internal stakeholder, the "market" is an internal budget holder, and the blockers are political as much as technical. If you're running a pilot programme, evaluating startup partners, or trying to move an innovation initiative from approved to funded, the diagnostic applies.

    → See the corporate framework