Most technical leaders know the pain. You get partway into an ambitious AI project, then hit a wall. You are not sure how to start, or you get so far and then stall out, lost in the noise of options and half-finished experiments.
Recently I tackled this head on. I did this live, in front of an audience. I used a framework that finally made the difference.
The challenge: could I take a complex change, break it down, and actually finish it, live on stream? My answer: yes, with the right approach. Here is exactly how I did it.
The Two Stage Method: Dictate, Then Delegate
I have learned that the biggest blocker for most teams using AI is lack of clarity, far more than technical skill, ability to review, or the complexity of the change. You need a way to cut through the noise, get a plan, and keep moving. My two stage method is simple.
- Rough Guide: I dictate everything I know into Wispr Flow1. Sources, ideas, what needs figuring out. I get it all out, no matter how messy.
- Plan and Execute: I ask for a plan in
docs/changes. Then I start a new chat, clearing out all the cruft. From there, I go step by step, focusing only on the next action.
This approach gets you from chaos to clarity. It is not just for solo work. It is how I help teams get unstuck and moving again.
Vision, Strategy, Execution, Metrics
I discovered that my approach is basically the same as the VSEM (Vision, Strategy, Execution, Metrics) framework. Let’s update it for the AI age:
-
Vision: Let AI help you explore possibilities. Ask it to generate scenarios, user stories, and potential outcomes. Use prompts like “What would success look like if we could…” to expand your thinking beyond conventional boundaries. Using AI as a therapist can help here.
-
Strategy: Use AI to break down your vision into actionable components. Ask questions like “What are the key technical challenges we need to solve?” or “What dependencies should we consider?” AI can help identify blind spots and suggest alternative approaches. This is the dictation and clarification step. You can even build small scripts to test things out, or prototype using a no-code tool (see my big list of tools if you need guidance)
-
Execution: This is where AI shines. You have a plan broken in to meaninful discrete steps. The key is to provide clear context and constraints, then let AI do the heavy lifting. Use an IDE or indepedent coding agents if you’ve managed to bring enough clarity. You might even be able to run some of these in parallel.
-
Metrics: Focus on measuring the impact of your AI-driven changes across your organisation. How many rejected pull requests are there due to AI slop? How productive are developers feeling with AI? Track the time saved through AI assistance (even subjectively). Use AI to help you identify these metrics and suggest ways to measure them effectively.
This aligns perfectly with David Allen’s Getting Things Done2 philosophy of transforming mental tasks into concrete, actionable items:
“The next action should be the next physical, visible activity that will move the project toward completion.” — David Allen, Getting Things Done
The magic is in making the work concrete and actionable - and AI is the perfect tool for this.
What Happened Live on Stream
On 23 May, I put this into practice. I started with a rough brain dump, then used the VSEM framework to structure the work. The result: I got further, faster, and with less stress. The audience saw every step. What worked, what did not, and how the framework kept things moving.
The key to success is to begin with what you know and refine as you go, rather than waiting for perfect clarity. Frameworks like VSEM help maintain alignment and accountability across the team. Remember to reset context frequently - fresh starts are more effective than endless iteration.
Join my next live webinar here.
-
Wispr Flow is my go-to dictation tool. I use it to capture my thoughts and ideas. This is a referral link, but I’d recommend it even if they weren’t giving me free credit :) ↩
-
Getting Things Done by David Allen is a classic productivity system that I’ve used for about 20 years. I have a couple of really old articles on this blog if you’d like a blast from the past. ↩