Collective Campus

Collective Campus

Innovation capability building for teams

Quick answer

Innovation capability building for teams starts with people who can frame a problem, test an idea and change how the work gets done. Collective Campus treats that search as capability building for the team you already have. The work covers problem framing, experimentation, lean startup, design sprints and AI prototyping, on a live idea or a live service. It runs with organisations, including Sydney, Melbourne and Brisbane, and across Asia. The shape of each programme is tailored after an initial conversation.

Book a scoping call

The work

What capability building gives a team

A team asks for help when an idea is stuck between a slide and a launch. Someone senior likes it. A business case is growing. Nobody has checked the part that could make the idea fail. Capability building is the practice of doing that check with the people who will live with the result. Collective Campus has run capability building programmes for organisations around the world since 2015. The same practice now includes AI, as one part of the work, for people who are not engineers.

The skill that matters is a sequence. Frame the problem so a stranger could recognise it. Name the assumption that would sink the idea. Design a test small enough to run with the resources already in the building. Build a thin version. Decide whether to continue, change or stop. When that sequence belongs to the team, the next idea does not wait for an outside facilitator. That is the standard we use when we shape a programme.

Buyers often arrive with a tool question or a workshop title. The useful question is closer to the work. Which decision is waiting, who can make it, and what evidence would change their mind? A programme that cannot answer those three lines will feel busy and leave the Monday work untouched. We start from the decision. The method, the room and the tools follow from it. The shape is tailored after an initial conversation.

Read the short account of how this practice started on our story. The pages linked through this guide are the live workshops: design thinking, lean startup and product sprint, AI design sprints, AI training, customer experience and agile. They are ways into the same capability. They are not a menu of unrelated courses.

Who it is for

Teams with a live idea or a live service

The work fits an intact team that already owns a problem. Product people, service designers, operators, marketers, policy staff, retail teams and professional services teams all show up in the published programmes. The common trait is not a job title. It is that the people in the room can describe the work as it happens today, and that someone with authority is close enough to hear what the evidence says.

Leaders use these programmes in three situations we see often. A new bet needs a first test before a budget locks in. A service is losing trust and the map on the wall describes the org chart, not the customer. A tool such as a copilot is already switched on, and leadership wants staff to change a real workflow. Each situation needs a different first session. Each one still ends in a decision the team can name.

Intrapreneurs sit in this picture when the organisation is willing to treat them as owners of a test, not as a side project. They need a sponsor, a time box that is real, and a path for evidence to reach a person who can stop the work. The later section on intrapreneurship programmes spells out that bargain. It uses the same methods as the rest of this page.

A public short course can introduce vocabulary. An in house programme uses the idea, the service and the constraints you already have. We build the sessions around that material. A canned case is a poor use of the room when a live problem is sitting in the business. If the team cannot yet name a live problem, the first job of the scoping call is to find one small enough to work on.

Skills

What teams build

Five skills carry the work. Problem framing stops the team solving the wrong thing. Experimentation turns an opinion into a test that could change a decision. Lean startup training for teams gives people a way to treat an idea as a set of assumptions. Design sprints compress framing, choices and a prototype into a shared direction. AI prototyping lets a mixed team build a thin version in tools they already have, after the workflow has been redesigned. The sections below say what good looks like in each skill, and where a published programme has already shown it.

Problem framing

Most teams arrive with a solution wearing the clothes of a problem. The sentence sounds like a need. We need an app. We need an AI assistant. We need a new policy. A frame asks who is stuck, what they are trying to get done, what they do today, and what would count as better. Until those four lines are stable, a prototype measures enthusiasm for a feature. It does not measure whether anyone has the problem.

A workable frame is narrow enough to test and wide enough to be about the person, not the feature. Narrow means a named step in a named journey. A claims handler retyping the same facts. A partner waiting on a first draft. A resident who cannot tell which counter owns the request. Wide means the frame still allows more than one response. If the only permitted answer is the solution someone already prefers, the frame is a brief in disguise.

We use a short test in the room. Could a customer or a frontline colleague recognise this sentence without our vocabulary in it? Could a different team propose a different response and still be answering the same problem? Can we point at evidence we already have, even if that evidence is only a handful of interviews or a pile of tickets? A frame that fails those checks goes back to the wall. The design thinking workshop spends its early sessions on this, because everything after it inherits a bad frame.

The move from insight to a question matters. At the M3 Property AI design sprint, each table picked one process, mapped how the work happens today and marked the steps that cost the most time. Teams then turned the problem into a how might we question, generated ideas and chose one to build. The question was a bridge. It was not permission to skip the map. Jobs to be done and customer interviewing sat in the same opening, so the room shared a method before anyone opened a tool.

Sponsors have a framing job too. They decide which problem is in bounds. A frame that quietly protects a favourite project will produce a polite workshop and a familiar recommendation. We ask the sponsor, before the room fills, what result would count as a reason to stop or to change course. That answer becomes part of the frame. It is the difference between a problem the team is allowed to look at and a problem the team is allowed to resolve.

An illustration, not a client engagement: a professional services team says it needs an AI assistant for proposals. The frame we would push for is closer to this. A proposal lead loses the first morning rebuilding context from the last three similar matters, and the partner reviews a draft that still misses the point of the brief. Better means the lead starts from a sourced brief, and the partner can see which lines came from the matter file. Several responses could fit that frame. A tool is one of them. A change to the brief template is another. The frame keeps both alive until a test says otherwise.

Experimentation

An experiment is a test that could change a decision you were already going to make. A demo, a survey of colleagues and a longer business case can all be useful. They are experiments only when the team has said, in advance, what result would continue the work, what result would change it and what result would stop it. Without that line, more data becomes more attachment.

Behaviour beats opinion when the decision is about what people will actually do. Asking a customer whether they like a concept gathers language. Asking them to click, book, pay a deposit, turn up, or complete a step gathers a different kind of evidence. Australian Unity's published programme shows the mix. Cross functional participants learned to build prototypes such as ads and landing pages, run campaigns and generate customer feedback. The teams ran more than 26 online and customer facing experiments on four private health insurance policy ideas. The experiments included social media ads, Google AdWords, landing pages and face to face interviews at targeted locations in the Melbourne CBD.

The published outcome is the part worth copying. Two of the ideas gained enough data to support the development of a business case internally. The assumptions underpinning two of the ideas were invalidated, and the teams reconsidered the business models or the ideas before further steps. Participants learned the value of moving quickly enough to gather insight and to drop a belief about what customers want. That is experimentation inside an organisation: evidence that can support a case, and evidence that can retire one.

A clean experiment record fits on one page. The assumption, written as a sentence that could be false. The customer or user. The test, small enough to run with current tools and current permission. The threshold, agreed with the sponsor before the test starts. The result. The decision. We would rather see five of those pages than a dashboard nobody is allowed to act on. The record is also how the skill spreads. A colleague who was not in the room can see why the team stopped.

Experiments inside a large organisation have constraints that a standalone startup does not. Brand, regulation, customer trust and the capacity of a frontline team all limit what a test may touch. Those constraints belong in the design of the test. They are not a reason to skip the test and return to a larger build. The scoping call is where we name them. A test that needs a legal review, a data approval or a script for frontline staff is still a test. It simply has a longer path to the first result, and the plan should show that path.

Lean startup

Lean startup, in this practice, is a way to learn under uncertainty before the organisation spends the full budget. The lean startup and product sprint puts a live bet on the table. The team writes what it believes, who it is for and why it would matter if it were true. It separates what it knows from what it is hoping. It designs the smallest test that could change its mind. It leaves with kill, change or continue criteria the room agrees on.

The lean canvas is the shared page, not a poster. It holds the problem, the proposed response, the customer segment, the assumptions and the metrics that would show the bet is real. AGL asked Collective Campus to upskill people from across its retail team in rapid experimentation and lean startup. The published session covered the origins of lean startup, why it matters, the lean canvas, identifying and prioritising key assumptions, identifying and prioritising prototypes, customer acquisition strategies, validation boards, actionable and funnel metrics, how lean startup applies in a corporate context, and how to get buy-in from executives.

That list is a useful picture of the method inside a large organisation. The canvas and the assumptions stop the team treating every uncertainty as equal. Prioritising prototypes stops the team building the impressive version first. Acquisition strategies and funnel metrics stop the team declaring success because a prototype exists. Executive buy-in is part of the method, because a test that leadership will not look at does not change the portfolio. The published account says participants gained a working understanding of how to apply lean startup at AGL, and some techniques for overcoming internal roadblocks. It also says participant feedback for the session was exceedingly positive.

A product sprint and a strategy offsite part company at the decision. An offsite can align people around a direction they already preferred. A sprint is doing its job when the team can point at an assumption that failed, or at a threshold that was met, and say what happens on Monday because of it. Zombie projects, the ones that stay alive because someone senior likes them, are the failure mode the method is built to interrupt. The interruption only works if the sponsor has agreed to hear a stop.

Regulated teams use the same bones with tighter tests. The workshop page for the product sprint says the tests are designed to learn without betting the franchise. That line matters in energy, health insurance, property advisory, government and financial services. A landing page, a concierge offer run by a person, a scripted interview or a prototype inside an approved tool can teach a great deal before a system build. The team writes down what it will not put in front of a customer yet. The discipline is the same. The surface of the test changes.

Lean startup also gives intrapreneurs a language their sponsor can audit. A canvas is visible. An assumption list is visible. A validation board is visible. The sponsor does not have to sit through a performance to see whether the work is learning or drifting. That transparency is why we teach the method as a management practice, not as a creativity exercise. Creativity still happens. It happens inside a page the organisation can govern.

Design sprints

A design sprint is a compressed sequence that widens the options and then converges with the people who have to live with the choice. It is a poor fit for a team that wants a tour of methods. It is a strong fit when several plausible directions are already in the air and the organisation is about to commit to one of them with more confidence than the evidence deserves.

The published two day innovation sprint with Inkeros is that situation in a single account. Inkeros, founded in 2001, is a Canadian omni channel sales and customer engagement company with more than 600 employees and operations across Canada and the United States. The company had a strong product and a real market, and faced too many plausible directions with no shared way to choose. Different stakeholders were quietly optimising for different outcomes. The risk was committing to the wrong directions together. Collective Campus facilitated a two day Lean Design Sprint in Toronto. Pre work meant the team walked in with evidence. Stakeholder perspectives were heard on their own terms. The sequence widened the aperture and then converged, separating genuine differentiators from table stakes, and pressure testing each direction against what customers actually value and what the business can sustainably deliver.

The published outcome replaced a scattered set of maybes with a single prioritised, evidence backed direction the whole team had built and bought into. Follow on tooling was put in place to measure impact and to institutionalise the thinking. Two details are worth keeping. The sprint was designed to force a choice, not to collect more ideas. And the work did not end as a wall of notes. Measurement had a place after the room emptied. A sprint that cannot say what will be measured has not finished converging.

The design thinking agenda that we already publish is the teaching version of the same arc. Frame the challenge. Empathise with interviews, observation and empathy mapping. Define a sharp problem statement. Ideate by diverging and then converging. Prototype and test something rough with real people. A customer experience programme uses those muscles on one live journey: pick the journey, see it from the outside, map the friction, choose one fix and prototype the moment. Both leave a method the team can run again. The customer experience workshop is the right door when the problem is a service people already feel.

Pre work is part of the sprint, not an optional reading pack. Inkeros walked in with evidence because the pre work was rigorous. In an Australian in house sprint we ask for the same class of material: the current process, the last few complaints or lost deals, the metric the sponsor already steers by, and the names of customers or frontline people the team can speak to. A sprint that starts from opinions will end in a more confident opinion. Evidence in the pre work gives the convergence something to push against.

Facilitation protects the two speeds. Widening fails when a senior voice closes the list early. Converging fails when the room is attached to being inclusive and will not cut. We hold the cut in the open. Options fall away because they are table stakes, because the customer evidence does not support them, or because the business cannot deliver them. The survivors get a prototype and a decision rule. People can disagree with the cut. They can see it.

AI prototyping

AI prototyping is the skill of building a thin, testable version with AI in the work, after the team has framed the problem and redesigned the workflow. It is one part of capability building. It is not the whole of it. A team that opens a model before it has named the costly step will paste a tool onto a broken process and call the result modern. We teach the redesign first.

The M3 Property account is the clearest published example. M3 Property is an independent property advisory firm with offices. Leadership had already given people access to Microsoft Copilot and wanted that access to become real changes in how work gets done, while protecting the quality and professional standards clients rely on. Collective Campus ran a one day AI design sprint inside the firm's annual staff conference on the Gold Coast. Staff found problems in their own workflows, redesigned them with AI, built working prototypes and showed leadership what they built.

Steve Glaveski led the day with co-facilitator Tessa Kowaliw. The opening covered design thinking, lean startup, customer interviewing and jobs to be done. Each table picked one process, mapped the current work and marked the steps that cost the most time. Teams wrote a how might we question, generated ideas and chose one to build. In the prototype sprint, some people built a working prototype in Copilot while others built the pitch. The rule was to redesign the workflow first and then apply AI. Teams then pitched to a panel of M3 leaders, joined by Steve and Tessa.

The published results are specific. Teams built working prototypes in Copilot on the day. Across the room they produced 20 ideas, eight teams pitched, and the panel picked two winners. The strongest ideas now go to M3's internal team for prioritisation and development. Staff designed every prototype around their own real workflows, using tools the firm already has. That gave leadership a practical, staff owned pipeline of AI improvements. The full account is on the M3 Property case study.

The pattern generalises beyond that conference. AI design sprints tie a brief to a real customer or operator problem, use AI to widen research and then check it against real evidence, generate more options than the room would invent alone, build a thin version and decide to proceed, change or stop. AI training builds the adjacent skill: use cases in the team's own work, hands on reps, prompting that produces usable output, and guardrails for data, accuracy and compliance. Training builds skill. A sprint spends that skill on one decision. Programmes often put a short training rhythm next to a sprint so people are not meeting the tool for the first time in front of a leader.

Guardrails are part of the prototype, not a slide at the end. We work from the rule already on the AI pages. Use dummy or approved data. Name what must not be pasted into a tool. Check an output before it is treated as advice. A property valuer, a lawyer, a clinician or a case officer does not get a free pass because the prototype looks finished. The pitch includes where a human still decides. At M3, protecting professional standards was part of the original brief, and the prototypes sat inside a tool the firm had already chosen. That is the shape we look for. The organisation's own stack, the organisation's own workflow, a person who remains accountable.

People who are not engineers can prototype when the version is thin. A script, a prompt chain on an approved data set, a revised checklist, a clickable walkthrough, a sample output marked up with what the reviewer must check. Engineers help when the bet survives and the workflow needs a real integration. Putting them in the room on day one is useful. Making the team wait for them before it can learn is not. The decision to integrate is one of the decisions the sprint is allowed to reach. It is not the entry ticket.

How the skills connect

One sequence, several doors

The five skills are a sequence the team can enter at different points. A fuzzy mandate starts at framing. A loved idea with no evidence starts at assumptions and a test. A pile of directions starts at a sprint. A tool that is already licensed, with no change in the work, starts at workflow mapping and then a prototype. Skipping backwards is allowed. A prototype that reveals the problem was wrong should send the team back to the frame. We treat that return as success. The expensive failure is a team that keeps building after the frame has broken.

Agile sits beside this sequence when the question is delivery rather than discovery. The agile work is how the team ships the thing it has already decided to pursue, on work it already owns. Rituals without a decision upstream do not create capability. A sprint decision with no way to deliver it does not create value. The scoping call says which problem the team actually has. Some programmes need both, in that order. Discovery first, then a delivery rhythm on the survivor.

Psychological safety sits under the sequence, because a test that invalidates a senior person's idea will be softened unless the room can say so. The psychological safety workshop is the place we work on that directly. The high performance teams work is the neighbouring practice: a team that can hold a standard and still tell the truth about a result. Capability building assumes that climate. Where it is missing, we say so on the scoping call rather than pretending a canvas will fix it.

Programmes

Programme options

Every option below is a live workshop or a sequence we shape from those workshops. None of them is a public calendar with a fixed seat price. The length, the cohort and the follow up are tailored after an initial conversation. What stays constant is the material: your idea, your service, your tools, and the people who can decide.

Problem framing and design thinking

Use this when the team is jumping to build, or when leaders disagree about the problem. People leave with a problem they have checked, a first round of options, and at least one rough prototype tested with someone outside the project team. The published outcomes include a problem worth solving, firsthand customer insight, ideas the team is willing to kill, and a method it can run without us. Details sit on the design thinking page.

Lean startup and product sprint

Use this when a bet is about to become a project. The team names the riskiest assumptions, designs a test it can run with current resources, and agrees the rule for continuing or stopping. Sponsors belong in the decision session even if they are not in every working session. Details sit on the lean startup and product sprint page.

Design sprint for a choice the team is avoiding

Use this when there are too many plausible directions. Pre work brings evidence in. The room widens, then cuts, then prototypes the survivor. Inkeros used a two day Lean Design Sprint for this job. An in house version uses the same logic on an Australian team's own options. The length is set in the scoping call, not copied from a past engagement.

AI design sprint

Use this when the organisation already has a tool and wants a staff owned pipeline of workflow changes. The M3 Property day is the reference: shared method, one process per team, redesign, prototype in the existing stack, pitch to leaders who can prioritise. The generic version is on the AI design sprints page. Vendor choice follows what the team is allowed to use.

AI training beside the sprint

Use this when people need reps before they prototype. The training is hands on, on a task the team already has, and it includes guardrails. It is the wrong booking if the only goal is a keynote about the future of the industry. Pair it with a sprint when the organisation wants both skill and a decision. The AI training page carries the outcomes and the tools conversation.

A sequenced capability programme

Some teams need the sequence, not a single door. A typical shape, always adjusted after the scoping call, runs like this. A framing session on the live service. A sprint that chooses one response. A lean test that puts that response in front of real behaviour. A short AI prototype only if the workflow and the guardrails are ready. A decision meeting with the sponsor. Follow up so the next bet uses the same record. Customer experience work replaces the framing session when the live problem is a journey. Agile coaching follows when the survivor has to be delivered by a team that is still performing ceremonies without shipping.

Customer experience and agile, when they are the real problem

We will not force a sprint label onto a journey mapping problem or a delivery problem. If customers are dropping out of a known path, start with customer experience. If the team already knows what to build and cannot get it out the door, start with agile. Both still count as capability building. Both still require a live piece of work. The label on the calendar matters less than the decision the team is trying to earn.

Agendas

Sample agendas

These running orders show the work inside a programme. They are samples, drawn from agendas we already publish and from the sequence used on published engagements. They are not a promise of hours. Session length, breaks and the number of sessions are tailored after an initial conversation. Where a past engagement had a length, we report that length as history. Your programme gets its own.

Sample A. Problem framing and design thinking

Best when the team needs a shared problem before it earns the right to prototype. Bring the challenge, any interviews or tickets you already have, and one person who has actually served the customer or used the process.

  1. Session 1. Frame the challenge

    Align on the decision this programme must inform, who it is for, and what is out of bounds. The sponsor says what result would change the plan.

  2. Session 2. See the work from the outside

    Interviews, observation, artefacts and frontline stories. The room collects what people do, not what the org chart says they should feel.

  3. Session 3. Write the problem

    Turn the mess into a problem statement a customer could recognise. Test it against the four lines: who is stuck, what they are trying to do, what happens today, what better means.

  4. Session 4. Generate options and choose

    Diverge on responses, including responses that are not a new product. Converge by killing what the evidence does not support and what the business cannot deliver.

  5. Session 5. Prototype and test

    Build something rough. Put it in front of a real person the same way the design thinking agenda describes. Capture what would have to be true to take a further step.

Sample B. Lean startup on a live bet

Best when an idea is about to become a funded project. Bring the idea, the customer you think it is for, and the sponsor who can stop it. This order follows the published product sprint: name the bet, find the risk, design the test, build a thin version, decide.

  1. Session 1. Name the bet

    What you believe, who it is for, and why it would matter if it were true. Put it on a lean canvas in the team's own words.

  2. Session 2. Find the risk

    List assumptions. Mark what you know, what you are hoping, and which hope would sink the idea if it is false. Pick one to test first.

  3. Session 3. Design the test

    The smallest experiment that could change your mind. Name the behaviour you will watch, the threshold, and what you will not do to the customer or the brand.

  4. Session 4. Build a thin version

    A prototype, a concierge offer, an ad, a landing page or a script. Not a full product. AGL's session treated prototype choice as its own skill. Australian Unity used ads, landing pages and interviews.

  5. Session 5. Decide

    Read the evidence against the threshold. Continue, change or stop. Write the owner of the next step and the date the sponsor will look again.

Sample C. AI prototyping after the workflow is redesigned

Best when a tool is already available and leadership wants staff to change real work. This order follows the M3 Property day and the published AI design sprint. M3 ran it as one day inside a conference. Another organisation might split the same sessions across a different shape. The scoping call decides.

  1. Session 1. Shared method before tools

    Design thinking, lean startup, customer interviewing and jobs to be done, so the room agrees how it will choose. Guardrails for data and professional standards are named here.

  2. Session 2. One process, mapped

    Each group picks one process, maps how the work happens today and marks the steps that cost the most time. The map is the brief. The tool is not.

  3. Session 3. One idea worth building

    Turn the costly step into a how might we question. Generate options. Choose one. Write what the redesigned workflow does before any model is opened.

  4. Session 4. Prototype in the tools you already have

    Some people build a thin version. Others build the pitch. Use the approved stack. Check outputs. Keep a human decision where the standard requires one.

  5. Session 5. Pitch and prioritise

    Teams show the workflow, the prototype and the limit of the test to the people who can fund the next step. The result is a short list leadership will actually take forward, as M3 did when two pitches were chosen and sent to an internal team.

A half sequence is legitimate. A leadership group might only need sessions one and five, with a working team covering the middle. A team that has already framed the problem might start at the test. We would rather run a short programme on the live decision than a long programme that rehearses every method. Say that on the scoping call if you already know which sessions you do not need.

Book a scoping call

Delivery

How a programme runs

The first step is a scoping call. We ask what decision is waiting, who can make it, what has already been tried, and which constraints are real. Data rules, brand rules, award conditions, regulatory limits and the simple fact of a crowded quarter all belong in that conversation. You should leave the call with a view of whether we are the right people for the job. We will say so if a different door, such as delivery coaching or a customer journey, fits better than a sprint.

Tailoring comes next. We build the sessions around the live idea or the live service, using language from your work. Pre work is specific: a process map, a handful of customer conversations, the metric you already trust, the tool your people are allowed to open. A generic slide deck about the history of innovation is a poor use of that time. Participants should recognise their own work within the first session.

Delivery is in the room or remote, for teams across Asia Pacific and beyond. Remote sessions are built as working sessions. They are not a webinar of an in person workshop. Mixed cohorts can work when the problem is shared. Intact teams work better when the point is a habit that has to survive on Monday inside one group. The published programmes show both patterns: a conference room of many tables at M3, a cross functional group of 20 at Australian Unity, a retail cohort at AGL, a stakeholder group in Toronto for Inkeros.

Follow up is part of the capability, because a method that only works while we are in the room has not transferred. The minimum follow up is a decision record and a date on which the sponsor looks at the next test. Where it helps, we stay for the first experiment, the way a product sprint can extend past the build of the prototype. Tooling that measures the bet, as Inkeros put in place after the sprint, beats a souvenir photo of a whiteboard. The amount of follow up is tailored after an initial conversation, alongside the sessions themselves.

Between sessions, the team owns the artefacts. The canvas, the problem statement, the assumption list, the prototype and the decision line should live where the team already works, not in a facilitator slide. We will show a simple record. We will not become the only people who can update it. That ownership is the practical meaning of capability.

Proof

Case studies from published work

The four accounts below are taken from published Collective Campus case studies. Figures, places and outcomes appear only where that copy states them. They are not a promise that the next programme will reproduce the same counts. They show the methods in real rooms.

M3 Property, AI design sprint on the Gold Coast

M3 Property is an independent property advisory firm with offices. The firm had given staff Microsoft Copilot. Leadership wanted real changes in how work gets done, without giving up the professional standards clients rely on. Collective Campus ran a one day AI design sprint at the annual staff conference on the Gold Coast so staff could find problems in their own workflows, redesign them, build working prototypes and show leadership.

The day moved through a shared method, process mapping, a how might we question, a prototype sprint in Copilot and a pitch to M3 leaders. The rule was to redesign the workflow before applying the tool. Results published on the case study: 20 ideas, eight teams pitched, two winners chosen by the panel, and a staff owned pipeline passed to M3's internal team for prioritisation. Steve Glaveski and Tessa Kowaliw facilitated. Read the M3 Property AI design sprint.

What it shows for capability building: people who do the work can frame a process, prototype in a tool the organisation already trusts, and hand leaders a short list. AI sat at the end of the method, not in front of it.

Inkeros, two day Lean Design Sprint in Toronto

Inkeros is a Canadian omni channel sales and customer engagement company, founded in 2001, with more than 600 employees and operations across Canada and the United States. Stakeholders were optimising for different outcomes, and the company risked committing to the wrong directions with confidence. Collective Campus facilitated a two day Lean Design Sprint in Toronto. Pre work brought evidence into the room. The group widened its options and then converged, separating differentiators from table stakes and testing directions against customer value and what the business could sustainably deliver.

The published outcome was a single prioritised, evidence backed direction the team had built and bought into, plus follow on tooling to measure impact and institutionalise the thinking. Read the two day innovation sprint. The engagement was in Toronto. We include it because the copy shows the sprint pattern clearly, not because every programme is held in Canada. Teams use the same pattern on their own material, with the city and the length set on the scoping call.

AGL, lean startup with the retail team

AGL Energy Ltd is an Australian listed public company involved in the generation and retailing of electricity and gas for residential and commercial use. AGL wanted to upskill employees from across its retail team in rapid experimentation and lean startup. Collective Campus delivered a full day lean startup training session, customised for AGL. The published topics were the origins of lean startup, why it matters, the lean canvas, key assumptions, prototypes, customer acquisition strategies, validation boards, actionable and funnel metrics, how lean startup applies in a corporate context, and how to get buy-in from executives.

Participants gained a working understanding of how to apply lean startup at AGL, and techniques for overcoming internal roadblocks. The published account says participant feedback was exceedingly positive. Read the AGL case study. What it shows: lean startup can be taught as a working method for a retail organisation, including the political skill of taking evidence to executives. The page does not invent a project count the case study does not give.

Australian Unity, tests on four policy ideas

Australian Unity is one of Australia's leading private health insurance companies. The organisation asked Collective Campus to facilitate a two day programme so a cross functional group could build prototypes and test assumptions behind private health insurance policy ideas with target customers. The sought outcome was quantitative and qualitative learning that could support ideas internally and support further work of the same kind.

Collective Campus worked with a group of 20 cross functional participants. They used the lean canvas to define problem, solution and customer segment, identified assumptions and metrics, and built prototypes such as ads and landing pages. They ran campaigns and spoke to customers. The teams ran more than 26 online and customer facing experiments on four ideas: social media ads, Google AdWords, landing pages and face to face interviews at targeted locations in the Melbourne CBD.

Published results: new insight into what customers actually want, two ideas with enough data to support an internal business case, and two ideas whose assumptions were invalidated so the teams reconsidered before further spend. Participants saw the cost of delivering something customers do not want. The programme also built internal momentum for this kind of work. Read the Australian Unity case study.

Inside the organisation

Intrapreneurship programmes

Leaders searching for an intrapreneurship programme usually want startup methods in the hands of people who already work inside the organisation. The aim is a team that can frame a problem, test a response and bring a sponsor a decision, on a venture, a service change or a new offer. Collective Campus builds that capability with the team. The methods are lean startup, design sprints, experimentation and, where it helps, AI prototyping. The programme is tailored after an initial conversation.

An intrapreneur, in the way we use the word, is an employee with a live problem, a sponsor and permission to run a test. The idea does not need to be a standalone company. It needs an assumption that the organisation is currently treating as fact. Australian Unity's cross functional group testing policy ideas is the published pattern: people from inside the business, a canvas, cheap prototypes, contact with customers, and a result that could support or retire a business case. AGL's retail session is the published pattern for the skill underneath: how lean startup works in the organisation, and how evidence travels to executives.

The sponsor's job is the part that makes the programme real. A sponsor names the decision, protects a slice of time, and agrees to continue, change or stop when the threshold is met. Without that agreement, intrapreneurs collect sticky notes and return to the day job. We write the sponsor's role into the scoping call. If nobody can stop the work, the team does not yet have a programme. It has an exhibition. Getting to a named sponsor is a legitimate outcome of the first conversation.

Startup methods inside a large organisation are specific tools, not a costume. The lean canvas forces problem, customer and success metric onto one page. Assumption ranking stops the team researching the easy question. A validation board shows the tests in flight. Ads, landing pages, concierge trials and interviews, the set Australian Unity actually used, sit at the cheap end. A design sprint, the set Inkeros used, is how a group of stakeholders chooses a direction before those tests multiply. AI prototyping, the set M3 used, is how a thin version gets built in the tools staff already have, after the workflow is redesigned. A programme for intrapreneurs borrows from that set. It does not need every piece on day one.

A practical intrapreneurship rhythm, adjusted on the scoping call, looks like the sequenced programme above. Week patterns vary, so we will not pretend there is a single calendar. The beats are stable. Choose one problem the sponsor cares about. Frame it in the customer's words. Fill a canvas. Pick the riskiest assumption. Run one test that watches behaviour. Prototype only as far as the test requires. Decide in a meeting where the sponsor is present. Capture the record where the next team can find it. Then run the rhythm again on the next bet, with less facilitation. Capability is the second run.

Idea portals, hack days with no decision and slide courses about famous startups leave intrapreneurs without a path. A portal can collect demand. It does not teach a test. A hack day can produce a prototype, and the Australian Unity copy uses that energy inside a two day programme that also named assumptions and faced customers. The prototype was not the end. The evidence was. A slide course can provide vocabulary. The vocabulary has to land on a live bet in the same programme, or it fades before Friday.

Selection of intrapreneurs matters as much as the curriculum. We look for people who do the work the problem sits inside, plus one or two colleagues who see a different part of the path. A room of only enthusiasts will design for themselves. A room that includes the operator, the person who handles the customer and the person who understands the constraint will design a test the organisation can run. Twenty cross functional participants was the Australian Unity shape. A conference of many tables was the M3 shape. Your number is tailored after an initial conversation. We do not publish a standard class size.

Governance keeps the programme inside the organisation's risk appetite. Intrapreneurs should know what data they may use, which customers they may contact, what they may promise and who signs the next spend. Those rules are an input to the test design, as they are for any regulated lean startup work. A programme that hides experiments from risk, brand or technology will create a shadow process. A programme that invites those people to set the boundary, and then lets the team test inside it, creates a path executives can defend.

The founder's own history is part of why this practice exists. By 2013 Steve Glaveski had spent almost a decade inside large professional services firms and investment banks. He was a frustrated intrapreneur, with ideas stifled by bureaucracy. Collective Campus grew from the question of how people in that position build skill and evidence, not from a wish to collect ideas on their behalf. The longer account is on our story. We mention it so the intrapreneurship work has a reason. The programmes themselves are judged by the team's decision record, not by the founder's biography.

If you are comparing an intrapreneurship programme with sending people to a public course, use three questions. Will they practise on a live bet with their sponsor in the decision? Will they leave with a test record a colleague can reuse? Will the second bet need less outside help than the first? A yes on all three is capability building. The lean startup and product sprint is the workshop we use most often as the core of that yes. Design sprints and AI prototyping bolt on when the bet needs a choice among directions or a thin version in the existing stack.

Australia

Where the work runs

Australia comes first. In person programmes run in Sydney, Melbourne and Brisbane, and we travel to the team when the room needs to be theirs. Remote and hybrid cover people who are split across offices. The Gold Coast conference for M3 and the Melbourne CBD interviews for Australian Unity are examples of the work meeting the team where the team already was. They are not a limit on the map. If your people are in another city, say so on the scoping call and we will plan delivery around them.

Collective Campus has run capability building programmes for organisations around the world since 2015. That line is the span of the practice, not a claim that every city has an identical public course. Asia engagements are scoped the same way: a live problem, a sponsor, a method the team keeps. Time zones and language of the work get named early. A remote sprint across countries needs stricter pre work, because the room cannot rely on hallway context.

Local proof matters more than a borrowed case. When we work with a Sydney, Melbourne or Brisbane team, the artefacts should name their customers, their process and their constraint. A Toronto sprint can teach the pattern. It should not become the story your team tells on Monday. Bring the local material. We will build the sessions from it.

After the session

How to tell the work stuck

We do not invent a return on investment figure for this page. The published cases give concrete traces instead. M3 left a pipeline of staff designed prototypes and a leadership choice of two winners. Inkeros left one evidence backed direction and tooling to measure impact. AGL left retail people with a working understanding of lean startup and of the internal roadblocks. Australian Unity left more than 26 experiments, two ideas supported towards a business case, and two ideas pulled back because assumptions failed. Those are the kinds of traces a serious programme can show. A decision record carries more than a smile sheet.

Inside your programme, ask for five signs. The problem statement is in the team's words and a customer could recognise it. The riskiest assumption is written down. A test happened, or is scheduled with an owner, and it watches behaviour rather than collecting only opinions. The sponsor has said continue, change or stop. Someone who missed the session can find the record and run the next step. If those signs are present, the capability is in the building. If they are missing, the session was a visit.

A second bet is the cleanest measure. The first bet has facilitators in the room. The second bet should show the team using the canvas, the test record and the decision rule with a lighter touch from us. We design follow up towards that second bet when the scoping call includes it. Some organisations only need the first decision. That is a valid scope. Say which one you want, and the programme will aim at it.

Leaders can review the work without sitting in every session. Ask to see the frame, the assumption, the threshold and the result. Ask who owns the next step. Ask what was stopped. A team that can answer those questions is building capability. A team that can only show a prototype is still in the middle of the sequence.

Standards

What a useful programme produces

A useful programme produces a decision the team can carry out, and a method the team can repeat. The decision may be to continue, to change the idea, or to stop. Stopping is a successful result when the threshold said stop. The method is the record: frame, assumption, test, prototype, owner. People should be able to explain it without our slides.

The team works on a live idea or a live service. The tools in an AI session are tools the organisation can actually use, with a rule for data. The workflow is redesigned before a model is applied. Sponsors hear the evidence in a session built for that purpose. Follow up has a date. These are the standards we hold on the scoping call, and they are the standards to hold us to afterwards.

A programme can be small. A single framing session plus a decision rule is enough when that is the missing piece. Size is not the signal. The signal is whether Monday's work uses what the room made. We would rather be hired for that outcome than for a long catalogue of methods the team will not touch again.

People

Who facilitates

Steve Glaveski is the founder of Collective Campus and the head facilitator on flagship programmes. He led the M3 Property AI design sprint with Tessa Kowaliw, including the pitch session with M3 leaders. He has worked inside large organisations and built the practice around teams that need startup methods without leaving their jobs. A short biography and the story of the practice sit on our story.

Tessa Kowaliw is a design thinking and customer experience facilitator. She co-facilitated the M3 Property day. Her work suits rooms that need a clear problem and a customer view before any tool is opened. The scoping call names the facilitator for your programme. Where a second facilitator strengthens the room, as it did at M3, we will say so.

Facilitation, in this practice, is the protection of the sequence. We keep the frame stable, the cut visible and the decision attached to evidence. We are not there to supply the idea. The team's problem, the team's customer and the team's constraint do that. A good room feels demanding and specific. People should leave able to run the next step without waiting for us to book another date, even when a later session is part of the plan.

Scoping call

Questions to bring to the scoping call

The call is short enough to be useful and long enough to tell whether a programme should exist. Bring what you can from the list below. Gaps are fine. A gap is often the first piece of work. The format that follows is tailored after an initial conversation.

  • What decision are you trying to earn, and by when does it need to be made?
  • Who can continue, change or stop the work? Will that person hear the result?
  • What is the live idea or the live service? What have you already tried?
  • Which customers, users or frontline staff can the team speak to?
  • What data, brand and regulatory limits should a test respect?
  • If AI is in the picture, which tools are already approved, and what must never be pasted into them?
  • Who must be in the room for the method to survive, and who would only be an audience?
  • What would you want a team to do differently on the second bet?

You do not need a finished brief. You do need a willingness to put a real piece of work on the table. If the only available material is a hypothetical, we will help you find a live slice before we design a long programme. That choice saves the room from rehearsing on fiction.

Questions

Common questions

What does capability building cover at Collective Campus?
People practise how to frame a problem, test an idea, see a service from the outside and change how they work. The methods are problem framing, experimentation, lean startup, design sprints and AI prototyping. The point is skill that stays when the session is over, used on work the team already owns.
Is this only AI training?
No. Collective Campus has run capability building programmes for organisations around the world since 2015. AI is one part of that work. A team can build the earlier muscles, framing, testing and sprinting, and use AI when a prototype is the right next step.
Where do you run it?
With teams, including Sydney, Melbourne and Brisbane, and across Asia. Delivery is in the room or remote. The scoping call confirms which mix fits the people who need to decide.
What should we bring?
A live idea or a live service, and the people who can decide what happens next. We shape the work around that, rather than around a canned case. Useful material includes the current process, any evidence you already trust, and the name of the person who can continue or stop the work.
How is a programme priced?
It is tailored after an initial conversation. Format, who is in the room and how far the work goes after the first sessions are set on the scoping call. This page does not list a fee.
What is the difference between a design sprint and a lean startup sprint?
A design sprint builds a shared direction and a thin prototype people can react to. A lean startup sprint treats the work as a bet: name the risky assumptions, design a cheap test and agree what evidence would continue, change or stop it. Many programmes use both. Framing and a sprint come first. A test of real behaviour follows when the decision needs evidence from outside the room.
Can people who are not designers or engineers take part?
Yes. The sessions are built for cross functional teams. Designers and engineers help when the work needs them. They are not a condition of entry. At M3 Property, staff who already do the work designed prototypes in Microsoft Copilot, a tool the firm already had.
What is an intrapreneurship programme in this context?
It is a way for people inside a large organisation to use startup methods on a live problem, with a sponsor who can act on the evidence. The methods are the same ones on this page: a clear problem, a lean canvas, ranked assumptions, a cheap test, a thin prototype and a decision. Collective Campus shapes that programme after a scoping call. It is not a public short course and it is not a portal for collecting ideas.
How do you know the work stuck?
The team can state the problem, the assumption under test and the decision rule without a facilitator in the room. Someone owns the next test. A published example is the M3 Property sprint, where staff left leadership with a pipeline of workflow prototypes. Another is the Australian Unity programme, where teams ran experiments and dropped assumptions that the evidence did not support.
Can a regulated team do this?
Yes. The tests are designed to learn without betting the franchise. AGL's retail lean startup session included how the method applies in a large organisation and how to seek executive buy-in. Australian Unity tested policy ideas with ads, landing pages and interviews, and used the evidence to support or reconsider a business case. The scoping call is where constraints on data, customers and sign-off get named.
Do you run this in Sydney, Melbourne and Brisbane?
Yes. Those are the core cities for in person work, and the same programmes run remote when the team is split. Australian Unity's published programme included face to face interviews in the Melbourne CBD. M3 Property's AI design sprint ran at a staff conference on the Gold Coast. The city is a delivery choice. The work is still the team's own problem.
Who facilitates?
Steve Glaveski, founder of Collective Campus, leads flagship programmes and led the M3 Property AI design sprint with co-facilitator Tessa Kowaliw. Tessa is a design thinking and customer experience facilitator. The scoping call names who will be in the room for your programme.

Book a scoping call