There are two videos that completely changed how I think about MVPs. The first one is my all-time favourite - it's 8 minutes and incredibly clear:
Watch: Making sense of MVP (Minimum Viable Product)
https://www.youtube.com/watch?v=0P7nCmln7PM
The key insight: MVP isn't about building a bad version of your product. It's about learning what matters before you build the real thing.
We had a quality control process running on paper. Operators would take dimensional measurements of products periodically throughout production. Supervisors would review these measurements, looking for issues.
It was painful and slow. Problems would surface hours after they occurred. The paper forms would stack up. Supervisors spent their time chasing down measurements instead of addressing issues.
We needed something better. The instinct was to design the complete solution - proper database, real-time dashboards, automated alerts, the works.
Instead, we started with Google Forms and Sheets.
Operators could enter measurements on tablets. Supervisors could see the data immediately instead of waiting for paper forms. It improved the speed of information significantly.
It wasn't scalable. We had to manually archive the data at the end of each shift. But it proved something critical: real-time visibility mattered more than we'd realised.
This was a deliberate trade-off. We could have spent weeks getting a proper database set up. Instead, we delivered value early and learned what actually mattered to the people using the system.
Once we understood that real-time data was valuable, we built the next version: Power Apps frontend with a SQL backend. This was scalable. We could handle the data volume properly. We learned how the data should be structured.
Then we added Power BI reporting on top of it. Visualisations that made patterns visible. And Power Automate notifications - if specific failures occurred, supervisors got alerts in real-time via email or Teams.
Three iterations. Each one taught us something we couldn't have known from planning:
If we'd tried to build the "complete" solution first, we'd have got the priorities wrong. We'd have focused on data storage and reporting before proving that real-time visibility was the actual problem to solve.
The second video uses the Wizard of Oz to explain a different type of MVP - one where you can validate that people want a feature before you build any of the actual technology. Manual processes behind the curtain while the user sees a working system.
Watch: Making sense of MVP - Wizard of Oz explanation
https://www.youtube.com/watch?v=VPVec5eupTY
This isn't about being lazy or cutting corners. It's about being smart with our effort. Building things people actually need, not things we think they need.
I'm applying this right now with a customer onboarding form.
The instinct was to build it properly from the start: database to store applications, internal portal for review workflow, draft saving, document uploads, digital signatures, status tracking.
Instead, we're building a Wizard of Oz MVP:
What the user sees: Professional form with validation, smooth authentication flow, clean interface.
What's actually happening behind the curtain: It emails a PDF.
That's it. No database. No review portal. No complex workflow. Just a form that collects information, validates it, and sends a PDF via email.
What we're learning:
Once we validate that the basic workflow works and people actually use it, then we'll build the database, the review portal, the draft saving, the document uploads.
But we're not building any of that until we know the core concept works.
The quality control system wouldn't exist if we'd tried to design it perfectly first. We'd still be planning the database schema while people filled out paper forms.
This customer onboarding form would be the same - we'd be building complex infrastructure before proving anyone wants to fill out the form.
Instead: build something that looks real but uses simple processes behind the scenes. Learn from it. Then build the real thing.
The quality control system worked because we committed to iteration. Google Forms first, then Power Apps, then Power BI. Each step taught us what the next step should be.
The customer onboarding form is working because we're deliberately starting simple. Email a PDF first, build the infrastructure later.
But I still catch myself designing the complete solution first on other projects.
Last week I was spec'ing out a reporting tool. I spent two days mapping out the database schema, the API structure, the caching strategy, the visualisation options. All before writing a single line of code or showing anything to the people who'd actually use it.
I could have built a basic version with static data in a few hours. Put it in front of users. Learned what reports they actually needed versus what I thought they needed.
Instead, I was planning the perfect architecture for a problem I didn't fully understand yet.
The concepts are simple. Google Forms before Power Apps. Email PDF before database. Static data before dynamic architecture.
But the instinct to plan everything first is hard to override. Especially when you know how to build things properly. It feels irresponsible to ship something "incomplete" even when that incompleteness is the entire point.
I'm getting better at recognising when I'm over-planning. Sometimes I catch myself mid-spec and pivot to "what's the smallest thing I can build right now?" Sometimes I waste a few days first.
The quality control system took three iterations over a couple of months. I want to get to the point where I default to that approach rather than fighting my instinct every time.
Not there yet.
Watch the videos: