IV. Building your MVP | The 10x Method
Deliver 1% of your ultimate vision, but 80% of its core value
We’re currently publishing a new chapter of The 10x Method every week, our sold-out book detailing Hexa’s early-stage methodology that built 50+ companies, 3 of which are unicorns. You can unsubscribe from future drops here.
This chapter is about scoping, building, and iterating your Minimum Viable Product (MVP), the first version of your product that lets you test your core hypothesis in the real world. The goal isn’t to build something polished or complete. The goal is to launch fast, get it in front of users, and learn as much as possible.
Many founders fall into a common trap: building too much, too soon. It’s tempting to perfect every feature, but most of them won’t matter or won’t even be used. Worse, you risk missing your moment: by the time you launch, the market might have shifted or your solution may no longer fit the problem.
At Hexa, we believe you should ship your MVP within weeks, not months. In this chapter, we’ll show you how to scope tightly, build quickly, and iterate with design partners.
A note: this chapter was originally written in 2025. Since then, tools like Cursor and Lovable have compressed the path from idea to working product from weeks to days. These tools are incredibly useful, but it also makes it easier than ever to overbuild. Arguably, the principles in this chapter matter more now than ever.
Scope small but think long-term
Every great product starts with a vision, a clear idea of the impact it will have. But too often, founders get lost in execution and forget to ask: what are we ultimately building?
Your MVP isn’t the final product, it’s the first step. It’s not about cramming in features but proving your vision.
Start with your long-term vision
Before diving into building your MVP, take a step back and define your long- term vision. What are you ultimately trying to achieve with this product? Your MVP is just the first step in making that vision a reality, the way to test your core hypothesis, not the finished product.
Think long-term. You’re not just building for today; you’re laying the foundation for something bigger.
Once your vision is clear, ask yourself: What’s the first step toward achieving it? This first step should deliver enough value for users to engage with your product and use it regularly. It should solve one fundamental problem. Rather than trying to do everything at once, focus on perfecting your core use case, the one that provides the most value to users right now.
Your MVP = the first step toward your vision
Your MVP may only represent 1% of your ultimate vision, but it should deliver 80% of the core value.
Examples of long-term visions and MVPs
Below are the initial long-term visions of these companies. It’s important to remember that long-term visions often evolve, they’re not set in stone. Just like Aircall, Spendesk, and Front, most startups adjust their vision as the market shifts. While your vision shouldn’t change every week or quarter, it’s still a hypothesis - one that needs to be tested and refined over time.
Aircall
Long-term vision: A modern cloud-based phone system that integrates seamlessly with business tools (CRM, helpdesk, etc.).
MVP: A simple VoIP solution that allows businesses to set up a cloud-based phone number in minutes. The first version had basic call routing and a web- based dialer, no deep CRM integrations, analytics, or call center automation.
Spendesk
Long-term vision: An all-in-one spend management platform that replaces corporate credit cards, expense reports, and manual approval processes.
MVP: A virtual card solution for employees to request and manage company spending. The first version had basic expense tracking and approval work- flows, no complex reporting, invoice management, or budgeting features.
Front
Long-term vision: Reinvent email for teams, making shared inboxes more collaborative and efficient.
MVP: A shared inbox for customer support teams that allowed multiple people to manage emails together. The first version had basic email assignment, internal comments, and tagging, no deep integrations, analytics, or automation.
Launch your MVP in weeks, not months
You might wonder: Why scope small? Why not deliver an MVP that includes the first two steps of your long-term vision? Why be so ruthless about delivering the smallest MVP with the biggest impact?
There’s one reason, and one reason only: you need to ship fast. The sooner you get your product into the hands of users, the sooner you’ll know if your first step truly delivers value. Scoping small allows you to launch quickly, gather real-world feedback, and validate whether you’re on the right track. No internal discussion or assumption can replace the insights gained from real user interactions.
The goal is simple: get it in front of users in a matter of weeks, not months. You’ll learn 10x more from real usage than from endless internal debates.
Plus, speed is everything in startups. One of the most common mistakes founders make is spending six months or more perfecting an MVP before launching. That’s the wrong approach. In a startup, speed is your greatest advantage. Speed means getting real feedback before you’ve invested too much time in the wrong direction. It means staying ahead of competitors, maintaining urgency within your team, and proving your ability to execute.
But there’s an important caveat: not all B2B software MVPs can be launched in a matter of weeks. While many can, and arguably should, some industries make that timeline unrealistic. Highly regulated sectors like fintech often require long lead times. For example, Swan had to wait 18 months to obtain its e-money license before launching. In other cases, the nature of the product demands a longer build cycle. If you’re entering a mature category with high user expectations (like email, calendar apps, CRMs, or ERPs) you may need to build for months before reaching the level of polish and value users expect. These are categories where the bar is already high. That was the case for us at Folk, and similarly for Front.
“Sometimes a single feature is enough to carve out your wedge in the market and create real value. Some of the best MVPs didn’t try to do everything; they focused on doing one thing exceptionally well. As the saying goes, it’s better to be small and excellent at what you do. A strong MVP isn’t about ticking every box, it’s about identifying one or two features that are so valuable that users come for them, and stay because of them. Some companies have outperformed their competitors 10x by perfecting a single key feature. Take PostMark, for example: their email parsing API was significantly better than anything else available. That one feature alone was so useful that it kept users loyal, even when they had reasons to churn as competitors like Mailjet were also offering the feature at a way cheaper price.”
– Quentin Nickmans, Partner and Cofounder at Hexa
“To ship an MVP quickly, the key is to leverage what you already know. Stick to the stack you’re comfortable with but don’t over-optimize. Speed matters more than perfection at this stage. The goal is to deliver value fast while still laying the right foundations. That’s the mindset we follow at Dotfile. Be ready to let go when something doesn’t work. I’ve been through that myself: we scrapped about 80% of our codebase (twice) be- fore landing on something that truly delivered. And above all, stay driven by the business. Building productivity tools is fun, sure, but in the end, it all has to serve a real business need.”
– Titouan Benoit, CTO and Cofounder of Dotfile
A common failing of founders
One of the biggest mistakes founders make is skipping the scrappy MVP and instead spending time crafting a polished prototype that reflects their long-term vision. They show this prototype to potential users, hoping for validation.
Users do not react to a prototype the same way they do to a real, functional product. A prototype invites opinions, but a working product triggers real behavior. If you rely on feedback from a non-functional prototype, you risk making decisions based on theoretical reactions rather than actual usage.
It’s best to skip the theoretical stage. Instead, build a minimal but functional MVP, something people can truly use. Only then will you gather real insights, understand how users interact with your product, and iterate in the right direction.
“Staying in the realm of theory and imagination for too long is like asking someone to assess a steel hammer by using a cardboard version, get an MVP in their hands as soon as possible so they can evaluate the real functionality”
– Thibaud Elziere, Partner and Cofounder of Hexa
The hammer allegory
As a founder, it’s tempting to wait until your product matches your full vision before sharing it with users. You imagine launching something beautiful and complete - a product that truly reflects your ambition. But you can’t deliver that perfect version yet. You don’t have enough feedback or iteration behind it. And ironically, the only way to get there is by putting something far less perfect in users’ hands today.
Let’s take the example of a hammer as a product.
Imagine someone trying to drive a nail into a piece of wood using just a rock. It’s clumsy and frustrating. You immediately picture the solution: a hammer. That’s your long-term vision.
But here’s the reality: you can’t hand them the final hammer today. You don’t yet know what the handle should be made of, what weight the head should be, or how it feels in actual use. So instead, you have to start smaller.
Day 1: You hand over a cardboard prototype. It resembles a hammer, but it’s useless in action. It bends. It fails. It leaves you with no insights and them with no progress.
Day 2: You build something crude but real: a stick with a rock tied to one end. That’s your first step to reach your long-term vision. Yes it’s ugly and unpolished. But it’s better than the rock alone. They use it and it works, barely, but now they’re engaged. “Can this be longer?” “It needs to be heavier.” Suddenly, they’re helping you build the hammer.
That’s the point: early, imperfect tools generate real feedback. Real usage reveals real needs. Every rough edge is a learning opportunity you wouldn’t get from polish alone.
You can’t ship the hammer today, but you can ship something usable. Not to validate the final product, but to start discovering what it actually needs to become.
It’s not about lowering the bar, it’s about laying the foundation. The only way to build the hammer is to first hand someone a better rock.
Your wireframes should be ugly
When founders start working on their MVP, there’s a natural tendency to overcomplicate, to add more features, more customization, more flexibility. But in reality, complexity dilutes value. The best products in the world share one common trait, they are deceptively simple. Slack, Notion, Figma, all of them took complex ideas and distilled them into an intuitive, frictionless experience.
But here’s the catch: to build simple products, you have to start simple. And that begins with low-fidelity wireframes.
Starting with low-fidelity wireframes is crucial because it allows you to:
Iterate fast
Wireframes are quick and cheap to modify. If an idea doesn’t work, you can sketch a new version in minutes rather than reworking high-fidelity designs or code.
Simplify your MVP
Most MVPs start with too much. You should be aggressive about removing features. Cut everything in half: half the buttons, half the options, half the tabs. Low-fidelity wireframing keeps things scrappy and ensures you can cut it all out.
Save time & resources
Designing in high fidelity (detailed UI, colors, animations) takes significantly more time. If you need to make changes later (which you will), it’s much easier to adjust a wireframe than to rework a polished design or rewrite code. This reduces wasted effort.
Collaborate with your team
Low-fidelity wireframes are easy for everyone to contribute to, whether they’re designers, developers, or product managers. Since they’re not overly polished, team members feel more comfortable suggesting changes and iterating together.
Reduce your bias toward aesthetics
When something looks finished, people hesitate to challenge it. With low-fidelity wireframes, stakeholders focus on functionality and flow, rather than prematurely debating colors, typography, or UI details.
Top tip: Use Blocks.pm for low-fidelity wireframes.
Hexa created a Figma plug-in to create low-fidelity wireframes as a team. It has tens of blocks ready to go, for you to move around and edit as you need.
Spendesk’s early wireframe - made on Blocks
Your MVP building checklist
Aligns with your long-term vision – It should be a stepping stone toward your ultimate goal, not a random experiment.
Can be developed in weeks, not months – If it takes too long, you’re over- building.
Is a real product and not a polished prototype - The only way to get mea- ningful insights
Delivers enough value to onboard real users – Even in its simplest form, it must solve a real problem.
Is minimal enough to allow for quick iteration – No unnecessary complexity that slows future changes.
If your MVP plan doesn’t check all these, you’re overbuilding.
Think in milestones, not roadmaps
Make your planning flexible
When you’re building a startup, long, detailed roadmaps can be more of a burden than a guide. Plans change and rigid timelines can slow you down instead of helping you move forward.
At Hexa, we believe in momentum over meticulous planning. Instead of a complex roadmap, focus on short, achievable goals that drive real progress and bring you closer to your long-term vision.
Forget the Gantt charts, the multi-quarter planning, and the overly detailed feature breakdowns.
Your roadmap should be a simple table. Here’s a suggested template:
“Forget perfect plans, momentum is your greatest asset. In startups, progress comes from shipping fast, not mapping everything out. Because for every 10 features you launch, only one might stick.”
– Seraphie de Tracy, CEO and Cofounder of Cohort
Here’s an example of a roadmap we have for an internal project called LegalX:
Product rituals
Even if you’re just one or two founders, establishing a clear rhythm for product discussions, prioritization, and execution will keep you moving efficiently. The key is consistency. These rituals help you maintain focus, iterate faster, and ensure that small, incremental progress compounds over time.
Here’s what early stage product routines should look like:
1. Weekly product committees
Cadence: Every week, same time.
Duration: 30 minutes to one hour (keep it fast and focused).
Who’s involved: Everyone working on the product (even if that’s just you).
What happens?
Review what was shipped: every feature, bug fix, or improvement from the past week should be demoed (even if it’s rough).
Refine priorities for the upcoming week: what’s the one most important thing to focus on next?
Address blockers: anything slowing you down?
Why it works:
Establishes a consistent cadence for execution.
Prevents features from getting stuck in endless iterations.
Forces you to ship, because you have to demo something every week. Keeps the team aligned to achieve quarterly milestones.
“Every Friday, we dedicate one hour to our sprint review and sprint planning. We look at what we accomplished during the week and plan what’s next. But more importantly, it’s a moment to show off progress. Even if it’s just a subtle UI change, the addition of a single field, or a minor feature that improves the experience in a tiny way, the point is to always demonstrate forward progress. That regular habit of showing, even in small increments, is what creates a culture centered on continuous delivery and value creation.
At Dotfile, this mindset has been embedded in our DNA from the very beginning. We’ve stayed relentlessly focused on shipping value and especially in the early stages, and made it a priority to communicate those updates regularly to our users.”
– Titouan Benoit, CTO and Cofounder of Dotfile
2. Quarterly milestone planning
Cadence: Every 3 months.
Duration: 1-2 hours.
Who’s involved: Founders, product team, and key stakeholders.
What happens?
Define big product milestones for the next quarter.
Align on the core problem to solve and major initiatives.
Set clear execution goals that break down into weekly sprints.
Discuss what’s working and what needs to change in the product approach.
Why it works:
Prevents you from getting lost in day-to-day execution. Keeps you on track to achieving your long-term vision. Helps you track progress and adjust course if needed.
It’s easy to think that formal processes like these aren’t necessary in the early days. “We’re small, we talk all the time anyway.”
But without a structured cadence, things can quickly become chaotic:
You lose track of priorities.
You keep iterating endlessly instead of shipping.
You don’t reflect on what’s working and what’s not.
By locking in these rituals early, you create a strong execution rhythm that scales as your team grows. They also make it easier to stay agile and pivot if necessary, because you’re constantly reflecting and refining.
Your goal:
Think in 3-month cycles: plan quarterly milestones. Execute in weekly sprints: ship and adjust every week.
How to validate early PMF
Why design partners matter
Launching your MVP is just the beginning, the real challenge is proving your product truly adds value to users.
At Hexa, we initially relied on pilots (beta testers) for early-stage product testing. However, we’ve since switched to working with Design Partners (DPs), an approach that transforms early users into active co-builders of our products. In Chapter VI, we’ll go much deeper into how to run Design Partner programs. For now, here’s a quick introduction to why they’re so valuable at the MVP stage.
Our old pilot programs gave early, free access to users, often with little commitment. If they liked it, great. If not, we moved on. However, this passive approach rarely provided clear signals that we were moving toward product-market fit.
A Design Partner Program changes that. Instead of simply testing usability, design partners actively co-build the product with you, ensuring it solves a real problem within a real workflow. This approach requires more effort and commitment from both sides, but the value it delivers is enormous.
Beyond gathering feedback, a Design Partner Program serves as an early validation of PMF. We emphasize the “early validation” part because achieving true PMF won’t happen in the first 12 months. On average, B2B products take over two years to reach PMF.
But a design partner program allows you to test whether users truly need your product, not just whether they find it interesting. If you struggle to find committed design partners, it’s an indication that your product might not yet address a strong enough pain point. Conversely, if companies are eager to participate and actively shape the product, it’s a signal that you are onto something valuable.
Pilots vs. DP program
Co-creating with DPs
We’ll deep dive into how to find design partners in the dedicated chapter on how to acquire your first users later in this book. For now, here are some pointers on how to best engage them.
A Design Partner Program isn’t just about collecting feedback, it’s about embedding users into your product development process. Here’s how to do it effectively:
Daily conversations with users
Regular check-ins help you gauge if your product is truly solving their problem. Design partners should feel like they are part of the team, and their input should influence your roadmap.
Iterate with every prototype
Instead of waiting for big launches, share each iteration early and often. Every version should be tested by design partners to validate the changes before broader deployment.
Observe real behavior
Actions speak louder than words. Don’t just rely on verbal feedback, watch how users interact with the product to uncover friction points and unexpected use cases. Watching users interact with your product often reveals insights they can’t articulate in interviews.
Create a dedicated space for collaboration
Use a Slack channel or private forum where design partners can:
Share thoughts and feedback in real-time
Stay updated on product changes
Feel engaged as co-creators
Asking the right questions
To make the most of your design partners, ask open-ended and practical questions:
“What problem were you trying to solve when you used this product?”
“How are you currently solving this problem without our product?”
“What would make this 10x better for you?”
Good questions should:
Be open-ended - Avoid yes/no answers; let users elaborate.
Be short & direct - Simple questions like “Why?” or “How?” drive deeper insights.
Prompt demonstrations - Ask users to show how they interact with the product, as behavior often differs from what they say.
Analyzing user behavior
Once feedback starts coming in, it’s essential to dig into usage patterns:
What features are used most often?
Where do users drop off or struggle?
Are there surprising use cases we didn’t anticipate?
This analysis will highlight what’s working, what’s not, and where to focus improvements.
Managing feedback without losing focus
With so much feedback flowing in, there’s a temptation to add every feature request. But blindly saying yes leads to a bloated and unfocused product. Instead, filter feedback carefully:
If users say “this isn’t good enough yet”, it’s a sign they see potential.
Prioritize feedback that aligns with your long-term vision
Store all feedback in one place, every suggestion should be considered, even if it’s implemented later.
“Users know their problems, not the solutions. Your job is to define what to build. Instead of asking for features, ask about their goals and observe their behavior. They ask for “better” not “different.” Use their requests for incremental improvements, but don’t rely on them for breakthrough innovation. Great product teams use feedback to improve product quality. They don’t rely on fancy prioritization scores or frameworks like RICE but instead leverage deep customer empathy, and strong product vision. Bottom line: Don’t just ship what users ask for. Listen, understand their needs, and prioritize based on real impact, not arbitrary scores.”
– Mehdi Boudoukhane, CEO and Cofounder of Cycle
“The real challenge with user feedback is knowing that 90% of what you hear will either be irrelevant or too obvious... The gold is in the remaining 10% — those little ‘aha’ moments where users aren’t directly asking for something, but they’re pointing you toward a deeper need.”
– Christophe Pasquier, CEO and Cofounder of Slite
I launched my MVP, now what?
Focus on one metric
When you get started it’s tempting to measure every corner of your product. The most successful teams use a “focus” metric, a metric that can only move when your business grows in a healthy way. Once you have a focus metric you can use it as a compass to justify your decisions and to try and understand if you’re on the way to product-market-fit or not. This doesn’t mean you should focus on just one metric (tracking several is valuable) but it’s important to have a single north star to guide your decisions.
For B2B software, a focus metric can be one of the below:
Customer retention rate
The % of users returning after a set period. Retention is everything for early-stage startups. A strong retention rate signals that your product delivers ongoing value. If retention is low, if your design partners are dropping off, then it’s a red flag.
Monthly recurring revenue (MRR) growth
We’ll cover the specifics of this in the acquiring clients chapter. MRR is another key metric to focus on in the early stages. In fact, monetizing your MVP early can be one of the strongest signals of product-market fit. When design partners are willing to pay even for a minimal product, it’s a very positive indicator for the future.
Active users
Whether that’s daily/weekly activation rates, tracking active users is crucial because it directly reflects engagement and product stickiness, helping you gauge whether users find real value in your product. Unlike vanity metrics like total sign-ups, active users show how many people consistently return and interact with your product. A growing and retained active user base signals that you’re moving toward PMF.
But don’t spend too much time on it either
Yes, tracking one of the above metrics is important but do not spend excessive time tracking everything. Early-stage product development should be driven by conviction and qualitative feedback, not excessive data analysis. Talking to users is far more valuable than getting lost in dashboards. Instead of obsessing over metrics, focus on:
Building a product you would like to use*
Observing user behavior through session recordings
Talking to users, everyday
Using the above analytics to validate, not dictate, decisions
*while this may seem to conflict with solving users’ problems, it’s crucial because you’re ultimately the judge of quality. If you don’t believe in your product, how can you expect others to?
Should I pivot?
It’s a big question and one where the framework we introduced in Chapter
II becomes especially useful. As we discussed, a strong startup idea is built on three core components: a problem, a solution, and a GTM strategy. When considering whether to pivot, revisit each of these elements. If any one of them falters (if the problem isn’t painful enough, the solution doesn’t resonate, or the GTM strategy isn’t delivering) then a pivot may be the right move.
One important thing to keep in mind, and why the startup idea framework is so useful, is that you might be solving a meaningful problem with a solution users truly love, yet still struggle because your GTM strategy doesn’t scale or your business model doesn’t capture enough value. That was the case with Collective, who pivoted post-seed, from a hybrid SaaS/service model to a social network-style platform for freelancers.
Insight from Simo Lemhandez, CEO & Cofounder of Folk
Early on, we used a mix of qualitative and quantitative metrics:
1. Qualitative metrics:
We ran surveys like “How disappointed would you be if you could no longer use the product?” (from Superhuman), and standard tools like NPS. These gave us early insights into user satisfaction and perceived value.
2. Engagement metrics:
We tracked usage ratios like:
WAU/MAU (Weekly Active Users over Monthly Active Users)
DAU/MAU (Daily Active Users over Monthly Active Users)
The underlying assumption here is: the more intensely and frequently people use a product, the more valuable they perceive it to be.
Of course, this depends on the product category. For example, with a tool like PayFit (HR/payroll), the goal is to use it as little as possible. But for productivity tools like Folk, high usage is a good proxy for value.
3. Talking to users:
This is often underrated, but it was critical for us. We had frequent conversa- tions with users to gather qualitative feedback. Are they satisfied? Frustrated? What pain points are they raising?
One thing I found particularly insightful was the idea that you should aim to create “love” for your product and not neutrality.
Surprisingly, the best way to get there was often to start with users who were frustrated or even a bit angry. Because if they care enough to complain, they see the product’s potential.
The real danger is users who are indifferent, who just don’t care, which means you’re not solving an important problem for them.
In fact, we found it easier to turn “haters” into champions than to convert lukewarm users (like a 5/10 or 6/10) into true fans (9/10). The hate-love spec- trum is useful, because hate shows there’s something worth fixing. Indifference, not hate, is the true enemy of product-market fit.
Insight from Paul Vidal, CTO and Cofounder of Collective
Pivot stories are extremely valuable and we don’t have enough of them, especially in Europe. Too often, we only hear about startups that had a straight, smooth trajectory. But the reality is different: many companies pivot, struggle, adapt, and eventually succeed.
Our initial business was actually doing quite well. By the end of 2024, when we started considering the pivot, we were on track to generate €1M revenue when we started thinking about the pivot. Many companies would have been happy with that.
But we realized two things:
1. We were building a very operational, service-heavy business. Scaling from €1 million to €10 million would have been slow, costly, and painful.
2. Beyond €10 million, the growth path became even less clear, it wasn’t an exponential model.
We had raised €8 million, but our revenues weren’t scaling as fast as we expected. Our business model was a hybrid of services and tech, which made it even harder. Service businesses require aggressive cost management, while tech companies require heavy R&D investment. Doing both at once was stretching us thin.
And so we pivoted toward a bigger opportunity.
We knew the freelance space extremely well after three years. We had deep insights, strong relationships, and brand recognition among freelancers and companies. We realized there was a gap in the market for better software tools, ones we wished we had when we started.
So instead of continuing to grow a service business slowly, we decided to build the software product we ourselves would have loved to use.