Joining your rival is not a way to build your MVP…….but thanks Kevin Durant!

Don’t Cheat Yourself…A Sports Lesson About Building Your MVP.

My name is Kameron Kales and I am a cofounder at Glance. We are a top of the funnel recruiting tool that helps recruiters eliminate bias & be more efficient. I have learned a lot over the last year starting my company and thought I could provide some thoughts on applying a lesson from my childhood to product development. This will also be posted on LinkedIn, Facebook & the SaaS Growth Hacks Medium Publication

(Thanks to Alexander Kehaya for inviting me to contribute).

Growing up I was like most young kids. I loved to play video games and sports. I hated doing my homework & frequently forgot to clean my room. While growing up I spent about as much time on the soccer field as I did in school (my mother is in education so you can imagine how much she loved my priorities list).

I may have tried to headbutt my homework once or twice.

During my time playing soccer I had one coach who changed my life.

At the end of a practice coach yelled at the team for not hustling through our suicides (full field sprints done after a 90 minute practice). But this time was different. He stopped us and told us….

“Don’t cheat yourself. These sprints will make you better. Running them slow is cheating yourself out of your potential.”

This hit home for me. I started thinking about everything I do in life and reasoning my way through the extra effort cost and the increased potential. Running a few extra sprints didn’t hurt that bad. Studying a little longer for my math test didn’t mean the end of the world……

Flash forward to today when I build products for users and this is the most influential piece of advice I have heard. We all set out to solve an immense problem and believe we are saving the world of this incredible pain. We will make everyone’s life easier, instantly. And they will love us for it! (sounds exactly like me 6 months ago).

What we think our users will do

But as we go through showing our product to users we realize we designed, built and/or architected it in a fundamentally wrong way for the very people we thought would love it.

There are usually a few reasons for this:

1. You developed the product in a bubble — very common & easy to learn from.
2. You made choices based on effort required — the “cheated yourself” principle. harder to learn from.

Developing a product in a bubble is a horrible idea. You can argue all you want for the few startups who have been successful doing so but 99.99% are not.

For more about how to not develop in a bubble read this blog post.

But I am writing to discuss a significantly less popular reason why users don’t love your product and the fundamental connection I made from my soccer coach.

Every developer, founder and/or business owner makes decisions about cost and time. Some decisions end up being easy to quantify the benefits from and some not. A few extra sprints after practice are hard to quantify.

Truly amazing products incorporate the same mindset in “not cheating yourself”

For a real example of this think about Slack. How did Slack actively chose to not cheat itself? It added all of the nice to have features that make you smile while using the product. Slack at its core is a messaging app that cuts out the need to email.

This stresses me out…….Slack fixes this.

So if Slack at it’s core is a messaging app that eliminates the need to email…why does slack support code embedding, video calling or integrations with other services? These are nice to haves that make the experience way more enjoyable. They are added product complexities that raise maintenance costs and developer burden. They did not HAVE to be there. But a great product goes the extra mile.

A great product runs the extra sprint. And unlocks more of its potential by doing so.

We came to this realization for us at Glance a few weeks ago doing a user interview with one of our beta customers. The customer uses the product for what we consider 75% of the time available. And this got us thinking….why does she not use the product for 100% of the time?

While we were developing our platform we did the typical “MVP” process. Talk to users, identify problem, build some stuff to solve problem, iterate, rinse & repeat. But in this rinse and repeat process we made tradeoffs that are very typical in early stage product development.

We built what was most feasible in a short amount of time to validate interest. But this gets us back to the “don’t cheat yourself” principle. As we made these tradeoffs we took some of the wow factor in our product away.

We cheated ourselves out of enabling users to love us when we were thinking like developers*.

Not problem solvers.

Seems like the case while balancing speed & product.

These hats need to exist together but at different time periods. Let your problem solver hat sit on your head while talking to your users. Fully understand what hurts them. Fully quantify these pains. And then put your developer hat on and figure out how to make these pains fade away with delight.

Believe it or not users have pain everywhere. Find one and fix it.

While thinking about this in a sports sense we should apply the problem solver mindset while training for the game and the developer persona while playing the game. In training we should seek to understand and bring out exactly what we need to make a difference in the game. In the real pressure packed situations we rely on our developer skills to execute on what we practiced in training.

After we adopted this mindset and actively chose to not cheat ourselves in product development we have seen our usage numbers take off.

Thankfully our users don’t utter the same as Mr. Shark here.

There are a ton of opinions on how to balance product development with time and many people have more experience than I do in the field. However, I witnessed our users become significantly more happy with the product once we decided to stop optimizing for time efficiency.

We actively chose to wear our problem solver hats first and foremost, then figure out how to build to remove pain.

Features that added complexity were avoided at first when we were optimizing for time. Now that we are tackling complex features we see our users exponentially more happy with the product.

They had the wow moment for the first time and now are sticky daily users.

This thought process should be applied in other fields as well. What potential are you missing out on by not running that one extra sprint? Are there product improvements you have been putting off?

There certainly is a maxima in how much complexity you should take on and the costs associated with doing so, but consider the benefits before opting for the easiest route.

What would the extra sprint look like in your product? And much value would your users obtain from that sprint?

*I say this as a developer myself who constantly fights project deadlines. Developers are incredibly insightful and amazing at thinking through products. However, I have thought in limiting terms around deadlines and base my statement off of this.

If you liked this article do me a favor and hit the heart button below. It will help other people discover it and encourage me to continue writing about product development :)

Thanks to Chris Comrie and Alex Smolen for reading early versions of this post.