How to run an applied AI workshop that validates commercial demand

Generating software during a workshop is no longer impressive on its own. A cohort of university founders or a business team can prompt a working web app into existence in under an hour.

Yet a few weeks after the session, most of those prototypes sit untouched.

The problem is rarely technical. It happens because most AI workshops focus on tool fluency rather than commercial validation. Participants learn how to prompt, but they never test whether the problem is urgent enough for anyone to pay to solve it.

A useful applied AI workshop reverses that order. Structured Design Thinking comes first, and AI tools are used to test assumptions, not to replace customer discovery.

The novelty trap in conventional AI workshops

Many AI workshops follow a familiar pattern: an overview of new models, a demonstration of prompts, then open time to generate landing pages or chatbots.

That creates energy in the room, but it introduces three risks:

• Premature solutions: teams design screens before defining the customer job or the root pain.
• Confirmation bias: building feels productive, so teams assume demand already exists.
• Disposable prototypes: without clear constraints, the output cannot become a real product roadmap.

Practical capability building is not about which words to type into a prompt. It is about using AI to stress test business assumptions before committing time and budget to a build.

Step 1: Frame the problem before opening any tools

Every hands-on session should start with the tools closed. Before anyone opens a builder or chat window, the idea goes through structured problem framing.

We anchor sessions in the Value Proposition Canvas and root-cause discovery:

• Which specific customer segment experiences this problem?
• What do they do today instead, even if it is a spreadsheet or a manual workaround?
• What does it cost them to leave the problem unsolved?

If a team cannot describe the buyer's pain in two clear sentences, a prototype only speeds up building something nobody needs.

Step 2: Use AI to challenge assumptions, not confirm them

Once the problem statement is clear, AI becomes a critical sounding board rather than a creative assistant.

Instead of asking a model to write marketing copy for the idea, teams use targeted prompts to simulate tough stakeholders:

• A sceptical buyer: ask the model to act as a cautious budget holder questioning why they would pay.
• Operational and regulatory blockers: ask the model to list failure points around data, compliance and integration.
• Better interview scripts: generate open discovery questions that do not lead the customer to an answer.

Used this way, AI stops being an echo chamber. Teams find weak points in their value proposition within minutes instead of months.

Step 3: Prototype around one core hypothesis

When teams move into building, the goal is not a complete product. The goal is an interactive artefact that tests one critical assumption.

Whatever tool is used, strong sessions follow three rules:

• One core interaction: show only the moment where value is created, such as the step that saves time or surfaces an insight.
• Realistic sample data: replace placeholder text with believable customer inputs.
• Live peer testing: other teams try the prototype without instructions, and the builders watch where people get stuck.

Participants leave with a tested, clickable artefact and clear next questions to take back to real customers, rather than a slide of tips.

Adapting the format for cohorts and business teams

Programme leads need practical outcomes, not theory. The same structure adapts to different groups:

• Academic and incubator cohorts: customer problem discovery, quick evidence gathering and first prototype tests.
• Business and innovation teams: commercial feasibility, decision-making and bringing AI into existing product discovery.

If you lead a cohort or a team and want a hands-on, outcome-focused session, explore the workshop tracks at Malvorah Advance.