Here's the pattern I see in every startup that asks me about AI strategy.
Some employees are using it well. Some aren't using it at all. Some are afraid. A few are doing impressive things nobody else on the team understands. Marketing prompts one way, engineering prompts another, design is off doing its own thing entirely. The founder sits in the middle, watching everyone pull in different directions, knowing they need an "AI strategy" but having no idea what that actually means in practice.
The usual response is to buy tools. Or hire an "AI lead." Or send the team to a workshop. Or, the worst option, let a thousand flowers bloom and hope coherence emerges.
It doesn't emerge. It never emerges. What you get is AI chaos, not AI leverage.
I've now worked through this problem with enough startups to know that the answer isn't more tools or more training. The answer is something most founders already have but can't seem to use: the frameworks they already know work.
The real problem isn't knowledge - it's enforcement
DDD. OKRs. Lean Startup. Jobs to Be Done. Every founder I work with knows at least two of these. Most have read the books. Some have tried to implement them.
And almost nobody has succeeded - not because the frameworks are wrong, but because enforcement is brutally hard.
Take DDD. Domain-Driven Design says your entire company should speak the same language about what you're building. Marketing, product, and engineering should all mean the same thing when they say "customer" or "subscription" or "campaign." The domain model should be the shared mental model.
In theory, this is obviously right. In practice, it requires someone to define that language, write it down, get everyone to adopt it, catch deviations, and do that continuously as the company evolves. That's a full-time job nobody has budget for. So what happens is this: someone reads the Evans book, gets excited, defines some bounded contexts in a Notion doc, and six weeks later marketing is calling the same entity three different names and nobody notices.
The same thing happens with OKRs. You set them quarterly. They're great for two weeks. Then the daily grind takes over and nobody looks at them until the next planning cycle, when everyone quietly admits the previous quarter's OKRs didn't actually drive any decisions.
And Lean Startup. Build-measure-learn. Fast iteration cycles. Validate assumptions. Every founder nods along. Then they build for four months without talking to a customer because the team was busy and the build felt productive.
The frameworks aren't the problem. Enforcement is the problem. Keeping an entire company aligned to a set of principles, consistently, across every department, every day - that's the part that's always broken.
That's the part AI fixes.
These frameworks aren't competing - they're a control loop
Before I get to the AI part, I need to explain something about how these methodologies relate to each other. Most people treat them as separate tools you pick from. DDD or Lean Startup. OKRs or JTBD. That's wrong. They're sequential stages in a single system.
Think of it as a classic feedback control loop.
Jobs to Be Done is the input. It's where you discover what problem your customer actually needs solved. Not what features they want - what job they're hiring your product to do. This is the starting point of everything.
OKRs are the controller. Once you know the job, OKRs translate that into priorities. What matters right now? What do we measure? What tells us we're on track? OKRs take the discovery and turn it into direction.
Execution is the process. The actual work the company does - shipping features, running campaigns, closing deals. This is where most teams focus all their attention.
Lean Startup is the feedback. It measures what actually happened versus what you expected. Did the customer behave the way you predicted? Did the metric move? The feedback loops back into JTBD, refining your understanding of the job and starting the cycle again.
And DDD is the foundation everything sits on. It's not a step in the loop - it's the shared language that makes the loop work. Without DDD, your JTBD discoveries get lost in translation when they reach engineering. Your OKRs mean different things to different teams. Your Lean Startup feedback is muddy because marketing and product are measuring different definitions of the same concept.
DDD is the substrate. The other three are the process. The loop doesn't function without the substrate, and the substrate is useless without the loop.
Here's the sharp version: JTBD discovers what matters. OKRs prioritize it. The team executes. Lean Startup tells you whether it worked. DDD makes sure everyone involved in that cycle is speaking the same language the entire time.
That's the complete framework. It's not new - every piece of it has existed for decades. What's new is the ability to actually enforce it.
Three phases of making this real
When I work with a startup on this, the engagement follows three phases. The first doesn't involve AI at all. The second is where AI becomes the enforcement mechanism. The third is where leadership gets visibility into whether it's working.
Phase 1: Discovery and alignment
This is the human work. No shortcuts.
I sit with the founders and C-level executives and we do the JTBD discovery. What job is your customer actually hiring you for? Not the feature list - the underlying job. This takes a few sessions and some honest conversations with actual customers.
Then we translate that into DDD. We define the domain. We name the entities. We write down what "customer," "subscription," "lead," "campaign" - whatever the core concepts are - actually mean in this company. We build the vocabulary that every department will use.
Then we set OKRs that derive from the JTBD insights. Not the generic "grow revenue 20%" kind. Specific, measurable results that tell you whether your understanding of the customer's job is correct.
This is the foundation. It takes one to two weeks. It produces a set of documents - the domain model, the vocabulary, the OKRs - that become the company's source of truth. Nothing about this phase requires AI. It requires thinking clearly and writing things down.
Phase 2: AI-enforced execution
This is where it gets interesting.
Take everything from Phase 1 - the JTBD insights, the DDD vocabulary, the OKRs, the standards - and put it in a centralized knowledge base. In practice, this is usually a repo with markdown files. Nothing fancy.
Now, when a marketer builds a landing page, they work with AI that has access to that knowledge base. The AI knows the domain language. It knows the customer's job. It knows what the company's current priorities are. So when the marketer asks for feedback on their campaign, the review isn't generic - it's grounded in this company's definitions and this quarter's priorities.
When an engineer writes code, the AI reviews it against the domain model. Are the entities named correctly? Does the API reflect the vocabulary the whole company uses? Is this feature aligned with the current OKRs?
When a salesperson drafts an outreach email, the AI checks it against the JTBD insights. Are you talking about the job the customer actually needs done, or are you pitching features?
The enforcement becomes invisible. It's not a meeting where someone polices compliance. It's not an audit. It's baked into the workflow. Every person in the company, from the most junior hire to the C-level, works with an AI that keeps them aligned - and they barely notice it happening.
This is the part that was never possible before. You could always define the right frameworks. You could never enforce them across an entire organization without dedicating a person to it full-time. AI changes that math completely.
Phase 3: Visibility and accountability
The third phase gives leadership something they've never had: real-time insight into alignment.
When everyone's working through AI that's grounded in your knowledge base, you can see patterns. Where are teams drifting from the domain vocabulary? Which OKRs are actually driving decisions and which are being ignored? Where is the feedback loop breaking down?
This isn't surveillance. It's the same thing a good engineering manager does when they review PRs - except it scales across every department, continuously, without requiring a person's full attention.
The CEO can look at this and say: "Marketing has been using 'subscriber' to mean three different things for the last two weeks - that's going to cause problems when it reaches product." And fix it before it becomes a misaligned feature that ships to customers.
A note on mechanics
Every company has its own tool preferences. Some teams use Claude. Some use Gemini. Some use GPT. Some use different models for different tasks, and that's fine.
The framework is model-agnostic. The knowledge base is the constant. Whichever AI a team member uses, it pulls from the same source of truth and applies the same enforcement rules. The model is the engine - the knowledge base is the steering.
This matters because the AI landscape changes every few months. A framework that locks you into one provider is a framework with a shelf life. One that's grounded in your domain knowledge, expressed in plain documents that any model can consume, is a framework that survives the next model generation.
Why this wins
The pitch for most "AI strategy" consulting is: "let us show you cool things AI can do." That's the wrong pitch. Cool things don't compound. Alignment compounds.
Here's what actually changes when you run this framework:
Everyone speaks the same language. Not because they went to a workshop, but because their daily tools enforce it. A junior marketer hired last week is aligned with the founding team's vocabulary from day one, because the AI they work with is grounded in it.
Strategy changes propagate instantly. When the JTBD insights shift, you update the knowledge base. Every AI interaction across every department immediately reflects the new direction. No "rolling out the new strategy" over six weeks of all-hands meetings.
The feedback loop actually closes. Lean Startup's build-measure-learn works when the measurement is consistent across teams. With shared vocabulary and shared priorities enforced through AI, the data you collect actually means what you think it means.
You stop losing information at translation boundaries. The gap between what the founder says and what the engineer builds shrinks dramatically - because they're both working from the same documented domain model, enforced by the same system.
Who this is for - and who it isn't
This is for founders and C-level executives who know their company needs an AI strategy but don't want to bolt on tools and hope for the best. It's for teams that have tried to implement DDD or OKRs or Lean Startup and watched it erode within weeks. It's for anyone who's sat in a meeting and realized that marketing, product, and engineering are all building toward slightly different versions of the company.
It's not for teams looking for a quick win. Phase 1 is real work - sitting in a room, thinking hard about your domain, writing things down. There's no shortcut for that. The AI doesn't replace the thinking. It enforces the output of the thinking.
And it's not for teams that don't have the discipline to maintain the knowledge base. If the documents rot, the enforcement rots with them. This isn't a set-and-forget system. It's a living one, and it needs someone - a founder, a chief of staff, an ops lead - to own the source of truth.
If that sounds like overhead, consider the alternative: the status quo, where your frameworks exist in Notion docs nobody reads, your OKRs are reviewed once a quarter, and your team is aligned in theory and misaligned in practice.
That's the actual overhead. You're already paying it. You're just paying it in wasted cycles instead of disciplined maintenance.
What to do this week
If this resonates, here's a starting point that doesn't require hiring anyone or buying anything.
Day 1. Write down the five most important entities in your business. Customer, order, subscription - whatever your core domain objects are. Then ask three people from different departments what each one means. If they give you three different answers, you have a DDD problem.
Day 2. Look at your current OKRs. For each one, ask: did this OKR actually drive a decision in the last two weeks? If not, it's decoration, not direction.
Day 3. Pick one team - marketing, engineering, support - and have them use AI with a one-page brief of your domain vocabulary for one day. See whether the output is more aligned than usual.
Day 4. Ask your most recent hire what the company is building and why. Their answer tells you how well your translation layer is working.
Day 5. Write the JTBD statement for your product in one sentence. If you can't, that's where the work starts.
Five days. Five hours. No tools purchased. Just the beginning of a discipline that, once AI is enforcing it, compounds faster than anything else in your organization.
If you recognized your startup in this post, that's the diagnostic. If you want to talk about what the implementation looks like for your team, reach out or schedule a conversation.
