The arc

Four days, built around one throughline: three lenses, one per phase:

• Day 1: Discover. Is this desirable? Do people actually want or need it? Your team picks a problem and a first idea.
• Fieldwork (10–20 Sept, on your own time). You test that idea against reality: 2–3 short interviews with real colleagues, plus mapping how the process actually works today.
• Days 2–3: Build. Is this feasible? Can we actually build it? You build a working prototype with an AI coding assistant, Claude Code.
• Day 4: Decide & Pitch. Is this viable? Does it pay off? You pitch a live demo plus a business case to a jury of KPNWE leaders.

Each phase depends on the one before it: you can't skip to building without first agreeing on a real problem, and you can't pitch viability without real data from fieldwork and the prototype. That's why the order matters more than the pace.

Two lanes

On Day 1 afternoon, your team picks one of two directions for your idea:

• Improve Existing Work: make something that already happens today faster, less error-prone, or less painful. Think: manual reporting, duplicate data entry, slow handovers between IT and business.
• Create New Value: build something that doesn't meaningfully exist today, a missing tool, a capability nobody currently owns, something people work around or request ad hoc.

Neither lane is "better", pick whichever your problem actually fits.

Teams & the finish line

Seven teams of 2–3, deliberately mixed IT and business, one shared laptop per team with the AI tools pre-installed. On Day 4 afternoon, each team gets 7 minutes to pitch, including a live demo of what you built, followed by 5 minutes of jury questions. Exact scoring criteria will be shared closer to the day, but expect the jury to weigh how well you understood the problem, how well the prototype works, and how strong the pitch is.

Ground rules

• Teamwork beats hierarchy: job title doesn't decide who's right this week.
• Day 1 itself is screen-free (paper and conversation), even though you'll have your laptop with you (see Logistics above).
• Block your calendar properly. No checking email between sessions.
• Get comfortable being uncomfortable, especially if you've never written a line of code. That's expected, not a gap you need to fix beforehand.

Why bother

The pace of change in most industries has sped up enough that "we've always done it this way" is no longer a safe default. Innovation isn't a department or a buzzword. It's deliberately creating new value, for a customer, for the business, or for the people doing the work. That last one, value for employees and making internal work less painful, is what most of this bootcamp is actually about.

Where it goes wrong

Three well-known cautionary tales, each failing a different lens:

• Juicero raised over $100M to build an internet-connected juicer that squeezed pre-packaged juice pouches, pouches you could squeeze by hand just as effectively, for free. Perfectly engineered, zero desirability.
• Google Glass shipped genuinely impressive hardware years before anyone had a clear answer to "what do I actually use this for, and why would I wear a camera on my face in public?" Feasible and built, but desirability and viability were never solved.
• Quibi, a $1.75B short-form streaming service, launched with A-list content and shut down within six months. Desirable in surveys, entirely feasible to build, but the viability math never worked.

Notice the pattern: each failure is one or two lenses out of three. That's exactly why this week checks all three, in order, before your team commits real building time.

Putting the three lenses into practice

Here's what this looks like applied to a boring, realistic "Improve Existing Work" idea, not a startup pitch: just an ordinary internal friction point.

The situation: every month, a finance coordinator manually compiles a departmental spend report by pulling numbers from four different systems, cross-checking them in a spreadsheet, and emailing a formatted PDF to five department heads. It takes roughly a day and a half each month, and errors slip through when source data changes late.

• Desirability: do people actually want this fixed? Does the coordinator find this painful? Do department heads value the report, or skim and ignore it? You don't know yet: it's a hypothesis to test in fieldwork, not an assumption to build on.
• Feasibility: can this actually be built, by this team, in three build days? Pulling data from four systems automatically might need access that doesn't exist yet. A more feasible first slice: automate the cross-checking and formatting, keep data-pulling manual for now.
• Viability: does fixing this pay off? Roughly: 1.5 days × 12 months of one coordinator's time, plus the cost of errors reaching leadership, weighed against the effort to build and maintain the fix. Even a rough estimate is enough to decide if it's worth a team's four days.

Notice that none of these questions get a real number today. Day 1 produces hypotheses ("we believe…"); fieldwork and the prototype produce the real numbers Day 4 needs.

Quick self-check

Before moving on, you should be able to answer these without looking back: What are the three lenses, and which phase of the week does each map to? What's the difference between the two lanes? Why does Day 1 produce hypotheses instead of firm numbers?

You don't need to know how to code for this week: the AI does the typing. But a little shared vocabulary will make Day 2 land faster, especially if "frontend" and "backend" aren't already familiar terms.

This is the part most worth your full attention, whatever your starting point: most of you already use tools like ChatGPT, Claude, or Copilot day to day, but Day 2 goes a layer deeper than "type a question, get an answer."

What an LLM actually is

A large language model (the "brain" behind tools like Claude or ChatGPT) is trained on enormous amounts of text and learns to predict, one small piece at a time, what text should plausibly come next given what came before. Those small pieces are called tokens: sometimes a whole word, sometimes a fragment of one. There's no database of facts it looks up and no true understanding the way a person has one. It's closer to an extremely well-read autocomplete that's gotten good enough to hold a conversation, write code, and reason through problems.

A concrete example: if a model has seen thousands of sentences like "the chef sliced the onion with a sharp ___" it learns "knife" is a likely next word in that context. Change the context to "the surgeon made a careful cut with a sharp ___" and it predicts "scalpel" instead: same last word before the blank, completely different answer, because it reads the whole sentence's meaning.

• It has a "context window." Everything it can see in a conversation has to fit inside a limited working memory. Long, messy conversations without a recap can cause it to lose the thread.
• It can hallucinate. It can state something confidently and incorrectly, especially with obscure facts or precise numbers. Example: ask it to summarize a long policy document, and it may state a deadline that sounds exactly right but was never actually in the document. The fix is verification, not distrust: check anything that matters, the way you'd double-check a number a colleague gave you from memory.

Prompting, briefly: good vs. bad, side by side

The quality of what you get back is mostly a function of the quality of what you put in:

Three habits behind all three "stronger" versions: be specific about audience and format, give it real context instead of describing it from memory, and iterate on what it gives you back rather than restarting from scratch.

See it in action

Here's a real side-by-side, not just a description. Imagine this short excerpt from an IT helpdesk report:

Q2 IT Support Ticket Report (excerpt): This quarter, the IT helpdesk received 1,240 tickets, up 18% from Q1. The largest category was password resets (31% of tickets), followed by software installation requests (22%) and VPN connectivity issues (19%). Average resolution time was 6.4 hours, up from 5.1 hours in Q1, largely due to two weeks of reduced staffing in May. Three recurring issues were flagged by the team: the automated password reset tool fails for accounts created before 2023, several business units are requesting software outside the approved list, and VPN drops correlate with a network switch scheduled for replacement in Q3.

• Weak prompt ("Summarize this.") produces: "This report covers IT helpdesk tickets for Q2. There were 1,240 tickets, an 18% increase from Q1. The main categories were password resets, software installs, and VPN issues. Resolution time increased to 6.4 hours. The report also mentions some recurring issues with the password tool, software requests, and VPN drops." Accurate, but flat: it just restates the report in fewer words.
• Strong prompt ("Summarize this for a department head with no background on the project, in 5 bullet points, focused on budget impact and decisions needed from them.") produces: ticket volume is up 18%, but driven by routine categories, not a systemic problem. Resolution time slipped because of a temporary staffing gap in May, not an ongoing issue. The password tool needs a small budget line to fix pre-2023 accounts. A decision is needed on whether to expand the approved software list. The VPN issue resolves itself in Q3 at no extra cost, no action needed. Same source material, organized around what the reader actually has to decide.

Same document both times. The only thing that changed was the prompt.

"Vibe coding"

This is the term for building software by describing what you want in plain language and letting an AI write the actual code. You review it, run it, and ask for changes, rather than writing the code yourself line by line. It's the core working method for Days 2 and 3: describe → review → run → refine until it works.

If you've never written code before, this is genuinely built for you. If you do have a coding background, the shift worth noticing is how much of this is about clearly describing what "done" looks like, rather than about syntax.

Hands-on: try it yourself (15–20 min)

Reading about prompting isn't the same as doing it. Open whatever AI tool you already have access to (ChatGPT, Copilot, Claude, Gemini, whatever's available to you today) and work through this checklist:

• Pick one real, small task from your actual job this week: an email, a document to summarize, a list to organize.
• Write a first prompt the way you normally would. Look at what you get back.
• Rewrite the same prompt using the "stronger version" habits above: specify audience and format, give it real context.
• Compare the two outputs. Notice what changed: that difference is the entire skill.
• Ask it to change one specific thing about its second answer: practice "iterate, don't restart."

Common questions, answered honestly

This is the one part of the pre-reading that isn't reading. Jot down answers to these below. Your notes save automatically in this browser. You'll bring this thinking into Day 1's brainstorm, so rough notes now save you a blank stare later.

Worked example, so you can see what "good" looks like:

A. Improve Existing Work: "Onboarding a new supplier takes about three weeks because the same information gets requested by four separate teams (procurement, finance, legal, IT) who don't talk to each other, so suppliers get the same emails asking for the same documents. It happens maybe 15–20 times a year. Roughly 6–8 hours of duplicated coordination effort per supplier, spread across four people. When it goes wrong, the supplier gets frustrated and either delays or sends inconsistent versions of the same document to different teams."

That's the level of specificity to aim for: not polished, just concrete.

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

Bonus, if you have five extra minutes: try turning your answer to A or B into a one-sentence prompt, the way you just practiced in Part 4. See what an AI tool gives you back. You're not looking for a finished solution, just a feel for how far a well-framed problem gets you before Day 1 even starts.

You don't need a polished answer, a clever framing, or a solution: just honest, specific observations from your own day-to-day. You'll also get a short separate survey asking a related question.