We spent six months building our first SaaS MVP before launching Standuply in beta. In April 2018 it reached $19k in revenues with 500 customers and keeps growing.

In the previous post, I described a part of our journey how we went from business idea to a beta product launch.

Today I will share lessons we learned while building a SaaS MVP. We made many mistakes, so you’ll have a lot to learn from.

Lesson 1: Customer interviews may not reveal new features

We did tons of interviews. We spoke about customer pains, workflows and listened to their feature requests.

Interviews helped us to see a bigger picture. But we were surprised that it didn’t help us with new features.

These are the challenges we met:

— You have to talk to a bunch of people about the same process.
— Not every respondent will have that process in place.
— B2B customers are busy people.

So, to discover one feature, you spend a hell of a time scheduling interviews and running 20–30 of them. It could take weeks.

But more importantly, people may mislead you.

We heard many times how important was this or that feature. But once we shipped those features, no one was using them.

Thanks, doc.

It turns out, sometimes it’s faster to ship a feature and see how it’s used.

Lesson 2: Internal statistics is your radar

To move forward, we needed the data how our SaaS MVP was used and by whom. We didn’t have internal statistics at first. It was like flying without radar.

We had to ask our developer to share metrics every time we needed data. It distracted him and wasn’t handy.

As the time passed, we built advanced statistics to see how Standuply is used and by whom. Now, we track everything what happens inside our product.

I can’t imagine how we could work without it. Instead of shipping additional features we should have built it from the start.

Lesson 3: A working product is more important than any deadline

We planned to ship the first release on a specific date. It wasn’t an important day. We just wanted to be lean and fast.

However, our estimations were wrong. We were not able to complete the work by the deadline. You know how it happens, right?

Regardless of that, we decided to ship the product within the deadline.

I don’t know…

We saved the week than to lose a month.

It led us to the bad coding, demotivation and tech debt for no reason. We didn’t have any specific need to ship by a specific date.

We had to postpone a deadline until the product worked properly.

Lesson 4: Two developers are better than one

The trivial statement, right? But it’s not only about the amount of code you may produce with two developers.

We found that having only one tech person on a project may lead to coder’s block. No matter of the personality and experience, it’s just psychology.

One person can get stuck, while several people have better chances to find a solution.

Later a junior developer joined our team. Together both developers started moving much faster.

Thus having one developer on the team may come at a higher cost than two.

Lesson 5: Technical foreseeing may save the day(s)

We wanted to ship fast. To do that we worked only on what was urgently needed.

So, in the first iterations, technical foreseeing wasn’t on the list. Sigh.

We didn’t plan how users authorization will evolve (i.e., for managers with several Slack teams). We could have spent some time looking in the future.

Later we did that anyhow.

We had to rewrite a lot of our code to make authorization scalable and convenient for users. If we did a bit of technical planning, we might save a lot of time.

Lesson 6: Talk a delivery date when the feature is being tested

How many times I promised our users new features arrivals. It was dozens of times.

Guess how often I fulfilled those promises in time? Not a single one.

No, it’s the dev team…

Okay, it’s me. I hate when it happens. But, estimations are often incorrect.

I decided to promise delivery dates only when the feature is being tested.

Lesson 7: A viral invite system didn’t work for us

There are a lot of products and materials how to set up a viral invite system. We used the post by Tim Ferris to do the same.

We spent our precious time to design and set it up:

— for every Twitter/Facebook share we would send a list of 300 hand-picked growth hacks (a great one, I swear);
— for inviting friends to sign up, we would then provide the service for free;

It looked cool but eventually didn’t work out.

I assume it may work for products in high demand. In our case, people didn’t spread the word about the product they didn’t try.

Later we made this mistake one more time. ¯\_(ツ)_/¯

Standuply users can get it for free by inviting their friends. Out of thousands of signups, only a few come via that system.

If you know how to make it work, please tell me in the comments below.

Lesson 8: Mobile web layout matters a lot for a landing page

Well, that’s the obvious fact nowadays. Sadly, it wasn’t for us.

Wanted to ship faster we didn’t optimize our landing page for the mobile web.

Don’t be like us.

After MVP launch, half of the visitors were coming from mobile devices. Thus, we had a poor conversion rate from those visitors.

We should have to deliver a nicely done landing page for both desktop and mobile users. In order to avoid making the same mistake as we did, it is important to use behavioral analytics tools to understand how users interact with your website on different devices.

However, our current web part of the product isn’t yet optimized for the mobile web — it’s mostly used on the desktop. Later we’ll improve that.

Lesson 9: Vague and marketing taglines didn’t work

We used different taglines with explanations on the landing page. Here are some of them:

Improve Your Communications and Reporting in Slack
ReportChef prepares custom reports from your team and task tracker

Keep on track using Slack
One single tool to share progress and obstacles

They worked poorly and kept visitors confused.

We found it’s better to use basic language speaking about concrete use-cases or problematic area.

It became crystal clear when we changed the tagline to “Automated Standups for Slack.”

Lesson 10: User feedback services weren’t useful enough

We used services to gather feedback on the website. They provide visitors and then ask them questions about the experience.

It may sound like a useful thing to do. You can ask questions like “what does this website do?” or “how do you like the company’s name?”, etc.

However, most of those visitors were out of our target audience. Thus, their opinions were not that relevant.

We had to spend more time showing the website to our potential users and tracking our metrics. This is what makes a lot of sense.

Just in case you need such service, here’s the list of them:

http://usersthink.com/
https://validately.com/
https://www.userzoom.com/
https://www.loop11.com/
https://verifyapp.com/
https://userbrain.net/
https://userbob.com/
https://ferpection.com/
https://www.trymyui.com/
https://usabilityhub.com/
https://fivesecondtest.com/
http://usabilityprovider.com/

Conclusion

Many people advocate for shipping SaaS MVP as fast as possible. But in contrast, our experience shows downsides of that approach.

Speed matters a lot, but planning and quality are also important. Seems like it’s about the balance.

I’d like to wrap up with a quote by Rand Fishkin, founder of Moz:

My experience has been that there’s been a bias — especially the past 7–9 years — to minimum viable meaning something small and crappy. Small and crappy doesn’t cut it in a competitive field. Therefore I’m advocating for something exceptional and dramatically better than the competition.