How to get MVP to the market faster by setting the right goals

Your goal for MVP defines how it will work, how much time it will take, and how much it will cost.

When you have a goal for MVP that not aligned with your business objectives, you’re risking to:

• Spend time & money building the wrong things
• Go over the budget and burst your plans
• Overspend on MVP and, as a result, have less money on marketing & iterations
• Run out of resources before MVP is live

You can end up with less money and time to figure out how to make your SaaS profitable.

Let’s get into how to set goals that help you ship MVP faster, on budget, and with fewer risks.

Aiming high not always the best move

One of the biggest reasons for overspending on MVP is setting too high of plank for the first release.

Ambitions, what got you to start SaaS in the first place, can hold you back when launching MVP.

Inspired by the big vision for your SaaS it is too easy to set grand goals for MVP.

But the bigger the goal, the more money & time it will take to build an MVP that meets it.

Often it leads to the point when your first release isn’t MVP anymore. And it is the opposite of what you were trying to achieve with MVP in the first place.

There is nothing wrong with a goal to hit 7 figure ARR. That’s awesome.

But when it is a target within 2 weeks after the launch, it only puts more pressure on you. And it doesn’t give any wiggle room for a leaner product.

When you set too high expectations for the first release, you can end up with a product that is too far away in the wrong direction.

So let’s see what goals can contribute to shipping MVP:

• In less time
• With less money
• With fewer risks
  

Set small goals that aligned with the bigger picture

For entrepreneurs, it is difficult to ship a smaller version of MVP because it threatens their product vision.

But shipping a smaller MVP doesn’t mean you need to give up on your vision. It only means making 1st iteration smaller.

MVP isn’t your whole vision it is only a 1st step towards it.

Smaller goals for the first release let you adjust your course earlier.

When you release early and often, you gain momentum and keep team morale high. On the other hand, when you build for 4 months and never give it to users it can be very hard on the team 🙂.

MVP is for learning rather than getting revenue

When your goal for MVP is to make revenue, it will only hold you back from achieving it in the long run.

There is a big gap between launching the first version of a product and making it valuable enough to get paid users.

And there are very few chances to bridge the gap without showing it to users and making several iterations & pivots.

Of course, taking care of the financial side is must have to build a successful SaaS startup. But for the first release aim to learn rather than make money.

Why focusing on learning?

Because users will only pay you if it solves their painful problem. You have no idea whether it does solve a problem until you give it to a user.

And when revenue is the goal for MVP it only delays a moment when the product gets to users.

When your goal is to learn, you get rid of the pressure to ship the “perfect” first release, and you can get it faster to the market.

You don’t need all the bells and whistles on MVP to learn.

Here are some examples of goals for 1st release

• See whether it will solve the problem of a user
• See whether anyone would like to use it
• See whether anyone would want to pay for it
• Figure out what’s the cost of attracting users to sign up
• Mesure conversion rate from the sign up to the sale
• Mesure conversion rate from visitor to waiting list sign up

For example, Buffer’s founder Joel Gascoigne aimed to learn from MVP if anyone would be interested to use & pay for the product. It was only 3 pages:

• Product description
• Pricing page
• Waiting list sign up form

“The result of this experiment was that people were still clicking through and giving me their email and a small number of people were clicking on paid plans.”

 — Joel Gascoigne from Idea to Paying Customers in 7 Weeks: How We Did It

Even though the only thing he got from MVP is learning, Buffer now is a $20m/year business.

Solve 1 problem for 1 potential user segment

Don’t try to solve ALL of the problems for ALL of the potential users. You’ll waste more time & effort trying to cover all the needs in 1st release than you’ll gain from it.

When it is for everyone, it is for no one.

You can end up stretching yourself too thin trying to cover all the needs. And get the product that solves many problems in a mediocre way.

Jussi Pasanen’s MVP Pyramid Model

Don’t half-assing 2 things. Whole ass 1 thing

Focus on the 1 problem for 1 target audience segment. It will let you build it faster, and getting the first users will be easier.

When you select the problem to focus on, pick the one that is burning enough and will give the biggest ROI from solving it.

You can always expand your product later to solve more problems and for more people. An active user base is a great asset to get feedback on new features.

Even Amazon started not as an “everything store”.

Amazon.com in 1995: one million book titles

Cut it till you can see it through

Your goals should let you see through how to reach them.

The bigger an MVP, the more underwater stones will come up during the development that will knock you out of track.

You can’t make accurate plans about how much it will take to build a product unless you can see it through.

It is like estimating the weight of an iceberg by its pick.

Thank less nightmare.

Pull back on the goals for MVP till you can see what you need to do to launch it.

Don’t solve problems that you don’t face

When you are launching an MVP the last thing that you should spend your resources on — is solving problems that you don’t have.

Do you really need to worry about scaling to 100 000 users if it will take you 2 years to get there?

— from Getting Real by Basecamp

It is too easy to spend too much time upfront solving problems that you don’t have. It even can be a way to escape from facing current problems.

In the early stages don’t spend too much time on unnecessary bells and whistles. And focus on the problems that are in front of you:

• Not knowing whether anyone will want to pay for the product
• Not knowing whether the product solves the problem
• Not having the product that you can give to users
• Low activation rate for users

Pull the right levers.

Outcomes from increasing conversion rate by 50% for a landing page that gets 100 visits/mo are drastically different from the one that gets 100 000 visits/mo.

Investment the same outcomes are different.

For example, guys from Basecamp, a multi-million dollar project management tool, launched it without billing.

“Heck, we launched Basecamp without the ability to bill customers! Since the product billed in monthly cycles, we knew we had a 30-day gap to figure it out.

We used that time to solve more urgent problems and then, after launch, we tackled billing.

It worked out fine (and it forced us into a simple solution without unnecessary bells and whistles).”

 — from Getting Real by Basecamp

Wrap up

The goals you set for MVP defines how it will work and how much it will cost.

Big goals for MVP make you ship bigger MVP.

So to get your MVP to market faster:

• Set smaller goals
• Remember that small MVP doesn’t mean small product vision. MVP is only 1st building block in your product vision.
• For the first release aim to learn rather than to make money
• Solve 1 problem of 1 target audience segment
• Make the 1st version of the product small enough so you can see it through
• Don’t spend too much time upfront solving the problem that you don’t have