Three cohorts graduated. Fourth corporate group is in training. Enrollment for the fifth group is open.
← Free materials
Workshop resource Open access

Imaguru AI Product Sprint - Prompt Pack

Work through the stages in order - each one builds on the last. Copy a prompt whole, paste it into your AI tool, fill in the [BRACKETS], and go. Beginner lane: use your browser builder (Bolt, Lovable, or Replit Agent) for research prompts too - no separate tool needed. Advanced lane: same prompts work in Claude Code, Codex, Cursor, or your coding agent of choice. The prompts are domain-neutral: your core loop can be software, research, marketing, support, finance, compliance, or another operational workflow.

Ground rules

  1. Plan first, build second - with two approvals. First confirm who the work is for, the problem, desired outcome, and what is evidence versus assumption. Then confirm the exact plan, owner or agent(s), tools and access, budget/time, acceptance checks, and stop conditions. If any material input changes, approve again.
  2. Be specific, not polite. Say exactly what's wrong or what you want - which screen, which behavior. Where a prompt has [BRACKETS], that's where your specifics go.
  3. Keep evidence and assumptions separate. Anything an AI tells you about "what users think" is an assumption until a real person confirms it. Label AI-simulated people as unverified, always - they inform your questions, they never replace a real answer.
  4. Never paste anything confidential. No customer records, internal strategy docs, credentials, or personal data into these tools. Never put an API key in a prompt.
Stage 1

Evidence-based discovery

What you'll get: an evidence log - sourced facts about the problem, separated from inference, plus the three riskiest unanswered questions.

I want to investigate this problem or idea: [DESCRIBE YOUR PROBLEM OR IDEA IN 2-3 SENTENCES]. Research this as a skeptical product analyst. Search for real sources - existing alternatives, manual workarounds people use today, complaints, forum posts, reviews - anything showing this problem is real and how people currently deal with it. For everything you find, cite the source and date, and label it clearly as primary evidence (direct quote or observation), secondary evidence (reported by someone else), or inference (your own reasoning, not sourced). Finish with: a one-sentence problem statement (target user, triggering situation, suspected problem), any evidence the problem might NOT be important, and the three riskiest unanswered questions.
Stage 2

Assumption ranking and validation kit

What you'll get: the single highest-impact, weakest-evidence assumption, plus a validation kit you can run with real people after tonight.

Here is my evidence log: [PASTE OR SUMMARIZE YOUR EVIDENCE LOG FROM STAGE 1]. List the assumptions I'm making that aren't yet backed by evidence. Rank them by impact (how much the idea depends on this being true) and by how weak the evidence is. Tell me the single highest-impact, weakest-evidence assumption - that's the one we test next.
My riskiest assumption is: [PASTE IT]. My target user is: [DESCRIBE]. Write me a validation kit I can actually run after tonight: 1. Five interview questions about the person's PAST behavior, existing workarounds, frequency, consequences, and spending on this problem - not whether they like my idea. 2. One short outreach message I could send to a real person who matches this profile, asking for 15 minutes of their time. 3. One decision signal: what answer or pattern would make me continue, change direction, or stop. Do not invent fake interview answers or pretend to be the interviewee - I will use this kit with real people after the sprint.

Optional, rehearsal only - never evidence

Role-play as 3 people who might match my target profile and answer my 5 interview questions, so I can spot weak or leading questions before I ask a real person. Give them distinct, relevant situations without relying on stereotypes. Label every answer "UNVERIFIED - SYNTHETIC." Then list where they agree, where they disagree, which questions felt leading, and which claims still require real evidence. This is rehearsal only - never market proof and never a replacement for real interviews.
Stage 3

PRD-lite product brief

What you'll get: a one-page product brief, ready to hand to your builder tool.

Here is my evidence log: [PASTE KEY POINTS FROM STAGE 1]. Here is my riskiest assumption and validation kit: [PASTE FROM STAGE 2]. Turn this into a one-page product brief with exactly these fields: Target user and affected stakeholders; Problem (observed behavior/friction, not a feature); Desired outcome and success signal; Evidence (sources, quotes, workarounds); Assumptions and missing evidence (including synthetic-persona output); Core promise (what improves and why this approach may be different); One journey (trigger -> input -> core action -> useful result -> next action); Executor requirements (capabilities, tools, permissions, communication needs, and boundaries); Execution pattern (one owner, sequential workflow, parallel specialists, supervisor, or human-controlled - and why); Acceptance tests (3-5 observable checks the prototype must pass); Mock data (static examples or simulated responses needed for the demo); Guardrails and approval points; Out of scope (auth, payments, complex roles, heavy infrastructure, secondary features); Next experiment (who tests it, what they do, and what signal changes the decision). Keep the scope small enough to build in under 60 minutes. Save this as a file (or as PRODUCT_BRIEF.md if you're in a local coding agent).
Stage 4

Build one core value loop

What you'll get: one working, end-to-end interaction - not a full product.

Here is my product brief: [PASTE OR ATTACH YOUR BRIEF FROM STAGE 3]. Build only the one core value loop described in "One journey" - nothing else. Use realistic mock data and fixed responses for anything that isn't the core interaction. No billing, no custom authentication, no complex infrastructure. Before building, use two approval gates. Gate 1 - context: restate the target user or stakeholder, problem, desired outcome, evidence, assumptions, and important missing information. Wait for my confirmation. Gate 2 - execution: choose the smallest suitable pattern - one owner, sequential workflow, parallel specialists, supervisor, or human-controlled. For each step state the owner or agent, required capabilities, tools and permissions, input, output, dependency, and acceptance check. Include budget/time limits, stop conditions, and a fallback. Do not invent agent capabilities or use unavailable tools. Wait for my approval. Then build only the approved loop, incrementally. After each small piece, tell me what to check before moving on. Save a checkpoint before any large change. If the context, plan, owner, tools, access, or budget changes materially, stop and ask me to approve again.

Fix things in plain language as you go:

The [SPECIFIC THING] doesn't work / looks wrong: [DESCRIBE WHAT'S WRONG]. Fix just this, don't change anything else.

Check against your acceptance tests before moving on:

Let's check this against my acceptance tests: [PASTE ACCEPTANCE TESTS FROM YOUR BRIEF]. Go through each one honestly and tell me whether it passes. Fix what doesn't, one at a time.
Stage 5

Test, publish, and prepare the demo

What you'll get: a published, shareable prototype tested outside the editor, plus a 45-second demo.

Help me publish this prototype and get a shareable URL. Then run an honest end-to-end acceptance check against my product brief. Test from a fresh private/incognito session, complete the full core value loop with realistic non-sensitive input, verify every handoff and output, try one failure or recovery path, and check the main screen at mobile width. Confirm that no private data, credentials, hidden admin controls, or unintended public access are exposed. For each acceptance test, report PASS, FAIL, or NOT VERIFIED and point to the observable evidence (URL, screenshot, log, or output). Do not pretend an untested step passed. Do not recommend sharing the prototype while a critical test fails. Finish with an execution receipt: outcome, quality, time and cost if known, rework, failures, human overrides, what the user accepted, and the single most important next change.

Before you share the link, confirm nothing private is exposed - assume a published prototype is public unless you've explicitly restricted and tested access.

Help me write a 45-second spoken demo: problem -> user action -> useful result -> next experiment. Keep it conversational - I need to say this out loud, not read it. Only claim what the end-to-end test actually verified; label assumptions or synthetic findings as unverified.

Speakers

Andrew Tomin Senior Product Manager, Agentic Ops, AI Trainer
AISandboxlab.com
Vitalijs Visnevskis AI Product & Technology Expert
Co-Founder of axwise.de

Want the full 5-session version?

This pack is one sprint. AI Sandbox is 5 sessions where you build your own AI tool end to end, with a mentor - from idea to a deployed prototype.

Join a group More free materials
Ask a question