I have a strong opinion about MVPs, and I will say it upfront: most founders are building products, not MVPs.
I have reviewed briefs from founders who call their project an MVP but have listed 60 screens, three user types, a mobile app and a web platform, payment processing, push notifications, an admin panel and five third-party integrations. That is not a Minimum Viable Product. That is a full product with an optimistic label attached to keep the budget conversation comfortable.
The consequence is predictable. They spend $60,000 to $100,000 building everything they imagined. They launch. Users are confused by a product that tries to do too much. The one thing it was supposed to do brilliantly gets lost in the noise. And then they come to me — or someone like me — to figure out why it is not working.
I have built 150+ digital products for founders in the US, UK, Canada, Australia and India. The products that succeeded almost always had one thing in common at the start: ruthless focus. The ones that struggled almost always had the opposite.
Here is the framework I use to help founders build an MVP that actually tests something — without wasting money finding out it was the wrong thing.
Step 1: Define the problem, not the product
Most founders come to me with a product idea. Very few come with a problem statement. That is the first thing I fix.
A product idea sounds like: "I want to build an app that connects pet owners with local vets and allows them to book appointments, store medical records and get reminders for vaccinations."
A problem statement sounds like: "Pet owners in urban areas struggle to find available vets quickly when their pet is sick, and often end up at emergency clinics that cost three times more."
The difference matters enormously. The product idea describes a feature list. The problem statement describes a pain. If you start with the feature list, you build all the features. If you start with the pain, you ask: what is the minimum thing that relieves this pain well enough for someone to pay for it?
One question I ask every founder before we start: if this product did not exist tomorrow, who would actually notice? And what would they lose? The more specific and honest the answer, the clearer the MVP becomes.
Step 2: Identify one specific user — not a target market
"The app is for small business owners" is not a user. It is a demographic.
Small business owners in retail work completely differently from small business owners in construction. A 25-year-old first-time founder has completely different habits and expectations from a 50-year-old who has been running a business for 20 years.
Every time you add a user type to your MVP, you are multiplying the complexity. Different onboarding flows. Different dashboards. Different notification logic. Different admin controls. A product for two user types is not twice as complex as a product for one — in my experience, it is three to four times more complex.
For your MVP, pick one user. Give them a name. Describe their day. What do they do in the morning? What frustrates them? What does a good day look like for them? When you can answer those questions, you can build a product that genuinely helps that one person. And if you can help one person extremely well, you can find more people like them.
Step 3: Define the one core flow
Every product has one flow that is the reason it exists. For Uber in its earliest days, that flow was: open app, request car, car arrives. Everything else — ratings, payment history, driver profiles — came later.
Your MVP should have one flow that works brilliantly. Not five flows that work adequately.
The exercise I do with every founder is this: walk me through the moment your user gets value from this product. Not the signup, not the settings, not the account management — the moment they actually get the thing they came for. Describe that in detail. That description is your core flow. Everything outside of it is phase two.
When founders push back and say "but users will need this feature to get there," I ask them to keep going: do they actually need it for the first version, or would they survive without it for 90 days while we validate the core? Almost always, the honest answer is that they would survive.
Step 4: Validate before you build — seriously
This is the step most founders skip. And it is the step that would save most of them their biggest mistakes.
Before you spend a rupee on development, talk to ten people who represent your target user. Not your friends. Not your family. People who have the problem you are trying to solve and would potentially pay someone to solve it.
Do not tell them about your product. Ask them about the problem. Ask them how they currently deal with it. Ask them what it costs them — in time, money or frustration. Ask them whether they have tried to find a solution.
If ten real people describe the problem the way you understand it, confirm that it is genuinely painful, and ask where they can sign up — you have something worth building. If they look confused or say "it is not really a problem for me," you have learned something that would have cost you $50,000 to learn the hard way.
The LeSociety team in Canada came to us after doing this validation work. They had already spoken to potential users, understood the problem deeply, and knew exactly what the first version needed to prove. We built it in 11 weeks. It worked. That is not a coincidence.
Step 5: Build the minimum — and mean it
Once you have done the first four steps honestly, the question of what to build becomes much clearer. It is everything that supports the core flow, and nothing else.
This is where I sometimes have a hard conversation with founders. They want features in the MVP that are genuinely useful but not essential for validating the core hypothesis. I push back on them.
Not because I want a smaller project — I want a successful one. A bloated MVP takes longer to build, costs more money, and is harder to learn from. When 20 features ship at once and the product does not perform as expected, you do not know which feature caused the problem. When 5 features ship and the product does not perform, you have a much clearer path to finding out why.
My rule: if removing a feature does not break the core flow for your target user, it is not in the MVP. Put it in a document called "Phase 2" and revisit it when you have real user feedback.
One more thing I have learned from building 150+ products: the feature founders fight hardest to include in the MVP is almost never the one that matters most to users. Users will surprise you. Build the minimum, ship it, and let the surprise happen.
What this looks like in practice
We worked with a founder on a platform for managing construction contractors in California. Their original brief had end-to-end project management, AI tools, satellite communication features and an admin dashboard.
We talked them into starting with one flow: a contractor receives a job, accepts it, and updates the status. That is it. No AI. No satellite. No complex admin.
That version cost a fraction of what the full product would have. They shipped it to a small group of contractors. They got feedback. Some features they had planned to build turned out not to matter to users. One feature they had never thought of came up in almost every conversation.
The product they have now — which is considerably more sophisticated — was built on a foundation of real user feedback instead of assumptions. Every feature in it was added because real users asked for it, not because someone imagined they might want it.
That is how you build an MVP without wasting money. Not by building less — by building the right thing first.