Your MVP Doesn't Need 6 Months: The Skateboard Rule for Building Products

The Word Everyone Uses and Almost Nobody Understands

I've lost count of how many times I've heard the word "MVP" used to describe a product that has 47 features, a six-month timeline, and a budget north of $100K.

That's not an MVP. That's a product. A bloated one, usually.

The term has been stretched so far from its original meaning that it's become a permission slip for founders to build everything they want while calling it "minimum." The logic goes: we'll just build a "smaller" version of the full vision. But smaller still means three dashboards, two user types, a payment integration, a notification system, and an admin panel. That's not minimum anything.

I wrote about this problem a couple of years ago, and the core argument hasn't changed - but the landscape around it has shifted dramatically. The tools available now have made it possible to validate a product idea faster and cheaper than at any point in the history of software. And yet, founders are still burning months and capital building things nobody asked for.

"An MVP is not a lite version of the full product. It's the smallest, most useful thing you can launch that actually helps someone."

MVP Is a Mindset, Not a Feature List

Here's the reframe that changes everything: stop thinking of an MVP as a product spec. Start thinking of it as a mindset.

The mindset of solving a core problem - in increasingly evolved ways as your product grows.

You identify a problem. You work on a solution. Whatever solves the problem in its simplest form becomes your MVP. Not whatever matches the competitor's feature set. Not whatever fills the pitch deck slides. Whatever actually solves the problem for a real person.

The classic skateboard analogy captures this perfectly. You don't build a car by first building a chassis with no wheels. You build a skateboard. It's crude, it's basic, but it gets someone from A to B. Then you evolve - scooter, bicycle, motorcycle, car. Each version solves the same core problem, just in an increasingly sophisticated way.

A lot of founders think of an MVP as an "incomplete" version of the real product. That framing is the root of the problem. An MVP isn't incomplete - it's intentionally focused. It exists to validate, not to impress. To learn, not to launch.

The distinction matters even more now because building has gotten dramatically easier. When building was hard and slow, you could argue that you might as well build more while you're at it. That argument doesn't hold anymore. When you can prototype in days, there's no excuse for spending months building features you haven't validated.

What Makes a Problem Worth Building an MVP For

Before you write a line of code - before you even open Figma - you need to pressure-test the problem itself. Not every problem is worth solving, and not every problem worth solving is worth solving right now, by you, with the resources you have.

A good MVP problem passes three filters:

It's impacting real people at meaningful scale. Not "I think this might be annoying for some people." Actual pain, experienced by a group large enough to sustain a business. If you can't find forums, communities, or conversations where people are complaining about this problem, it might not be a problem worth solving.

It's feasible to address with what you have. Not what you'll have after your Series A. Not what you'll have when you hire three more engineers. What you have now - your current budget, your current team, your current tools. If the smallest version of the solution still requires six figures and six months, the problem might be right but the timing might be wrong.

It's focused enough to own. Niches build businesses. Solving "communication" is a feature. Solving "async standup updates for remote engineering teams under 20 people" is a product. The tighter your problem definition, the faster you can build something that actually resonates.

And one more that doesn't get talked about enough: do you actually care about this problem? Not "do you see a market opportunity." Do you care enough to spend the next 2-3 years grinding on it when things get hard? Because they will get hard. If your motivation is purely financial, the first plateau will break you.

This is exactly the kind of thinking that happens in a proper product discovery process. Discovery isn't a tax on your timeline - it's how you avoid building the wrong skateboard.

AI Changed What "Rapid Prototyping" Actually Means

Two years ago, "rapid prototyping" meant a design sprint, some wireframes, maybe a clickable Figma prototype. It was faster than building the real thing, but it still took weeks and still required specialized skills.

With AI, rapid prototyping means something fundamentally different.

A single developer working with AI coding tools can build a functional prototype - not a mockup, a working application - in days. Not because the code is magic, but because the grunt work that used to consume 80% of development time has been compressed. Boilerplate, CRUD operations, standard UI components, API integrations, database schemas - all of this can be generated, reviewed, and refined in a fraction of the time it used to take.

This changes the MVP equation in three critical ways:

The cost of being wrong dropped to nearly zero. When a prototype takes four weeks and costs $6,000 instead of three months and $50,000, you can afford to be wrong. You can build the skateboard, show it to ten users, learn it's the wrong skateboard, and build a different one - all within the timeline and budget that used to produce one "MVP" you were stuck with.

Validation happens with working software, not slides. You don't need to convince users to imagine what your product would feel like. You can put a working version in their hands. The feedback you get from someone using a real tool is categorically different from the feedback you get from someone looking at a wireframe. They stop being polite and start being honest.

The gap between prototype and production shrank. A well-built prototype with clean architecture can evolve into the production MVP without a full rewrite. The throwaway prototype era is ending. With the right approach, your validation tool and your launched product can share a codebase.

We covered this in depth in our piece on why small teams now outperform large agencies - the combination of AI tools, focused expertise, and lean process means a trio of product manager, engineer, and designer can ship what a 15-person team used to deliver. And for MVP-stage work, even that might be more than you need.

"When prototyping takes days instead of months, the only excuse for building the wrong thing is not talking to users."

The Two Routes Founders Keep Ignoring

Most founders default to "build the app" as their first move. But the best MVPs now often don't start with code at all.

Route 1: Start with a community.

If the problem you're solving is real, there are people experiencing it right now. Find them. Or create the space for them. A newsletter, a Discord, a LinkedIn community, a Substack - whatever fits your audience.

Talk about the problem. Raise awareness. Get 100 people who care about this problem before you build a single feature. Those 100 people become your design partners, your first beta testers, your first paying customers, and your most valuable source of product feedback.

Building a community first and building within that community is the most underrated MVP strategy available. It costs almost nothing, it validates demand before you spend a dollar on development, and it gives you a distribution channel from day one.

Route 2: Be the product before you build the product.

Know how to solve the problem yourself? Then solve it manually first. Become the service before you build the software.

A lot of successful SaaS companies started as service businesses. They solved the problem by hand, learned every edge case, understood what customers actually valued (versus what they said they valued), and then automated the parts that made sense to automate.

This approach is especially powerful if it's your first product. You learn the domain deeply. You build revenue. You fund the product development from the service income. And when you do build, you're building from real operational knowledge - not assumptions.

Paul Graham's advice to "do things that don't scale" is nearly a decade old now. It's never been more relevant. AI tools make the scaling part easier than ever - but no tool can replace the insight you get from doing the work manually first.

The 6-Month MVP Is a Symptom of Skipping Discovery

Here's the pattern I see constantly. A founder has an idea. They skip discovery. They go straight to an agency or a dev team and say "build this." The team, because they're paid to build, starts building. Nobody stops to ask whether this is the right thing to build, in the right sequence, for the right user.

Three months in, the founder realizes the core user flow doesn't make sense. Features get added to compensate. The timeline extends. The budget inflates. What started as an "MVP" becomes a six-month project with a growing feature list and a shrinking runway.

This is the most expensive mistake in early-stage product development. And it's entirely preventable.

At Biz of Dev, every engagement starts with a Discovery Sprint - not because we want to add a phase, but because we've seen what happens when you skip it. Discovery defines the problem, identifies the target user, maps the competitive landscape, and produces an execution plan with explicit scope boundaries. It answers the question every MVP should start with: what is the smallest thing we can build that validates the core thesis?

The output isn't a massive requirements document. It's a focused, build-ready blueprint that any team can execute - including us, but also including any other capable team. There's no vendor lock-in, no proprietary framework, no dependency on Biz of Dev to make sense of the plan.

When discovery is done right, the MVP timeline compresses naturally. Not because you're cutting corners, but because you've eliminated the features that shouldn't be there in the first place. The skateboard has two fewer wheels than you thought it needed - and it still rolls.

"A 6-month MVP is almost never a scope problem. It's a discovery problem."

Common MVP Mistakes That Haven't Gone Away

AI tools made building faster. They didn't make thinking faster. The same MVP mistakes that killed products five years ago are still killing them today - just more efficiently.

Feature stuffing. "While we're building the core feature, let's also add..." is the most dangerous sentence in product development. Every feature you add to an MVP is a feature you have to maintain, test, explain to users, and eventually decide whether to keep. The MVP's job is to validate one hypothesis. One.

Building in isolation. If you're three months into development and haven't shown the product to a single potential user, you're not building an MVP. You're building a guess. User feedback isn't something you collect after launch - it's something you build into the process from week one.

Skipping the feedback loop. You shipped the skateboard. Ten people tried it. Three of them gave you feedback. And you ignored it because it contradicted your vision. This defeats the entire purpose. An MVP without a feedback loop is just a small product with no growth path.

Solving problems you assume people have. You think onboarding is the pain point. Users think billing is the pain point. You won't know until you ask - and asking means identifying real user requirements, not projecting your assumptions onto them.

Confusing an MVP with a prototype. A prototype is a clickable demo to test ideas - not production-ready, not built for real use. An MVP is a working product with minimal features that solves the core problem in production. Both are valuable. They serve different purposes. Know which one you need first.

The Biz of Dev Take

Every now and then, someone reaches out to us with a "simple MVP" that turns out to be a 40-feature product roadmap disguised as a starting point. When we push back and ask what the actual core problem is, the conversation gets uncomfortable. That discomfort is the work.

The MVP conversation has never been about technology. It's always been about discipline - the discipline to identify what matters most and build only that. The discipline to show something unfinished to real users and listen to what they say. The discipline to resist the urge to add "just one more feature" before launch.

What's changed now is the speed at which you can exercise that discipline. AI tools compress the build cycle. Small, focused teams eliminate coordination overhead. Discovery sprints replace months of wandering with weeks of structured thinking. The infrastructure exists to go from validated problem to working skateboard in 30 days - if you have the discipline to keep it focused.

The founders who win aren't the ones who build the most. They're the ones who learn the fastest. And learning fast means shipping small, listening hard, and iterating with purpose.

Your MVP is not your product. It's your first question to the market. Make it a good question - and make it fast.

"Building is cheap now. Knowing what to build is the expensive part. That's why discovery exists."

Ship the Skateboard, Learn, Then Build the Car

The MVP playbook is simpler than it's ever been. Define a focused problem. Validate it with a community or a service model before writing code. Use AI tools and a small team to build a working prototype in days, not months. Put it in front of real users immediately. Listen to what they tell you - especially when it contradicts what you expected. Iterate.

The six-month MVP is a relic of an era when building was hard and expensive. Building is neither of those things anymore. The hard part - the part that separates products that work from products that don't - is knowing what to build in the first place.

Start with the skateboard. It's ugly, it's basic, and it might fall apart. But it rolls. And rolling beats planning every single time.