The problem is that many first-time clients do not understand how to approach the conversation of building an MVP with an external partner. Do you need to prepare anything beforehand? Should you hire the team first? Do you need a fully-formed business plan first?

This ‘chicken or the egg’ conundrum can lead to a very messy meeting if not addressed beforehand. And it’s no one’s fault. Software development is not a clean or straightforward process. Our goal is to make the first MVP meeting as meaningful, time-efficient, and full of clarity as possible, especially for newcomers.

At Polcode, our mission is to turn your vision into a business through our expertise in technology. To do that expertly, the first MVP conversation should be focused around tackling assumptions, and clearly communicating expectations. The better we manage assumptions during the first meeting, the sooner we can get to building out your vision.

With that in mind, here’s how to ace your first MVP meeting when outsourcing product development to a software house.

Let’s Review What An MVP Does Best

No doubt that you’ve already read about the Minimum Viable Product—the first barebones version of your software. This YCombinator article best sums up how MVPs are a process, rather than an actual product. An MVP process works best when it reflects on your riskiest assumption, and finds the smallest experiment to test that assumption.

Managing assumptions here is the key word. Even the term ‘product’ can be extremely misleading—people assume different things about what a product should be. There are other variations of the MVP model too. For example, the Minimum Lovable Product (MLP) seeks to create an experience that users love from the start. It disregards cold, robotic efficiency or ‘getting the job done’ (e.g. making a purchase online) and focuses on creating some kind of experience that users adore (e.g. shopping lazily with vibrant images). The assumption of an MLP is that your first version needs to kick off a powerful experience, rather than sets of features that may, or may not be loved by the audience.

Then there’s the Minimum Marketable Product (MMP), which represents a product ready to be marketed to your audience. A minimum marketable product focuses on fast time-to-market, without over-engineering anything. It values quick turnaround times and bringing value immediately to a specific audience, without caring too much about perfection.

As you can see, even within the realms of MVP development, there are core assumptions that need to be defined well before moving forward. We’ll tackle that during the first meeting, which brings me to the next point: What exactly should you prepare before the call or meeting?

Prepare For Your First MVP Meeting

You have a meeting planned with a software house like Polcode. But what’s so special about the first MVP project meeting anyway?

It’s partially true that you, as a client, don’t really need to prepare anything before the meeting. We act as the bridge between your business ideas and realizing the technology solutions behind them. If you have a good idea for a business, but aren’t sure where to go from there, we’re happy to jump off from that point.

But let’s back up for a moment and look at why communicating efficiently with an outsourced IT partner is so important.

The landscape of building digital products has changed over the last decade. IT service-delivery worldwide has shifted largely to outsourcing to a 92.5bn USD market. Companies both small and gargantuan have moved the bulk of their IT services to third-party partners, due to pressures of software engineer shortages or rising costs of hiring developers in-house.

Chances are good that you’ll be working with an external software house at some point to develop your digital product. It is a far different experience from managing your own team, or hiring a bunch of freelance programmers. Instead, you’re getting a whole team with technology expertise who can bring your vision from concept to reality. When you first plan an MVP with us, the following concepts will be extremely important in how much value the meeting creates.

Quick Pre-meeting MVP Checklist

1. Bring your vision to the table. You should be able to describe the short and long-term vision for your idea, and what success would look like at early, middle and late stages.
2. Take a business-oriented role. You’re a key stakeholder and know more about your industry, market, trends and competitors than we do. It’s great if you have a preplanned business model or business plan ready (more on that later). You don’t need to know anything about technology, but be clear about what you want to build, and why it matters to the world.
3. Consider the people involved. Who are your competitors? Who are your most loyal customers or potential customer segments for the MVP? Do you already have a specific audience who are asking for the product? The more we know about your target user base, the better we’ll be able to plan an MVP.
4. Don’t forget finances. At the very least, you want to have a ballpark budget in mind for short-term and long-term effort. Whatever your budget may be, we’ll work within those limitations and architect solutions and timeframes within. Going the other way gets tricky, as it’s nearly impossible to estimate developer effort without having some kind of baseline estimations.
5. Don’t sweat the small stuff. Remember that your role is about communicating the big picture: business viability, vision and growth. What problems are you solving? Who is benefitting? Things like technologies, project scope, design come later—and that’s our job. Prepare yourself to discuss macro concepts without worrying about details during this stage.

How to Bring Your Vision To The Table

What exactly do we mean by ‘bringing your vision’ to the table? There are so many ways to go about this, that it’s really up to your style and judgment. I’m a big fan of Brien de Haaff’s roadmap to a Minimum Lovable Product, which aims to create a visual roadmap. The fundamental visualization (this is where you come in), the key purpose of the product and direct benefits to users should be well-thought out before meeting with your software house.

After you’ve established the vision, then we can work together towards strategies to achieve that vision, and a roadmap for action. These elements naturally build up on top of vision, but you need to supply that strong vision for the next stages to happen harmoniously.

Eric Ries’s Lean Startup is another great resource for understanding the MVP process, and what you, as a business stakeholder, should be thinking about when it comes to “vision-based” management rather than “instruction-based” leadership. In the lean startup method, vision-based planning is the North Star of the product building process. When everyone can focus on an easily-understandable mission, it’s easy to both motivate team members, and keep the plan towards MVP strictly controlled. For the purposes of software house cooperation, this vision is mission critical when we form a team, technology choice and plan for development of your MVP.

Alternatively, you could also start with visualizations in the form of Porter’s Five Forces or a simple Product Vision Statement on paper that answers important questions: In a year or more, what do you want your product to be? What grand problem is it solving? Who exactly in benefitting and how? Is the product realistic, but also bold and game-changing?

Play The Role of Business or Product Owner

Preparing for an MVP meeting with a software house means preparing your role in the conversation. We’ve met hundreds of product and business owners who are passionate about their products, but the most successful meetings were always those where the client was extremely passionate about their product idea. They already had strong ideas about how it would work, who it was for, and the ways it would make a difference. They could talk about their vision endlessly and repeat it over and over again to different people without skipping a beat.

On the flipside, we’ve also met owners who were already locked into a product roadmap. They had preconceived notions about what the product was (without any strong feelings toward vision), and were simply in the conversation to execute a long-term IT project. While these projects are sometimes necessary down the line, they are typically not successful in having a first-time MVP meeting.

If your vision isn’t fully formed in your head, and it doesn’t get your blood pumping, how can you expect to transfer motivation and communicate understanding to your technical team? Of course, you need to temper your vision and be realistic and flexible over time, but your passion for the product will be the nucleus

Communicate And Re-Communicate Expectations

Assumptions are the enemy of a first-time MVP meeting. We always want to know “What are your expectations towards us?” At the same time, you’re probably thinking, “Do you guys even know what I’m talking about?!”

That’s why it is critical to lay out expectations on the table. This means verbalizing each and every expectation, by asking follow-up questions like, “Is this something that you think you’d be able to achieve?” Even if you don’t know what your expectations might be, communicate that! Everyone makes assumptions, which is perfectly normal. However, both you and your software house must avoid assumptions at all costs during the MVP kickoff stages. “But we thought you understood what we wanted” is what nightmares are made of, and are easily avoidable with proper communication.

Don’t Forget Costs

Even though the MVP meeting is a time to focus around your vision, financial matters should also be at the forefront of your mind. It’s not just about the cooperation model with you and your software house, but the financial plan for the business. What is the cost of acquiring your customers? What startup costs have you already incurred? What will be the primary revenue streams for the MVP stage? What about in 5 years?

Of course, you’ll probably be more discrete before you trust us with any financial specifics. Instead of any, prepare in advance what you expect the average cost of development might be. Working with many first-time owners, we find that their price estimations are not always realistic (going in both directions!). No matter how many articles you read about the “average costs of software development” there’s no getting around the fact that you will need a custom quote. Luckily, that’s one of the things that can come out of your first MVP meeting—a general cost estimation based around your project scope. But this can only happen once we fully understand your product vision!

There are no wrong questions. Ask freely.

Remember that your first-time meeting around building a Minimum Viable Product is very much a get-to-know-each-other conversation.

The best thing you can bring to the table is a good vision for inspiring us. You should be able to describe your dream product, visualizing its early state and its growth potential years down the line. A good vision is also full of clarity and avoids the worst mistakes of vision statements.

When you bring the vision, we can bring the technical solutions to achieve it. In the next writeups, we will talk about what happens next after the first MVP meeting, including Polcode’s unique Scoping Session, Design Sprint, and how we achieve a unified Definition of Done with our clients. So stay tuned to our company blog!