The journey

The bootcamp follows one idea from problem → evidence → prototype → decision.

Day 1 — Discover

You explore possible challenges and select one idea with your team. You will:

• hunt for relevant frictions and opportunities
• prioritise your ideas
• choose one challenge
• map how things work today
• identify pain points
• identify what you still don't know

By the end of Day 1, your team should have a selected idea, a first process map and a list of important assumptions and questions.

Fieldwork — 10–20 September

Between Day 1 and Day 2, you leave the workshop room and check your assumptions against reality. Your team will:

• speak with 2–3 real users or stakeholders
• verify how the process actually works
• collect useful examples and documents
• sharpen the pain points
• challenge assumptions you made on Day 1

The goal is not to prove your idea was right. The goal is to learn what is actually true before you start building.

Day 2 — Build I

Now you move from problem to solution. You'll learn the foundations of AI, software and AI-assisted development, then turn your team's fieldwork into a clearer solution concept and build brief. After that, the first version of your prototype begins.

Day 3 — Build II

You continue building, testing and improving. You'll also learn how to work more effectively with Claude Code, how to think about safety, and how to test whether your application actually works. By the end of Day 3, the target is a demo-ready, tested prototype.

Day 4 — Decide & Pitch

Finally, you bring everything together. You will:

• refine the value case using what you learned during fieldwork and building
• finish and stabilise the prototype
• build and rehearse your pitch
• demonstrate the solution to the jury

Each team gets 7 minutes for the pitch, including the live demo, followed by 5 minutes of jury questions.

Two challenge types

On Day 1, you will explore opportunities across two broad directions.

A. Improve Existing Work

Something already happens today, but it takes too much time, effort or coordination. Examples:

• repetitive manual work
• reporting and documentation burden
• duplicate data entry
• information spread across different places
• slow handovers
• recurring support requests
• unnecessary waiting or rework

The question is: how can we do what we already do significantly better?

B. Create New Value

There is a useful capability, service, insight or tool that does not meaningfully exist today. Examples:

• proactively warning someone before a problem occurs
• helping people make better decisions using existing information
• giving employees easier access to specialist knowledge
• providing personalised guidance
• offering a service that today only exists informally or ad hoc

The question is: what useful thing could we do that we cannot meaningfully do today?

Neither direction is better. Pick the one that fits the problem.

Teams and the finish line

You will work in seven mixed IT + business teams. The goal is not to create production-ready software in four days. The goal is to create a credible proof of concept that:

• addresses a meaningful challenge
• reflects real user evidence
• demonstrates how the solution could work
• gives KPNWE enough information to decide whether the idea deserves a next step

Ground rules

• Teamwork beats hierarchy. Job title doesn't decide who's right.
• Start with the problem. Don't fall in love with a technology before you understand what needs solving.
• Make uncertainty visible. "We don't know yet" is a useful answer.
• Test instead of assuming.
• Get out of your comfort zone.
• Protect the time. No normal daily work during the sessions.
• You are not expected to know how to code before you arrive.

What do we mean by innovation?

Innovation is not simply inventing something new, and it does not have to involve new technology. For this bootcamp, we use a practical definition: innovation is creating a new or improved product, process, service or way of working that creates meaningful value.

That value might be for a customer. It might be for KPNWE. Or it might simply make somebody's work easier, faster, safer or better.

This distinction matters because many useful innovations are not inventions. GPS, smartphones, digital maps and online payments all existed before companies combined them in new ways to create services such as ride-hailing. The underlying technologies were not necessarily new. The way they were combined to create value was.

During this bootcamp, we are much more interested in creating value than in inventing new technology.

Innovation is really about uncertainty

An idea can sound excellent and still fail. Before investing heavily in an idea, there are three fundamental questions worth asking.

1. Desirability — do people want or need it?

• Who experiences the problem?
• How important is it to them?
• How are they dealing with it today?
• How well does the current solution work?
• Would changing it actually make a meaningful difference?

A technically impressive solution has little value if it solves a problem nobody really cares about.

2. Feasibility — can we make it work?

• Can the solution actually be built?
• Do we have access to the required technology?
• Is the necessary data available?
• Can the right systems be connected?
• Can it work reliably enough?
• What are the biggest technical uncertainties?

An attractive idea is still only an idea if there is no realistic way to make it work.

3. Viability — is it worth doing?

• What value would solving the problem create?
• How much time, effort, cost, risk or frustration could it remove?
• What new capability could become possible?
• What would it take to build, operate and maintain?
• Is the expected value large enough to justify continuing?

Something can be desirable and technically possible but still not be worth the investment.

What happens when one lens is missing?

Some famous failures make the point clearly.

Juicero — desirability problem

Juicero raised more than $100 million to develop a sophisticated internet-connected juicer. Customers bought special juice pouches, placed them into the machine, and the machine squeezed out the juice. Then people discovered something awkward: the same pouches could simply be squeezed by hand. The engineering worked. But the expensive machine did not solve an important enough problem.

Lesson: building something impressive is not the same as creating something people need.

Zano — feasibility problem

Zano was a highly successful crowdfunding project for a tiny autonomous drone. Thousands of people ordered one and millions were raised. The demand was clearly there. But the company struggled to make the technology work reliably at the promised quality and scale.

Lesson: people wanting something does not mean you can actually deliver it.

MoviePass — viability problem

MoviePass offered subscribers access to cinema tickets for a very low monthly fee. Customers loved it. The service worked. Unfortunately, MoviePass often had to pay cinemas close to the normal ticket price each time a customer watched a film. Heavy users could therefore cost the company far more than they paid in subscription fees. The more people used the service, the worse the economics became.

Lesson: a product can be desirable and feasible while still having an unsustainable value equation.

The real lesson

The lesson is not "be afraid of failure." The lesson is: find out what you don't know as early and cheaply as possible. That is what innovation methods are for.

Instead of spending months building something and discovering the problem afterwards, you progressively reduce uncertainty. You talk to users. You inspect the current process. You build prototypes. You test assumptions. You gather evidence. Then you decide whether the idea deserves more investment.

How the three lenses appear during this bootcamp

You will not answer all three questions perfectly on Day 1. The bootcamp progressively replaces assumptions with evidence.

• Day 1 — Discover. You investigate the desirability and early viability of the idea. Is there a meaningful problem? Who experiences it? What appears valuable? What are we still assuming?
• Fieldwork. You test those assumptions with real users and real process information.
• Days 2–3 — Build. You explore feasibility. Can the concept actually work? What becomes easy? What becomes difficult? What did we misunderstand before we started building?
• Day 4 — Decide. You bring the three lenses back together: is the problem meaningful, does the prototype demonstrate a credible solution, what value could it create, what would still be needed, and is the idea worth taking forward?

Think of the bootcamp not as proving your first idea was correct. Think of it as learning quickly whether the idea deserves to survive.

Quick self-check

Before moving on, make sure you can explain:

• the difference between an invention and an innovation
• Desirability, Feasibility and Viability
• why an idea can fail even when one or two of those lenses look strong
• why the bootcamp starts with the problem instead of immediately building a solution
• the difference between Improve Existing Work and Create New Value

You do not need to learn programming before the bootcamp. Claude Code will write much of the actual code. But you will make much better decisions if you understand the basic pieces that make software work.

This is the section most worth reading carefully before Day 2. You may already use ChatGPT, Microsoft Copilot, Claude or another AI tool. During the bootcamp, we will go one step further: we will use AI not only to generate text, but to analyse information, challenge ideas, structure findings, help define solutions, create software, investigate errors, and test what we have built.

AI is bigger than ChatGPT

Artificial intelligence is a broad field. AI systems already do things such as make recommendations, recognise objects or speech, detect patterns, make predictions, optimise routes or schedules, and generate text, images, audio, video and code. The part of AI that has received enormous attention recently is generative AI: it creates new outputs based on instructions and context, such as text, summaries, classifications, structured information, images, analysis, plans or computer code. The systems behind tools such as ChatGPT and Claude are called large language models, or LLMs.

How does an LLM generate an answer?

At its core, an LLM works by predicting tokens. A token is a small piece of text, sometimes a whole word, sometimes part of one. Imagine this sentence: "The chef sliced the onion with a sharp ___". A likely next word is "knife." Now change the sentence: "The surgeon made the incision with a sharp ___". A likely next word becomes "scalpel." The model takes the context into account and predicts what should come next, then the next piece, then the next. At very large scale, this apparently simple mechanism produces surprisingly sophisticated behaviour: modern LLMs can explain concepts, summarise documents, translate languages, analyse information, identify patterns, generate ideas, plan work, write computer code and reason through many types of problems.

The model and the AI tool are not the same thing

The LLM is the language model itself. The AI product you use may give that model access to additional capabilities, such as searching the web, retrieving company documents, reading uploaded files, executing code, inspecting a software project, calling external tools or APIs, or interacting with other systems. So an AI assistant is increasingly more than a chatbot answering from its training alone: it can be given tools and information that let it perform work. That becomes especially important when we start using Claude Code.

The context window: the AI's working material

An LLM does not automatically remember everything forever. It works with a context window: the information currently available to it while producing an answer. Depending on the tool, this might include your current instruction, earlier messages, documents you provided, project files, tool results, or other information supplied by the application. This leads to one of the most useful AI habits: give the AI the information it needs instead of expecting it to know your situation.

Compare "Improve our onboarding process" (the AI has almost no real information and will probably produce generic suggestions) with "Here is our current onboarding process, three complaints we hear repeatedly, and two interview summaries. Identify the steps causing the most avoidable effort. For every issue, show the evidence you used." Now the model has something real to reason from. Better context often matters more than clever wording.

AI output is not automatically true

LLMs are very good at producing plausible responses. But plausible and correct are not the same thing. An AI can misunderstand your request, make an incorrect assumption, omit something important, invent a detail, state an incorrect fact confidently, or write code that looks correct but contains a bug. When an AI presents unsupported or invented information as if it were true, this is often called a hallucination. This does not mean AI is useless, it means you need the right working relationship with it. AI output is something to inspect, not something to automatically accept. The higher the consequence, the more important verification becomes.

Prompting: you don't need a magic formula

People sometimes make prompting sound more complicated than it needs to be. For this bootcamp, remember five useful ingredients.

1. Task — what exactly do you want the AI to do?

Analyse these interview notes and identify recurring pain points.

2. Context — what information does it need to understand the situation?

These interviews are with service-desk employees using the current incident-routing process.

3. Criteria — what should a good answer take into account?

Separate observed problems from assumptions. Prioritise issues mentioned by multiple interviewees.

4. Format — how should the answer be returned?

Return a table with pain point, evidence, affected user and frequency.

5. Check — tell the AI what to do when it is uncertain

If there is not enough evidence to support a conclusion, say so instead of guessing.

Weak vs. stronger prompts

Weak

Summarize this.

Stronger

Summarize this report for a department head who has no background on the project. Use five bullet points. Focus on the main operational impact and any decisions they need to make.

Weak

Make this better.

Stronger

Rewrite this email to sound more direct and confident. Keep it under 100 words and preserve the three factual points.

Weak

Improve this process.

Stronger

Here is the current process and three user interviews. Identify the three steps that create the most avoidable effort. For each one, explain the evidence, likely root cause and what we would still need to verify.

The difference is not "better prompt engineering tricks." The stronger prompts simply make the intended task clearer and provide better context.

AI works best as an iterative partner

Do not expect the perfect result from one enormous prompt. A more useful pattern is: Ask → Review → Refine. For example: "Analyse these interview notes and identify the main problems," then "You combined two issues that I think are different. Separate them," then "Now rank them by user impact, but show the evidence for each ranking," then "Which important questions can we still not answer from these interviews?" You are steering the work. That is an important skill, and it becomes even more important when AI starts writing software.

From AI assistant to AI developer

In a normal AI chat, you might ask "how would I build an application that tracks meeting actions?" The AI could explain it or generate some example code. An AI coding assistant goes further. During the bootcamp, you will work with Claude Code inside VS Code. Claude Code can work directly with a software project. It can:

• inspect the existing files
• understand how the application is structured
• propose a development plan
• create new files and change existing code
• add frontend and backend functionality
• change the database
• call AI models
• run technical commands and investigate errors
• run tests and modify the application based on your feedback

Instead of asking "what code should I write?" you can ask something like "add the ability for a user to mark an action item as completed. First inspect the existing application and explain what needs to change before editing anything." The AI can inspect the project and perform the work itself. That changes who can participate in building software.

So what is "vibe coding"?

Vibe coding is an informal term for building software by describing what you want in natural language and using AI to create much of the actual code. A simple loop looks like this: Describe → Build → Run → Review → Refine. For example: "Add a page showing all previous meetings." Claude changes the application. You run it. Maybe the page works, but the meetings are sorted incorrectly. You tell Claude "this works, but show the newest meeting first." Claude changes it again. You run it again. You repeat.

But we're not going to build by vibes alone

There is a big difference between "build me an amazing AI application" and a disciplined AI-assisted development process. During the bootcamp, we will work more like this: Understand → Describe → Plan → Build a small piece → Run → Test → Refine. You will also learn to:

• give Claude persistent project instructions
• let it inspect before changing things
• break bigger changes into smaller steps
• keep useful project context
• give it evidence when something breaks
• test important workflows
• save checkpoints so bad changes can be reversed

AI dramatically lowers the amount of technical syntax you need to know. But that does not mean your team can switch off its judgement.

What AI changes — and what it doesn't

AI can write the code. Your team still needs to decide:

• what problem is worth solving
• who the user is
• what the software should do, and what the important workflow is
• what "done" means
• whether the output is correct and safe
• whether the prototype actually works
• whether the solution creates enough value

That is why this bootcamp does not begin with Claude Code. It begins with the problem. A perfectly coded solution to the wrong problem is still the wrong solution.

Proof of concept vs. production software

During the bootcamp, you will build a proof of concept, or PoC. Its job is to demonstrate that the core idea could work. It does not need everything a production application would need.

• A prototype might use: simplified workflows, sample data, local storage, limited users, mocked integrations, basic security, a narrow "happy path."
• A production version might additionally require: enterprise authentication, real integrations, monitoring, stronger security, privacy controls, scalable infrastructure, support and maintenance, governance, broader testing.

Do not confuse "we demonstrated that the idea can work" with "this application is ready to run across the company." Both are valuable milestones. They are simply different milestones.

Hands-on: improve one real prompt

Reading about prompting isn't the same as doing it. Use an AI tool you are already allowed to use. For this exercise, use non-sensitive information: do not paste personal data, confidential information or restricted company information into an AI tool unless that use is explicitly approved.

• Step 1 — Pick a real task. Choose one small task from your work: summarising a document, improving an email, analysing a list, organising meeting notes, comparing several options, or generating questions for a meeting.
• Step 2 — Use your normal prompt. Write the prompt the way you normally would. Look at the result.
• Step 3 — Improve the prompt. Rewrite it using Task → Context → Criteria → Format → Check. Run it again.
• Step 4 — Compare. Is the second answer more useful and specific? Did the AI make fewer assumptions? Is the format easier to use?
• Step 5 — Iterate. Don't start a new conversation. Give the AI one specific piece of feedback about its answer, for example "this is too generic, use only evidence contained in the information I provided" or "the tone is right, but it is too long, reduce it to five bullets."
• Step 6 — Expose uncertainty. Finally, ask "what assumptions did you make that I should verify before using this answer?"

That final question is worth remembering. Good AI use is not only getting the model to produce more. It is also getting it to show you where you should remain sceptical.

Before moving on, remember five things

• AI needs context. Give it the information required to understand your situation.
• Specific instructions usually produce more useful output. Be clear about the task, relevant criteria and desired result.
• Iterate instead of searching for the perfect first prompt. Ask, inspect, correct and improve.
• Fluent does not mean correct. Important outputs need verification.
• AI does not remove your responsibility. The AI can build remarkably quickly. Your team still owns the problem, the decisions and the definition of "works."

This is the one part of the pre-reading that isn't really reading. On Day 1, your team will brainstorm possible challenges. You do not need to arrive with the winning idea, but it helps enormously if everybody arrives already noticing the friction and opportunities around them. Think about your own work, your team, and the people you support. Write rough answers below: specific observations are much more useful than polished ideas.

Notes save automatically on this device and are shared with the facilitation team to help prepare Day 1.

Worked example

Here is the level of detail to aim for:

Improve Existing Work: Onboarding a new supplier takes about three weeks because procurement, finance, legal and IT each request information separately. Suppliers sometimes receive several emails asking for the same documents. It happens around 15–20 times a year. Across the teams, we probably spend 6–8 hours of coordination per supplier. When it goes wrong, onboarding is delayed and different teams may end up working with different versions of the same information.

Notice what makes this useful: we know what happens, we know who is involved, we have a rough frequency, we have a rough effort estimate, and we know what goes wrong. It is not a solution yet. That is exactly what we want.

Don't solve it yet

You may naturally start thinking "we could build…" That's fine, write the idea down if you don't want to lose it. But don't become attached to it. On Day 1, we want to begin with: what is happening, who experiences it, why does it matter, and what don't we know yet. The solution comes afterwards.

Bonus — if you have five extra minutes

Take one of the observations you wrote above and give it to your AI tool:

Here is a recurring friction from my work. Do not propose solutions yet. Ask me five questions that would help determine whether this problem is significant enough to work on.

Answer the questions. Notice what information the AI asks you for. You will do a much more structured version of this during the bootcamp.

Your notes will be used as input for Day 1. You don't need a polished challenge, a clever framing or a solution. Bring honest, specific observations from your real work.