How a Product Market Sprint works.
One day, one small business, one working prototype. Here's the whole thing, start to finish: what happens, why it's structured this way, and what everyone takes home.
The problem
Good builders and good problems rarely meet.
Australia has thousands of small businesses running on duct tape: quoting from spreadsheets, rostering by text message, chasing invoices by hand. And it has a growing community of builders who can stand up working software in a day with AI tools.
The two almost never find each other. Agencies are priced for enterprises. Off-the-shelf software solves the average problem, not yours. And builders practising their craft end up making demo apps for imaginary users instead of products for people who'd use them on Monday.
A Product Market Sprint closes that gap with a format both sides can trust: the business brings a problem that hurts, builders bring their tools, and the day ends with something working: handed over, documented, published.
The format
One day. Small teams. A live demo before dinner.
Each sprint pairs three to five small businesses with teams of builders. Every team gets one problem, one business owner on call, and a hard 5pm demo. The format is deliberately repeatable (same stages, same rhythm, every sprint) so builders know the drill and businesses know what they're getting.
Sunrise to demo
Doors at 8am, demos at 5pm. The deadline is the feature.
For everyone attending
Sponsor-funded. Businesses pay nothing; builders pay nothing.
Businesses per sprint
Each with a dedicated team and a problem worth a day.
Published
Every sprint becomes a written case study: what worked, what didn't.
The Sprint Method
Five stages, in order, every time.
The method is the product. It's what makes a one-day build trustworthy instead of a gamble: each stage exists to stop a specific failure mode.
Prime 8:00 – 9:00
Builders meet the business owner before anyone opens a laptop. What does the business do, where does the day go, what's been tried already? Prime exists because the most common failure in software-for-small-business is solving the wrong problem confidently.
Frame 9:00 – 10:30
The team scopes the one thing worth building today and cuts everything else. The output is a single sentence the business owner agrees with: "By 5pm you'll be able to ___." Frame is where the 5E framework does its work:
The 5E framework
How a team goes from a messy story to a buildable scopeSit with the owner in their workflow; watch the spreadsheet open.
Map the problem space wide before narrowing. List every pain, not the first one.
Play the problem back in the owner's words until they say "yes, that's it".
Sketch the smallest version that would change Monday morning.
Agree how the demo will be judged before a line of code exists.
Build 10:30 – 16:00
Heads down. Teams build with whatever AI tooling they're strongest in; the sprint is tool-agnostic by design. The business owner stays reachable for the questions that always come up ("what do you call this field?", "who approves that?"). Working beats perfect; shipped beats both.
Demo 16:00 – 17:00
Every team demos the working thing to the business owner, live: real data, no slides, in front of the room. The owner drives it themselves before the day ends. If it only works in the builder's head, it didn't happen.
Ship 17:00 onwards
The prototype leaves with the business: code, accounts, and a plain-language handover note. Then the sprint gets written up and published: the problem, the scope, the build, the result. The writing is what turns one good day into a public record.
Outcomes
What everyone walks away with.
- A shipped prototype with a real user, not a portfolio mock
- A published case study with their name on it
- A bench of peers who've seen them work under a deadline
- A working tool aimed at their most annoying problem, free
- Full ownership: code, accounts, and a plain-language handover
- A clear-eyed read on what AI can and can't do for them yet
- Their tools in the hands of the builders most likely to champion them
- A published record of what got built on their stack
- Standing with a community that ships, not just attends
Questions
The things people ask.
What does it cost?+
Nothing, for builders or businesses. Sprints are sponsor-funded: sponsors cover the venue, food, and tooling credits. That's the whole model.
Do I need to be an experienced developer to build?+
You need to have shipped something with AI tools: a side project counts, a job title doesn't. Teams are mixed deliberately, so first-time sprinters sit alongside people who've done several.
What kinds of problems suit a sprint?+
Anything specific and painful: quoting that takes hours, rosters managed by text, double-entered invoices, booking requests living in a personal inbox. If you can show us where the time goes, it's probably a fit. "We need an app" is too big; "I retype every order into MYOB" is perfect.
What happens to the prototype afterwards?+
It's yours. Code, accounts, and a handover note leave with the business on the day. Some businesses keep running the prototype as-is; some hire a builder to take it further; some learn the idea doesn't hold up, which is also worth a day.
Is my business information kept private?+
The case study is written with you, not about you. You approve what's published, and anything commercially sensitive stays out. Most owners choose to be named; some don't, and that's fine.
Where do sprints run?+
Sydney, for now. Each sprint's venue is announced with the event. If you want to bring the format to another city, get in touch: the method travels.