How to Run Sprint Demos as a Non-Technical Founder

Seven questions to ask. A 30-minute meeting structure that works. The difference between useful feedback and accidental scope creep. Written for founders who do not know what to ask.

Why Non-Technical Founders Need This

The sprint demo is the primary mechanism by which non-technical founders maintain control of a software build. Every 2 weeks, the team shows you what they have built. You give feedback. You approve or redirect. The next sprint starts.

But if you do not know what to ask in a demo, you nod through working software you do not really understand — and discover three sprints later that the team built something different from what you imagined. This guide gives you the seven questions and the meeting structure that prevent that drift. No technical knowledge required.

A note on Devi: Devi is a composite character drawn from patterns we have observed across hundreds of founder-led builds. The sprint demo struggles, learnings, and recovery described here reflect real scenarios — compressed into a single narrative.

Devi's First Sprint Demo: 12 Minutes of Silent Nodding

The Seven Questions to Ask in Every Sprint Demo

Memorise these. Bring them to every demo. They work regardless of your technical background.

1 "Can you show me this from a real user's perspective?"

If the team is showing you architecture diagrams, code, or admin dashboards — redirect to the user-facing experience. You are not approving code quality (that is what testing and code review are for). You are approving whether the product serves the user.

What you are looking for: Working software on a real device, running through real user paths. Not slides. Not screenshots. Not "imagine if the user did this."

2 "What did you have to assume to build this?"

Every implementation decision involves assumptions the scope document did not explicitly cover. Devi's team assumed single-driver operations. Hana's team assumed all users were in AEST. This question surfaces invisible decisions before they compound.

What you are looking for: Specific assumptions like "we assumed the user wants weekly summaries, not daily" or "we assumed addresses are always Australian format." Then validate each assumption against your actual users.

3 "What happens when this breaks?"

Every feature has failure modes — bad inputs, network timeouts, third-party API outages. Ask: what does the user see when the payment fails? When the upload times out? When the GPS does not connect?

What you are looking for: Concrete error handling, not "we will handle that later." If the team has not thought about failure modes, the feature is not done — it is half done.

4 "How did you test this?"

"It works on my machine" is not testing. "We have automated tests for the critical paths and manually tested on iPhone 12, iPhone 15 Pro, and Pixel 7" is testing. Ask specifically.

What you are looking for: Specific test devices, edge cases tested, and any known issues documented. The PRR checklist turns this into 50 specific test categories.

5 "Can I try this myself on my phone?"

Demos on the developer's screen always look smoother than real-world usage. Ask for a TestFlight or Play Store internal build on your own device. Tap with your own thumbs. Watch yourself get confused.

What you are looking for: Issues only visible in your actual usage — touch targets too small for your thumb, scroll behaviours that feel wrong on your network speed, anything the developer is unconsciously compensating for.

6 "What's the biggest risk for the next sprint?"

Good teams know where the risks are. They have already identified that the payment integration might be tricky, or that the third-party API has rate limits, or that the offline mode requires significant logic changes. Ask before they start.

What you are looking for: Honest risk acknowledgment, not "everything is on track." A team that says "no risks" either has not thought hard enough or is not telling you the truth.

7 "Is there anything you need from me before the next sprint?"

The team often needs decisions, sample data, customer access, or content from you to keep moving. Ask explicitly. Founders who do not respond to dependency requests for 4-5 days become the bottleneck — and then blame the team for slow delivery.

What you are looking for: A concrete list of items, ideally with deadlines. "We need the privacy policy text by Wednesday" is actionable. "We might need some stuff" is not.

Print these seven questions. Keep them on a sticky note next to your laptop. Ask all seven, every demo, even when you feel awkward asking. According to Atlassian's research on agile sprint reviews, teams with active product owner participation in sprint demos ship 1.5-2x more features at lower rework rates than teams with passive participation. Your questions are the mechanism. Asking is the work.

The 30-Minute Sprint Demo Structure

Use this as your default agenda. Adjust as needed.

Why 30 minutes: Long enough for substantive review, short enough that everyone stays engaged. Demos longer than 60 minutes consistently produce diminishing returns — the team starts performing, the founder starts disengaging, and decisions become rubber-stamping. If you genuinely need more time, schedule a separate working session rather than extending the demo. Marcus's week-by-week build process uses this exact 30-minute structure across 8 sprints.

Feedback vs. Scope Creep: The Distinction That Matters

Devi's second mistake was the opposite of the first. After the multi-driver disaster in Sprint 1, she over-corrected — peppering every subsequent demo with intense questions, suggestions, and "small ideas."

The 'just one small thing' trap. Every individual small thing seems harmless. The cumulative effect is project failure. According to PMI research on project failure, scope creep affects 52% of projects globally and is the second-largest cause of project failure after inadequate requirements. The change request process exists to make scope additions visible, priced, and approved — not to be bureaucratic.

Built to Last™ — P04: The Right Delivery. Sprint demos are the operational expression of P04. They are how you maintain control of a software build without writing code. The seven questions, the 30-minute structure, and the feedback-vs-scope-creep distinction are the mechanisms that turn agile delivery from theory into practice. Marcus's week-by-week build demonstrates P04 in action across 8 sprints.

Five Common Sprint Demo Mistakes (And How to Avoid Them)

Your Sprint Demo Cheatsheet (Print This)

Before the Demo

• Review the sprint goal from your last demo notes

• Install the TestFlight or Play Store internal build on your phone
• Block 45 minutes (30 demo + 15 buffer)
• Have the 7 questions visible (sticky note or open document)

During the Demo — Ask These Seven Questions

• "Can you show me this from a real user's perspective?"

• "What did you have to assume to build this?"
• "What happens when this breaks?"
• "How did you test this?"
• "Can I try this myself on my phone?"
• "What's the biggest risk for the next sprint?"
• "Is there anything you need from me before the next sprint?"

After the Demo

• Send a written approval (or specific concerns) within 24 hours

• Submit any change requests you decided to formalise
• Provide any dependencies the team flagged (content, decisions, sample data)
• Add notes to your sprint demo log — you will need them for the next demo

Founder FAQ

The Founder's Edge

Devi ran 8 sprint demos. The first cost her $18K because she said nothing. Sprints 2-4 cost her $11K because she said too much without structure. By sprint 5, she had the seven questions, the 30-minute agenda, and the feedback-vs-change-request distinction. The remaining demos delivered the build on schedule and within scope.

The sprint demo is the most important meeting in your software build. Treat it that way. Print the seven questions. Ask all of them, every time, even when it feels awkward. The cost of asking is 20 minutes. The cost of not asking is $18K — and sometimes the project.