AI Sprint: Choosing the Right Problem — Day 2 (A Nine-Step Worksheet from Pain Inventory to PRD, and the Honest Screen for Whether AI Belongs at All)

The whole session is one artifact: a worksheet that carries a single problem from raw observation to a build-ready brief across nine numbered steps. The split is the point - 'w 1, w 2, w 3 is completely non AI. It is pure problem solving. W 4 onwards is where AI fitment comes into the place.' Steps are sequential and skipping ahead breaks the later ones, because W4 screens the root cause found in W3 and W9 writes up the shape chosen in W6. One worksheet per problem per week; take a fresh copy for the next one. The framework is not invented - it blends and simplifies IDEO design thinking and Google PAIR.

Dileep opens with evidence rather than exhortation. The first citation is a CSCW conference study from around 2020 - 'even before AI came with the picture' - that tracked roughly 590 hackathon projects: about 35% showed some activity straight after the event, 17% by day six, 3.5% by five months. The second is the MIT 2025 report that went viral, in which 95% of 300 surveyed AI projects showed weak P&L impact. His reading of both is the same: the failure is upstream of the tooling. People pick a problem they are not motivated by, or one that was never AI-shaped, and the build dies quietly. Hence a whole session on selection.

Before setting the exercise, Dileep widens the definition so nobody opts out for lack of engineering. A solution can be a saved prompt, a custom GPT or project, a skill, spreadsheet AI, a workflow automation, or a vibe-coded product - six rungs on the same ladder. He then time-boxes the whole thing to seven days, invoking Parkinson's Law, and sets the data rules: no passwords, no personally identifiable information, use dummy data. Finally he reframes the guiding question. Not 'can I use AI here?' - which invites you to force it - but 'how might I solve this, and where could AI fit?'

W1 asks for about ten recurring pains from roughly the last two working weeks - recency bias is deliberate, though the window can be widened. The seed prompts are designed to surface friction rather than wishes: 'if I were training a new coworker, what would I teach them first?' and what gets retyped or re-checked 'because two systems do not talk to each other'. Each entry must be quantified - what concretely happened, how often, minutes lost each time, who else is affected - because W4 will later do ROI arithmetic on exactly those numbers. AI is banned for this step outright. And the filter at the end is painkiller versus vitamin: things that would merely make you happier 'rarely succeeded'.

Mid-exercise, Dileep pauses on a risk he heard described on an entrepreneurs' podcast. The transcript mangles the term - 'intuition thrust', 'intuition trust', 'intuition rushed' - and he apologises for his own pronunciation, but the idea he describes is unmistakable: 'if you have delegated your judgment to LLMs for a very long time, once you stop using LLMs, your intuition reduces.' He compares it directly to brain atrophy and to a muscle that weakens from disuse. It is offered as a caution inside a pro-AI framework, not against it, and it is the reason W1 to W3 are handwritten: the exercise deliberately claws some decisions back.

W2 is a five-minute narrowing to exactly one problem for the week, and the trap it exists to catch is the disguised solution. 'Remind my team' is not a problem - it is a fix someone has already chosen, which quietly forecloses every other option and skips the root cause entirely. The supporting case study is the attendance app: a purpose-built app failed, and the working answer turned out to be a selfie taken through WhatsApp's camera at the building entrance and exit. The lesson is to embed the fix in a habit that already exists rather than asking people to adopt a new one - a constraint that should shape the shape you pick at W6.

W3 is twelve minutes of driving one pain down to a root cause by asking why about five times. The rule that makes it work is structural: the chain of 'because' statements has to hold together end to end, and 'if a because does not connect to the previous one, the Socratic framing is incomplete' and has to be redone. The worked examples all land somewhere the surface never suggested. 'I read all 34 notes by hand every day' bottoms out at 'the summary was never the rep's job. It was mine' - an ownership problem. A calendar-overload complaint bottoms out as a delegation problem, not a scheduling one. Dileep explicitly rejects stopping at vague causes like 'the system is bad' or 'how the org is structured'; those are not specific enough to build against.

W4 is the honest part, and it is where most candidate problems should die. Part A lists disqualifiers - conditions under which the task should be narrowed or dropped, one of which is named explicitly: a single mistake being catastrophic. Part B lists the qualifiers that make a task a good fit. Part C is the one people skip: name the non-AI alternative first - a rule, a filter, a template - and then ask honestly whether it is genuinely not enough. The whole screen only works if you are willing to lose: 'do not try to lie about your problem statement... if you are honest, then you kind of come to the conclusion that AI should not be used' in some cases.

Once a task clears the screen, one call remains: does AI do the task end to end with a human reviewing only the result (automate), or does it assist while the human keeps deciding at every step (augment)? Two questions settle it - is the task unpleasant, and do people agree on what a correct outcome looks like? Where both hold, automate. Where the work is enjoyable, or where reasonable people would disagree about the right answer, augment. Dileep is explicit that this does not need to be exact: 'you don't have to get it right completely. At least directionally.'

Part E forces two numbers into existence before any building starts. First, define failure concretely: what a wrong output looks like, what a missed item looks like, and which of the two is worse in this particular workflow - because that determines whether you tune for precision or recall. Second, time both sides: how long the task takes by hand today, and how long it takes a person to check one AI-generated output. The gap between those two is the entire ROI case. Dileep's framing of the payoff is deliberately modest: 'every time the task is done, every time I'm reclaiming 10 minutes, and that is a great victory.'

The last part of the fitness screen turns your own reasoning against itself. Paste the W3 root cause and the six disqualifier criteria into a capable thinking model and instruct it to argue, paragraph by paragraph, that AI is a bad fit for this problem - with the explicit instruction 'do not soften it'. Then write a one-line rebuttal to each objection. Anything you cannot rebut in one line is a real hole. Dileep names the move by analogy: you do not hammer a nail in and walk away, you shake it to see whether it holds. He also concedes the full A-to-F sequence is hard and tells learners it is fine to get only through Parts A and B inside the time box.

Version 0 is the manual way the task is done right now, written down properly, and it is the yardstick everything else is measured against. It is not a thought experiment: it is scheduled as literal day-one and day-two work in the coming week, before AI is allowed anywhere near the problem. Doing it by hand has a second payoff - it produces three or four real worked examples of the task, and those examples become the test set and the specification later. If the AI version does not beat Version 0 on time, quality or insight, there is nothing to build.

W5 rewrites the root cause from W3 as a solution-agnostic 'how might we' statement. The discipline is in what it must not contain: no tool, no technology, no named fix. Three quality tests are given. It should allow different types of solutions rather than pointing at one. It should hint at where to start while naming no solution, tool or technology. And it should make sense to someone outside the team - if it needs insider context to parse, it is written wrong. The worked example follows the calendar chain: a root cause of being expected at every meeting becomes 'how might we set up a system so that fewer meetings require my presence?'

W6 is deliberately divergent: sketch eight different forms the answer could take, Post-it style, committing to none. The examples given are all small - 'a sheet with a row appearing in a spreadsheet, a chat message, draft email, weekly one-pager, a checklist' - because the point is to break the reflex that every solution is an app. 'You are just saying my solution to the problem looks like this.' Only after the spread exists do you choose one, on three criteria: ease of build, one-week feasibility, and whether the data is actually available. Shapes stay droppable: a WhatsApp-automation idea gets traded for email once the integration turns out to be hard.

W7 is a feasibility gate with an honest clock. The nominal window is one week; the real budget is four to six focused hours, and everything else must be scoped to fit. To help, Dileep offers a menu of solution archetypes to map the idea onto - read-many, fill-a-table, sort-and-route, notes-to-actions, a recurring report, question-and-answer over documents, comparing lists, a checklist, form-and-record, a morning digest. Then the warning signs that a problem is oversized: needing more than one new system connection; being unable to name a test that would prove it works; being unable to gather ten to twenty examples by day two; being an open-ended assistant rather than a fixed repeatable job; or high stakes where mistakes would be hard to spot.

W8 storyboards the chosen shape as five beats, and they are the same five whether the build ends up an automation, an app, a prompt or a skill: 'what is the trigger, what is the input, what is the transformation, the output, and the human moment, who checks, approves, or gets flagged.' W9 then writes the brief - problem, goal, users, inputs, outputs, data and access, success criteria, why not a rule, out of scope - plus the human check: what must be produced, when it passes, what a human approves. Dileep equates it to a PRD and treats a fully completed W9 as the evidence of 'complete problem understanding'. The remaining week layers on top: interview the problem owner if it is not your own problem, collect examples, turn the brief into a spec, add AI, test with the real user, submit.