I took a startup framework built for products and retrofitted it for marketing
The Foundation Sprint was designed to validate a product in two days. The questions it asks are the same ones a marketer needs answered. So I bent it into a marketing tool and ran it through AI, step by step.
Most strategic frameworks are built for one job. The interesting part is what happens when you use them for another.
The Foundation Sprint is a good example. Jake Knapp and John Zeratsky, the people behind the Design Sprint, built it to help startups answer the hardest early questions before they write a line of code: who is the customer, what is the problem, who are we really competing against, and where do we differentiate. Two days, a team, a wall of sticky notes. The goal is to compress months of validation into 48 hours and avoid the most expensive startup mistake, which is building the wrong thing.
I am not a startup founder validating a product. I am a marketer, fifteen years in B2B, ex-AWS EMEA. My problem was different. I needed to understand a complex enterprise market: who buys, why, what stops them, who the real competition is. When I looked at the Foundation Sprint, the questions were almost identical to mine. The framework was built for product. The questions were marketing questions.
So I retrofitted it.
Why a product tool fit a marketing problem
The reason the fit works is that validating a product and reading a market ask the same opening questions. A founder validating a product needs to know the customer, the problem, the competition, and the edge. A marketer entering a market needs exactly the same four things. The framework does not care whether you call the output a product spec or a market read.
What the Foundation Sprint added that an informal market scan lacks was discipline and speed. It forces you to answer the customer question before the problem question, and the problem question before the competition question. No jumping ahead to conclusions. In marketing, jumping ahead is the default, and it is why so many campaigns rest on a customer nobody actually defined.
What I changed when I retrofitted it
The original is built for one product and one startup. My market was not one thing. It was a complex enterprise landscape with many distinct buyers.
So I made three changes.
First, I expanded the customer step. Instead of defining one ideal customer, I had the models generate fifteen specific micro-segments, then distilled them down to three buying personas: the economic buyer who signs the budget, the technical decision-maker who shapes the shortlist, and the practitioner whose veto can kill the deal. Fifteen is research. Three is a decision. Choosing which segments mattered and which to drop was the real work, because that judgment rests on knowing the market, and the model does not.
Second, I rebuilt the problem step around real evidence. Rather than a team's assumptions on sticky notes, I pulled the actual language buyers use, their frustrations as they wrote them in forums and reports, so the problem statement rested on real words rather than on what I imagined the customer felt.
Third, I kept the differentiation step almost intact. The 2x2 differentiation map, finding the axis where you could win and a competitor cannot follow, is the strongest part of the original framework. I did not touch it. The empty quadrant is the insight.
Where AI came in
The original Foundation Sprint runs as a two-day workshop. I ran the analysis through AI instead, with the model doing the research and the first drafts that a workshop normally fills a room to produce.
The first step was getting the framework into a form I could work with. I listened to Jake Knapp and John Zeratsky explain the Foundation Sprint on a podcast, then had it transcribed. A transcript beats listening, because you can search it, pull the steps out of it, and feed it to a model.
I fed that transcript into Microsoft Copilot, the sanctioned AI route inside a large enterprise, and had it pull out the exact steps of the sprint: customer, problem, competition, differentiation. One detail worth knowing for anyone working inside Copilot: the default model selector says "auto," and most people leave it there. Click it and a dropdown appears with the underlying models. Copilot on auto did not give me what I needed, so I switched to a specific GPT model and the quality jumped. The lesson is small but real: do not accept the default just because it is the default.
Then I went step by step. For each step of the sprint, I wrote a marketing version of the prompt and ran it on its own. Not all four steps in one go. One question, answered fully, before the next. That is the discipline the framework enforces with a facilitator, and I enforced it through the structure of the prompts.
Here is the shape of the customer step:
Act as my strategic research partner. We are executing the customer step of the Foundation Sprint. Brainstorm all potential customer segments with a short rationale for each. Then recommend the most important customers, justified by pain severity, willingness to pay, market accessibility, and strategic fit. Then build a detailed profile of the chosen segment: role, a day in their life, core problems in their own words.
A product founder would ask "who is the ideal customer for this product." I asked "who are the buying personas in this market." Same question, different noun. That translation, repeated for every step, is the whole retrofit.
One thing I learned too late: context fills up fast. Run all of this in a single long chat and the model starts forgetting the early steps by the time you reach the later ones, the same context problem I ran into with my CLAUDE.md file. The fix is to run it inside a dedicated project or workspace, so each step keeps its own clean context instead of drowning in the last one. I figured that out halfway through.
What this taught me
Two things.
The first is about frameworks. A good framework is not locked to the job it was built for. The Foundation Sprint was built for founders validating products. It works just as well for a marketer reading a market, because the underlying questions are the same. The skill is recognizing that, not inventing a new framework from scratch.
The second is about AI. The model did not do the thinking. It did the synthesis. It read more than I could and drafted faster than I could, but it did not know which of fifteen segments mattered most, or which difference a buyer would actually care about. Where the output was thin or generic, judgment had to fill the gap, and that judgment came from years of doing this work, not from the model. A marketer who has segmented markets and built personas writes better prompts for this, because the framework lives in the prompt, and the judgment lives in the marketer.
I did not use AI to build a strategy. I borrowed a product framework, bent it to a marketing question, and used AI to run it at a speed that normally takes a two-day workshop. What I had at the end was a clear read on three buyers and the place I could win, in days instead of months.
CoNudge is the B2B2C SaaS for personal trainers I am building. Pilot starts August 2026. conudge.com