Collective Campus
Blogs

Programmes

How to run an intrapreneurship programme in a large Australian organisation

A glasshouse inside a dark tower, a compass and a faceted gem in a dense collage

A large organisation can name a cohort, book a room and still finish the year with a poster. The people in the cohort were serious. The ideas were not silly. The missing piece was a decision the company was allowed to make while the bet was still cheap.

That decision is the whole point of an intrapreneurship programme. Employees use startup methods on a live bet inside the organisation they already work for. The brand, the customers, the regulator and the budget cycle stay in the room. The programme earns its name when a sponsor can stop, change or continue the bet on evidence, and when the people who ran the test can do it again without a festival.

Collective Campus has done capability building for teams since 2015. The work is how a group tests an idea, sees a service from the outside and changes how it works together. AI has been part of that practice since 2022. It can draft a page or sort a pile of notes. It does not choose which bet is allowed to die. The programme below is written for teams in Sydney, Melbourne, Brisbane and the hybrid mix of those cities.

What an intrapreneurship programme actually is

An intrapreneur is an employee who builds something new with the organisation's assets, not a founder who has left to start a company. A programme is the repeating way those people get a bet, a sponsor, a test and a decision. A single workshop can teach the moves. A programme is what happens on the Tuesdays after the workshop, when the test has to survive a steering meeting.

The assets are the reason to do this inside the building. A bank already has customers, a licence and a brand people recognise. A utility already has a network and a duty. A council already has a suburb and a service standard. A startup method that ignores those assets produces a toy. A method that worships them produces a business case nobody has tested. The useful middle is a small bet that uses the asset and does not pretend the asset is proof.

Proof and permission are different. Permission is a senior person liking the theme. Proof is a person outside the team behaving in a way that would matter if the bet were true. A click, a switch, a booking, a complaint that names the new offer, a frontline colleague who will carry it next week. The programme exists to create that kind of proof before the organisation spends the year building.

A bet, not a theme

Themes are how planning sessions stay polite. Growth, risk, service, cost, capability. Nobody has to disappoint a colleague if every theme survives. A bet is ruder. It names who it is for, what they would do differently, and why the organisation would be better off if that were true. If the sentence can be said of three unrelated ideas, it is still a theme.

Write the bet in language a customer could correct. "Small businesses in western Sydney will switch their energy plan if the exit fee is explained before the sale" can be tested. "Reimagine the retail experience" cannot. The first sentence can be wrong in a useful way. The second can only be applauded.

One bet per team is a kindness. Two bets give the team a place to hide when the first one looks shaky. The programme can hold several teams. Each team should be able to point at one sentence and say that this is the thing the next test is about.

Internal customers count, and they are still customers

Some of the best bets inside a large organisation never face a paying outsider. A claims team wants a simpler handoff. A council team wants the permit question answered once. A professional services firm wants the partner pack to stop eating Thursday. These are still bets. The customer is the person who has to live with the change, and that person can reject it.

Treat an internal customer with the same discipline as an external one. Do not let the team interview only its friends. Do not let a senior sponsor stand in for the user. A director saying the branch would love it is a hypothesis. A branch colleague changing a real Tuesday is evidence. The programme should say, in writing, which of those two the team is collecting.

Who has to be in it

Three roles make the programme real. The sponsor can fund the next test or stop the bet, and stays until that call is made. The team does the work and is close enough to the customer to notice a weak sentence. A guide, from inside or from outside, keeps the method honest when the room wants to skip to a build. Miss any one of the three and the week turns into theatre with better stationery.

The sponsor is not a guest speaker. If they open the session and leave, the team will design a test that dies in the next steering meeting. The useful sponsor can say, in front of the team, what result would make them stop. That sentence is uncomfortable. It is also the sentence that protects the team from a zombie project later.

Legal, risk, brand and technology are not an audience. They are constraints the test has to respect. Invite them when the bet touches their rule, and give them a job: name the line the test must not cross. A review that arrives after the prototype is built is how a fortnight of work becomes a slide that says "not yet". A constraint named on day one is a design input.

Time that is actually protected

A programme that runs on evenings and goodwill will select for people who can donate time, not for the people who know the work. The manager who loses a strong operator for part of the week has to agree before the cohort starts. If that manager is surprised, they will pull the person back at the first busy Monday, and the test will slip until it is no longer a test.

Protected time is a calendar fact. The team can point at the hours, and those hours are not the first thing a restructure eats. How many hours, and over how many weeks, is a scoping question. Collective Campus does not publish a fixed length. The shape is tailored after an initial conversation, because a regulated bet and a service bet do not need the same room.

The same rule applies to the sponsor's time. A decision that waits three months for a quarterly forum is not a decision. It is a delay wearing a governance costume. Put the decision date in the diary when the bet is named, and keep it shorter than the organisation's instinct.

Startup methods that survive a large organisation

The public Lean Startup principles are short enough to pin above a desk. Entrepreneurs are everywhere, including inside a company that does not call itself a startup. Entrepreneurship is a management practice, not a personality. Progress is validated learning. Accounting for a new bet is not the same as accounting for a known product. And the loop is build, measure, learn, in that order only when the thing you build is the smallest thing that can teach you.

Steve Blank's Harvard Business Review essay, Why the Lean Start-Up Changes Everything, makes the management point for people who already run a large organisation. A new bet is a search for a model that repeats, not a smaller version of the annual plan. The search needs hypotheses, and a hypothesis is only useful if something could prove it wrong.

Inside a large Australian organisation the loop has extra weight. The brand can make a thin test look official. A landing page on the real domain is not a napkin. Customers may treat it as a promise. The method still works, but the test has to be labelled as a test, limited in who sees it, and easy to take down. A regulated team in banking, insurance, energy, water or government can learn without betting the franchise. The learning is smaller. It is still learning.

The canvas is a page, not a ritual

A lean canvas is useful because it forces the bet onto one page: who it is for, the problem, the offer, the reason it might make money or save cost, and the assumptions holding it up. It is not useful as a poster. If the team fills every box in an hour and nobody argues, the boxes were too vague. The argument is the point.

Separate what the room knows from what it hopes. Known facts have a source a sceptic can open. Hopes sound like facts because the team has repeated them. "Customers hate the waiting time" is a hope until someone can show the wait, the customers, and what they did about it. The programme should embarrass a hope kindly, in the room, before it becomes a line in a funding paper.

Then rank the hopes by how much they could sink the bet and how little the room knows. The riskiest assumption is often dull. Will the sales team carry the new offer. Will a customer switch. Will the operations team do the manual step the prototype hides. Will the regulator treat the trial as the product. Test that one first. A beautiful interface on top of a false assumption is an expensive drawing.

Prototypes a company is allowed to put in front of people

A prototype is a way to ask a question, not a small product. Ads and a landing page can ask whether anyone will stop. A concierge version can ask whether the service is wanted when a human still does the hard part. A clickable sketch can ask whether a person understands the step. A conversation in a branch, a depot or a service centre can ask whether the problem is even the problem.

Choose the prototype that matches the risk, not the one the team knows how to make. If the risk is demand, do not spend the week on a workflow diagram. If the risk is whether staff will adopt the new step, do not spend the week on a public campaign. The smallest test that could change the sponsor's mind is the right size. Anything larger is a build pretending to be a question.

Tools change. The discipline does not. A team in 2017 used landing pages and interview notes. A team now can draft the page, the ad and the interview guide with a model, then still has to send the page to a real person and read what that person does. The model is not the customer. Capability building since 2022 has included that distinction on purpose.

A metric the sponsor is allowed to dislike

Agree the number before the test runs. What will you count, from which source, over which window, and what result means stop, change or continue. If the team picks the metric after it has seen the data, the metric will be kind. Kind metrics are how weak bets survive.

Vanity is easy to recognise once you say it aloud. Page views on an internal post. The number of ideas submitted. A satisfaction score from the people who attended. None of those tell you whether the bet is true. Actionable numbers are closer to the behaviour: how many of the invited customers took the next step, how many staff used the new path when the old path was still available, how many conversations ended with a request to be told when it was real.

Write the kill rule in the same sentence as the target. "If fewer than the agreed number take the step, we stop this offer and do not reopen it without new evidence." The number itself is the sponsor's, not a number borrowed from another company. Publishing someone else's benchmark as if it were yours is how a programme imports a fantasy.

How to design the programme before the first room

Start with intake, not with a call for ideas. A call for ideas rewards people who write well and punishes people who are busy with a real problem. Ask leaders for the decisions they are about to fund, and ask frontline teams for the workarounds they have already built. Those two lists are full of bets. A suggestion box is full of wishes.

Score each candidate on three plain questions. Is there a customer, internal or external, who can be reached without a new project. Is there a sponsor who will attend the decision. Is there an assumption that could be tested with the people and money already available. A candidate that fails one of those waits. Waiting is not an insult. It is how the programme stays small enough to finish.

Write the rules before anyone falls in love with a prototype. Who may contact a customer. What may be promised. Which data may be used. What the team may not build. How a stop is announced so the people who worked on it are not punished for a good kill. These rules are short. A policy that needs a workshop of its own is a sign the programme is trying to boil the ocean.

Governance that fits on one page

A steering committee that meets monthly to "note progress" will turn every bet into a status report. Replace the note with a decision. Each bet arrives with the hypothesis, the test, the result and a recommendation to stop, change or pay for the next test. The committee's job is to accept or refuse that recommendation. If it asks for a thicker pack instead, it has chosen delay.

Keep a single register. Bet, owner, sponsor, assumption under test, evidence so far, next decision date, and whether the bet is live, changed or stopped. The register is dull on purpose. Dull is inspectable. A showcase video is not. Anyone in the organisation who asks what the programme has done should be able to read the register without a narrator.

Funding should arrive in slices that match the evidence. A small slice to run the test. A further slice only if the test earned it. The annual plan can still exist. It should not be the only moment money can move, or the only moment money can be taken back. A budget that cleared before anyone wanted the offer is a different problem, and it is a common one. The programme is there to stop that sequence becoming the default.

A worked illustration, not a client story

Picture a retail bank in Sydney. The illustration is a composite, so the mechanism is visible. It is not a report of a named client. A product team wants to waive a fee for a narrow group of customers who call about hardship. The theme in the strategy pack is "care". The bet is sharper: a defined group will complete a short check online, and the contact centre will not be flooded by people outside the group.

In a programme with a sponsor, the team writes that sentence down and names the riskiest hope. The hope is not the screen. The hope is that the people who should use the check can be recognised without a new data project, and that everyone else will not treat the page as an open offer. The test is a page shown only to a small list, with a human still making the waiver decision. The kill rule is agreed before the page goes up. If the wrong people arrive, or the right people cannot finish, the offer stops and the team reports that plainly.

In a programme without that rule, the same team builds a fuller journey because the screen is what they can show. The contact centre hears about it when the calls start. Risk hears about it when someone screenshots the page. The sponsor, who liked "care", is now defending a thing they did not know had launched. The method did not fail. It was never given a decision to attach itself to.

A cadence a sponsor can defend

The cadence is a sequence, not a promise of days. Collective Campus agrees the length after a scoping call. The sequence itself is stable, because the decisions are stable. Skip a step and the later step becomes theatre.

Name the bet

The team writes who it is for, what would change for them, and why the organisation should care if that were true. The sponsor edits the sentence until they would be willing to say it in their own meeting. If they will not say it, the team is working on a private hobby. Stop there. A bet the sponsor will not repeat has no path through the building.

Find the risk

The room lists what must be true and marks each line as known or hoped. The riskiest hope is the one that would make the bet pointless if it were false, and that the room cannot yet prove. This is usually slower than brainstorming and more useful. People discover they have been arguing about a feature when the open question was whether anyone had the problem.

Design the test

The test is the smallest move that could change the sponsor's mind. It names the people who will see it, the behaviour that counts, the window, and the line between stop, change and continue. It also names what the team will not build. A test with no exclusions becomes a pilot, and a pilot with no end becomes a product that nobody chose.

Run it where the customer already is

Some tests can be finished in the room. Most of the learning happens after, with the people who were named. The programme's job is to make that next step ordinary: a date, an owner, and permission to contact those people. A beautiful plan that waits for "when we have capacity" will wait out the quarter. Put the first contact in the calendar before the team leaves.

Decide in public

The sponsor says stop, change or continue, against the rule they signed. The team records what was learned in sentences a later team can use, including the result that killed a hope. A stop is a success when it was the honest reading. Treating a stop as a failure teaches the next cohort to hide bad news inside a longer pilot.

Then the register updates and the next bet, or the next test of the same bet, is booked. A programme with one climax and no second decision is a campaign. Campaigns end. The capability you wanted was the second decision, made by people who now know what evidence looks like.

How a real programme differs from theatre

Theatre has a look. Posters, lanyards, a pitch night, a prize, a video of people laughing at a whiteboard. None of those are sins. They become a problem when they replace the decision. Steve Blank has described how large companies strangle new ideas by forcing a search to wear the clothes of the existing business. The clothes in this case are the showcase. The search needed a test and a stop line.

You can hear theatre in the success measures. Number of ideas. Number of attendees. Number of teams "activated". A social post. A mural. Ask instead how many bets stopped, how many changed because a customer did something unexpected, and how many continued with a named next test and a named owner. If the first list is long and the second is empty, the programme is a communications exercise.

Theatre also hides in language. "Explore the art of the possible." "Create a movement." "Unlock innovation." These sentences cannot be false, so they cannot teach. Replace them with the bet, the assumption and the result. The room will feel plainer. Plain is what a chief financial officer can defend, and what a frontline manager can repeat.

A worked illustration, not a client story

Picture a state agency team in Brisbane. Again, this is an illustration, not a named engagement. The team has been asked to "be more innovative" about permits. They run a day, produce forty ideas, vote with dots, and announce three winners. The winners become a slide in the quarterly pack. Six months later the permit form is the same, because nobody was allowed to change it, and nobody tested whether residents were failing at the step the winners assumed.

The same team in a programme writes one bet. Residents abandon the form at a named question. The assumption is that the question is unclear, not that people refuse the permit itself. The test is a rewritten question, tried with a small set of real applications, with the old question still available. The sponsor is the person who owns the form. If completion does not move, the team stops rewriting and goes to look at the rule behind the question. The dots never get a vote. The applications do.

What the public write-ups already show

Collective Campus does not invent clients for a programme story. The engagements below are the ones already written up on the work pages. They are not all intrapreneurship programmes in the full sense. Several are a single day or two that taught the method on live work. They matter because they show what startup methods look like inside organisations that already have customers, rules and a brand. Read them as evidence of the moves, not as a promise that every future room will copy the format.

The AGL retail session was a full day of lean startup training for people from the retail team. It covered where the method comes from, why it matters, the lean canvas, how to find and rank assumptions and prototypes, customer acquisition, validation boards, metrics that lead to an action, how the method sits in a company, and how to ask an executive for the room to use it. People left with a working understanding and with techniques for the internal roadblocks. The public write-up records that the feedback was exceedingly positive. It does not invent a product that launched the following week, and this article will not invent one either.

MetLife asked a harder question than a training day. The work was to test appetite for an idea: the customer, the problem, the offer, the features and the business model, and to come out with a go, a no, or a pivot. Collective Campus built hundreds of ads and prototypes, including landing pages, and read the analytics. MetLife pivoted on that evidence. The public account says the pivot saved the time and money of building out an expensive business case on untested assumptions. Staff were in the work, and the contrast the write-up draws is the one that matters for a programme: many small bets driven by customers, rather than a few large bets driven only by senior opinion.

Sportsbet put people with no startup background, drawn from across the organisation for a project, through a one-day workshop. The day ran from problems and offers, through a model, assumptions, experiments, prototypes, customer tests, metrics, a pitch and a pivot-or-proceed call. The write-up says people left with an appreciation of building, measuring and learning quickly, with a sense of what it means to prototype in a day, and with the harder lesson that the first assumption is often wrong, so ego has to sit down. A programme tries to make that lesson a habit, not a memory of a single day.

NPS MedicineWise brought a cross-functional group to a one-day course on rapid prototyping, including lean startup, so the organisation could reach market evidence sooner and be more careful about what it built. More than thirty people took part. The public account lists the kinds of tools in the room, from interface sketches to analytics, and says people left with a method, a basic grasp of the tools, and reference material for later. The point recorded is the avoidance of spending early on the wrong product or feature. That is a programme outcome even when the container was a single day.

Standard Chartered asked for a half-day crash course for selected people in its Hong Kong team, so those people could champion the method afterwards, including inside a large regulated financial services organisation. The write-up says the session was well received. It does not claim a portfolio of bets. Championing is a real job, and it fails if the champions go home to a building that has no kill rule. Training the guides is not a substitute for the sponsor's sentence.

Water Corporation in Perth wanted its product and innovation team to be able to apply lean startup inside a regulated public body. The two-day workshop covered how to do that in a large organisation with public duties, what public-sector examples showed, and how to move faster without pretending the duties had vanished. The team left, on the public account, able to see the next steps on work it already had. A public body does not get a free pass from evidence, and it does not get to copy a startup's risk. The method is the same shape with a tighter fence.

Australian Unity is the closest of these write-ups to a short intrapreneurship programme. Twenty people from across the organisation spent two days learning the canvas, the assumptions, the metrics and the prototypes, then tested private health insurance ideas with customers. They ran more than twenty-six experiments, online and in person, on four ideas. The experiments included social ads, Google ads, landing pages and interviews in the Melbourne CBD. Two ideas gathered enough for an internal business case. Two were invalidated, and the teams were told to reconsider before going further. The write-up also records the cultural point: people felt, in their own hands, the cost of building something customers had not asked for.

Inkeros is a different shape and a different country, and it belongs here only as a boundary. The public write-up describes a Canadian company, founded in 2001, with more than six hundred employees across Canada and the United States. The team had too many plausible directions in AI-assisted hiring. A two-day lean design sprint in Toronto, with serious pre-work, ended in one evidence-backed direction the group had built together, plus follow-on tooling to measure impact. It is not an Australian intrapreneurship programme. It is a reminder that the enemy is often a pile of plausible directions, and that convergence is a result.

Where a sprint sits inside the programme

A programme is the system. A sprint is one room inside it, used when a team already has a live bet and needs the assumption, the test and the decision pulled into the open. The lean startup and product sprint is that room. Innovation and product teams, and the sponsor who can fund or stop the work, stay until the call is made. The wider practice, including design, customer experience and the way people work, sits on the capability building page. AI is one part of that practice. It is not a separate identity, and it is not a reason to skip the customer.

Use the sprint when the bet is real and the organisation is about to spend. Use the programme when you need that decision to happen more than once, with more than one team, without importing a new set of facilitators every time. The sprint teaches the moves on live work. The programme is the calendar, the register, the kill rule and the sponsor's habit of showing up.

Do not use either as a reward for people who already agree with each other. A room of enthusiasts will produce a polished hope. Put a sceptic from operations, a person from risk, and the sponsor who has to say no in the same half-day as the people who love the idea. The argument you want is the one that would otherwise happen in a corridor after the money has moved.

What Collective Campus will not pretend

We will not sell a fixed public price, a fixed headcount or a fixed number of days as if every organisation were the same shape. The scoping call is where that is settled. We will not dress capability building up as a search for a label. Buyers look for intrapreneurship, and for startup methods inside a company. The work is still the team's skill: framing a problem, testing it, and deciding.

We will not claim a result a write-up does not contain. If a page says the feedback was positive, that is the claim. If a page says the organisation pivoted, that is the claim. A programme designed from those lessons should copy the discipline, not a fictional trophy.

Failure modes that look like progress

The first failure is too many bets. A cohort of fifteen ideas feels fair and produces fifteen thin tests, none of which a sponsor can read. Cut until each bet has an owner who can say the assumption without looking down. A smaller cohort that finishes is a better advertisement than a large one that dissolves.

The second failure is a pilot with no end. The team "learns" by keeping the pilot open, adding features, and calling the additions insight. A pilot needs the same kill rule as a landing page. If the rule cannot be applied because taking the pilot down would embarrass someone, the programme has already lost. Embarrassment is cheaper before the build.

The third failure is teaching the method on a canned case. People get good at the case. The next real bet has a different customer, a different rule and a different politics. Practise on a live bet the sponsor cares about, or accept that you have run a class, not a programme. A class can be worth booking. Do not count it as intrapreneurship.

The fourth failure is punishing the stop. If the only stories told at the end of the year are the ones that continued, the next team will bend the metric. Tell the stop with the same respect as the continue. Name what the organisation did not spend. That is a result a finance partner can recognise.

The fifth failure is handing the programme to a team that cannot touch the work. A centre of specialists who are not allowed to change a form, a script or a price will produce recommendations. Recommendations are not tests. Put at least one person on each bet who can alter the thing the customer touches, even if the alteration is temporary and small.

Questions to settle before you announce it

Who is the sponsor for the programme itself, not only for a single bet, and what will they stop defending if the register says the bets are weak. A programme sponsor who needs a success story by a fixed date will lean on the teams to continue. Say that risk out loud.

Which customers, staff or residents may be contacted, under what consent, and with what promise. If the answer is "none, until legal has a month", design the first tests around evidence you can already touch: existing call data, a shadowed shift, a paper prototype in a real meeting. Do not announce customer experiments you are not allowed to run.

What the programme will refuse. Ideas that are really a request for headcount. Ideas that need a rule change the organisation has already declined. Ideas whose only measure is internal applause. A refusal list is a gift to the people doing intake. Without it, every no feels personal.

How the second cycle starts. The date, the owner of the register, and the meeting where stops are read out. If that meeting is not in the calendar, you have planned a launch, not a programme. Launches are easy to photograph. Programmes are easy to audit.

What good looks like after one cycle

After one cycle, a stranger should be able to read the register and see which bets stopped, which changed, and which earned another test. The people who ran the tests should be able to name the assumption they got wrong. The sponsor should be able to repeat the kill rule without a slide. Managers of the people involved should be able to say the time was real, because the work moved or it stopped, and either outcome was allowed.

You should also see a quieter sign. The next idea that arrives comes with a customer and a doubt, not only with enthusiasm. Someone says "we should test the switch before we fund the build" without being prompted. That sentence is the capability. The cohort was only the excuse to practise it.

Australian organisations already know how to run a project. The project machinery assumes the answer is known and the task is delivery. Intrapreneurship is for the stretch where the answer is not known, and delivery would be a way of hiding that. Keep the project machinery for the bets that have earned it. Keep the programme for the search. Mixing them too early is how a hope gets a Gantt chart.

A last illustration, then the decision

Picture a water business in Melbourne. Composite again, not a client report. The strategy day produced a theme about customers using less water in summer peaks. Three teams leave with concepts and a shared slide. In a programme, one team is allowed to proceed, and only with a bet: a named suburb will shift a named chore, such as garden watering, if the message arrives the day before a hot spell and the action takes less than a minute. The test uses a channel the organisation already has. The measure is the behaviour, not the open rate. The sponsor owns the demand forecast and has said what shift would matter. If the behaviour does not move, the concept stops and the other two themes do not inherit a free pass.

That is a smaller story than a summit. It is also a story a board can follow. The organisation did not claim to have changed the city. It claimed to have found out, cheaply, whether a specific hope was true. The people who ran it can run the next one. That is the programme.

If you are about to announce something like it, write the sponsor's stop line before you write the invitation. Then pick one live bet in Sydney, Melbourne, Brisbane, or wherever the work actually sits, and put that bet through the sequence. The invitation can wait until the first decision has been made in public. A programme that starts with a decision is much harder to turn into a poster.

WorkshopBook the Lean Startup and Product Sprint workshop