the pragmatic sprint

Stop reading about product management. Build something.

I say this in every cohort, usually around week 10, when students have consumed enough frameworks and case studies to fill a textbook — and have shipped exactly nothing. The anxiety is always the same: “I don’t know enough yet.” “My idea isn’t good enough.” “I need to do more user research first.”

No. You need to ship. The first thing you ship will be bad. That is the point. You learn more from one bad product in production than from a year of reading about good products in theory.

The Pragmatic Sprint is the framework I built to force this. One week. Seven days. From a blank page to a product that real users can touch. Not a deck. Not a Figma file. Not a PRD that sits in Confluence. A product.

Over eight years, I have watched hundreds of PMs and aspiring PMs go through this sprint. The ones who finish it — even with a rough, ugly, barely-functional output — are categorically different from the ones who do not. They have shipped. That changes everything about how they think, how they interview, and how they work.

Why one week

We used to give students a month to build their MVP. It was too long. They spent three weeks debating features and one week panicking. The output was no better than what a focused week produces.

POC building — proof of concept — should not take more than a week. You are going to use it and throw it away. The point is not to build something permanent. The point is to learn whether the problem you think exists actually exists, whether the solution you imagined actually works, and whether anyone cares.

One week forces you to make decisions. You cannot research for three days when you only have seven. You cannot build five features when you barely have time for one. The constraint is the value.

The three pillars

The Pragmatic Sprint runs on three principles. If you remember nothing else from this page, remember these.

Accelerated. Speed is the strategy, not a compromise. Condensing what typically takes months into one focused week eliminates the single biggest product killer: overthinking. You do not have time to fall in love with your idea. You barely have time to test it. That is the point.

Adaptable. No two product journeys are the same. The daily structure is a guide, not a mandate. If you are a first-timer, follow every step — you do not yet know what to skip. If you have built before, skip what you already know and spend more time where you are weakest.

Achievable. The goal is not a polished product. The goal is a working proof of concept that a real user can interact with. Lower the bar for what “done” means. Raise the bar for actually finishing.

The seven days

Here is the daily structure. Each day has a morning focus and an afternoon focus. Mornings are for thinking and planning. Afternoons are for building and validating.

Day 1 — Problem and validation. Morning: define the problem using a Lean Canvas. One page. Do not overcomplicate it. The problem statement should be one sentence that a stranger can understand. Afternoon: talk to five people who have the problem. Not friends — strangers. Use a Google Form if you must, but a phone call is better. You are checking one thing: does this problem actually exist outside your head?

Day 2 — User and value. Morning: define your value proposition. What does your product do that nothing else does? Write it in one sentence. Then define your MVP features — the absolute minimum set that delivers that value. Three features maximum. Afternoon: build a user persona and map the customer journey. Not a 20-slide deck. One page each.

Day 3 — Business model and prototype. Morning: fill out a Business Model Canvas. Who pays? How much? Through what channel? Afternoon: assess technical feasibility and start a low-fidelity prototype. If you can code, use whatever stack you know. If you cannot code, use a no-code tool — Bubble, Glide, Carrd, Softr. The tool does not matter. Shipping matters.

Day 4 — Build and test. Full day of prototyping. Get to a state where someone can click through the core flow. By end of day, put it in front of two people who are not you. Watch them use it. Do not explain anything. Write down where they get confused.

Day 5 — Iterate and plan. Morning: fix the top three problems from yesterday’s testing. Do not fix everything — fix the things that prevented users from completing the core flow. Afternoon: write a development roadmap (what comes after this week) and a launch plan (who sees this first, how do you get it to them).

Day 6-7 — Ship. Finalize. Internal testing. Fix critical bugs only — do not add features. Execute a soft launch to a small audience: 20-50 people who have the problem. Collect feedback. You are live.

Post-sprint. Analyse feedback. Decide: iterate, pivot, or kill. All three are valid outcomes. The sprint succeeded regardless of which one you choose, because you now have data instead of assumptions.

What the sprint is not

It is not a hackathon. Hackathons reward clever demos. The Pragmatic Sprint rewards learning. A hackathon project dies on Monday. A sprint project has a roadmap for week two.

It is not a design sprint. The Google Ventures design sprint is five days of discovery and prototyping — no code, no launch. The Pragmatic Sprint includes prototyping AND a real launch. You are not testing a concept. You are testing a product.

It is not a shortcut to product-market fit. One week does not give you PMF. It gives you the first data point on the road to PMF. The sprint validates whether the problem is real and whether your approach has any signal. That is all — and that is more than most founders have after three months.

Who should do this

Aspiring PMs who have never shipped. This is the single fastest way to build a portfolio piece that is not a teardown or a hypothetical PRD. Interviewers can tell the difference between “I designed a feature on paper” and “I built and shipped a product that 30 people used.” The sprint gives you the second one.

PMs transitioning from large companies to startups. If you have spent five years at a company where shipping means six months of planning, two months of development, and a month of QA — the sprint recalibrates your sense of what is possible. You can ship in a week. You just need permission to be bad at it.

Founders who are stuck in ideation. If you have been “working on your idea” for more than a month without putting anything in front of a user, the sprint is an intervention. The idea is not getting better in your head. It is getting worse — accumulating assumptions that only contact with reality can test.

The mistakes I see every cohort

After hundreds of sprints, the failure patterns are consistent.

Spending Day 1-3 on research and Day 4-7 panicking. The sprint front-loads thinking and back-loads building for a reason. If you are still researching on Day 4, you have already failed the sprint. Research without a time box expands to fill all available time. The sprint gives you exactly two days. Use them.

Building features instead of the core flow. A student once spent Day 4-5 building a notification system for a task management app. The core flow — creating and completing a task — did not work. Notifications for a broken product is not a feature. It is a distraction.

Refusing to show imperfect work. The students who hide their prototype until it is “ready” never finish. The ones who show a broken version on Day 3 get feedback that saves them two days of wrong-direction building. Embarrassment is a cost. Wasted time is a bigger cost.

Treating the sprint as a solo exercise. The sprint is designed for a solo PM or a tiny team. But “solo” does not mean “isolated.” You need testers, you need feedback, and you need someone to tell you when your idea does not make sense. Find a sprint partner — even if they are just watching over your shoulder.

After the sprint

The sprint ends on Day 7. What you do in the next two weeks determines whether it was a learning exercise or the start of something real.

If users came back without being asked — you have signal. Not product-market fit. Signal. Double down. Fix the top three complaints. Add the one feature every tester asked for. Get to 100 users.

If users tried it once and did not return — diagnose why. Was the problem not painful enough? Was the solution too clunky? Was the distribution wrong (you reached the wrong people)? Each answer points to a different next step.

If nobody cared — that is also a result. You spent one week learning that this problem or this audience or this approach does not work. A founder who learns that in one week is ahead of a founder who learns it in six months.

The sprint is repeatable. The best students in our cohorts run two or three sprints before they find something with signal. Each sprint takes a week. The total investment is three weeks — less time than most people spend writing a business plan that nobody reads.

Where to go next

• Understand what happens before the sprint: Zero to One — finding the idea worth sprinting on
• Know when the sprint output has real signal: Product-Market Fit — the PMF signals to watch for
• Scale what works: Scaling Your Product — what changes after PMF
• Build the business model around it: Business Model Thinking — turning a prototype into a business