Back to Posts

MVP's are broken

Around two months ago I offered to help a friend with the app. It's been awesome so far, tight timelines, figuring out tough technical problems and managing the project.

I worked on a couple of "MVP" type of apps in my career so far, all of them which I inherited from other people, and I've noticed a couple of patterns which may help you out when you make a decision to take your product to the market.

Nik's Guide To MVP's

Step 1: Validate the idea. Don't write code.

So first and foremost I urge you not to code until you actually have an idea that is worth writing code for. Again please do not code until there has been proven traction for whatever you are trying to get to the market.

I've seen this too many times, and I am guilty of this as well ( two times ), if you're a builder you will have the tendency to build the app. Because that's a low hanging fruit and an "easy" thing to do.

If your idea does not have traction, and people don't care about it, there is no point in writing code. I'm looking at you Node.js enthusiast, that just learned React Native and want's to build Uber for pancakes. Oh, and I am also looking at you creative founder, who is about to hire a person to build an app for him.

Logical question after this claim would be:

"But how do I validate the product if people can not use it?"

Great question, but also the one that has been answered a lot of times on the internet. There are multiple ways to see the traction for an idea.

Classic ones are outlined in the startup bible called "Lean Startup". That includes interviews, landing pages, etc.

Product Hunt was validated via good old email. So Ryan Hoover, Product Hunt CEO, started an email list that included interesting products, and more and more people wanted to be on the list, so then the Rails app was built to support that.

All in all, there are many ways to validate your product without coding. So do yourself a favor, learn from other people mistakes and don't code until there is proven traction.

Step 2: Figure out what features you really need.

So we validated the idea, now it's time to start building that sweet app. The thing is we need to figure out what features will the app have before we write any code. So how do we do that?

I heard a long time ago, CTO of Thoughtbot, saying this:

My initial response for a feature request is a big "no".

And at the time that did not make any sense. More features, mean more things a person can do, which in turn means more revenue?

Of course not.

Only a couple of features, especially at the start, provide value to the user and only building those is important. Everything else is a nice to have or maybe not even that.

So when deciding what features to build take a piece of paper and write down all of the features you had in mind. Now imagine you are not going to build any of those and you need to convince yourself to build it.

Of course, this can be hard if you are the CEO of the company, that's where a good technical lead/CTO/Product person can come in and play the bad cop.

Now below every feature you've written write down values it will provide to the user. Sometimes I even write down user stories in a standardized format, to help me realize what the value is.

Now if you did your job right at product validation, you will know why your customers liked your idea and what value did they plan to take out of it. Or at least you have a good guess.

Since you know that, now you cut off all of the features that don't provide that value and that's it.

Step 3: Build

Finally the step we all been waiting for. Building that thing.

So presuming we have the market validated, and the app's features have been clearly defined, it's time to build.

Usually, the urge is to build it ASAP, because all of those customers are waiting on the front door right?

This type of mindset usually leads to a couple of problems.

When people are building things that are "prototypes" or MVP's they don't write tests. Of course, this is not always the case, but I've seen a lot of apps with zero test coverage.

There is literally no excuse if the app was validated in the market and there is traction, for you not to write tests. I am not saying 100% test coverage but at least basic integration and unit tests. Please do your future self and engineers that are coming in the future to work on the app a favor and write tests.

Secondly, I've seen a lof of crappy code. Now, this may be due to the inexperience of the one writing it, but also it could be because of ASAP factor. If the later is the case, please don't let the urge to finish things, stop you from writing decent code. And I don't mean anything perfect here, just don't write conditionals in views, don't make giant controllers and models, separate your concerns and know the basics of OOP or functional programming if that's your jam.

I can go more on all of the bad coding examples and things I've seen wrong in the codebases but the previous two paragraphs get the point across.

Step 4: Iterate

All of the assumption we made about the market and features need to be iterated upon. What does that mean?

Well once you build out an app, you sit down and watch users behavior. You manually onboard them. You ask questions. You ask for feedback. Even pay people to give you feedback. It does not matter, just keep improving on those features.

Sometimes that means adding more features. Sometimes that means bumping up your prices. Sometimes that means cutting off features and bumping up your pricing. Experiment and iterate. See what works and when it does iterate again.

Final Thoughts

We've all been guilty of rushing things. We've all been guilty of doing things prematurely. That's when experience and patience come in.

Nobody is perfect and we will all make mistakes. But if we can learn from each other's mistakes and embrace them, resulting in "skipping" some of them, our path to success might be a bit easier.

That's all from me. I'm always looking for feedback so please do let me know what do you think about this article on social media or where ever you find me.

Software engineer that loves business side of things as well. Also lifts a lot of weights.

Read Next

Macro Patience & Micro Speed