Setting Yourself Up for Success - How I Define MVP (Minimal Viable Product)

Let’s be honest -- things are constantly evolving in the tech world and there's always something new to try. It seems that each month brings with it a new hype JavaScript framework or library and on top of that, because we’re developers, we have lots of interesting project ideas.

I've recently been putting a lot of effort into my portfolio website. I love adding new features and making it a unique slice of the internet tailored to me and the developer I am. One day this past week while installing a library in my portfolio project, the process failed and told me I didn’t have enough room on my Mac to install the dependency.

Puzzled, I opened my Mac’s storage settings and low and behold, I had less than a gigabyte of space free on my machine. What in the world? Where did all of my space go?

Come to find out, I had a bunch of small or medium sized projects just sitting on my hard drive. I had forgotten about most of these projects and it got me thinking:

Why do I have all of these projects on my Mac?

I have a confession to make and I suspect the same can be said of you: I start a lot of side projects, but rarely see them through to a usable state.

As developers, we come up with unique ideas that may help solve a real-world problem. We create and clone a new repository, pour a ton of effort into the project at first and then… nothing. The project never sees the light of day. Why is this?

My proposal, in part, is that we allow the definition of MVP to encompass too much work; we’re setting ourselves up for failure instead of success.

What does MVP mean, anyway?

MVP stands for Minimal Viable Product. It’s generally considered the stage of a project’s life where it has enough features to become usable for early adopters.

You may have a brilliant idea for the next social media app and have a bunch of features lined up in your head, but the MVP version only contains the bare-bones features that are essential for someone to actually use and benefit from the application. But how would you, as a developer, determine what MVP looks like in your side projects? That’s subjective. And I have a few suggestions.

Too much scope - not enough results

If you’re anything like me, I get an initial rush of excitement when I start a new project. It’s exactly that - new and thrilling and has the same effect as that ‘new car smell’. I have an idea and, with little (or no) planning, hop straight into my editor and start typing away. I don’t put much thought into MVP and when I do, I tell myself that adding a specific set of features is essential to the early adopter.

I’ve gotten so use to defining MVP in terms of features that when I try to identify that MVP-threshold, I include too many features and work eventually tappers off, resulting in another project taking up space on my hard drive. There’s too much scope — and I’m not seeing enough results in order to maintain the excitement that drives me to keep going.

Step 1: Determine MVP based on a timeframe

When I look back at failed side projects that I took seriously, I noticed a pattern. I put in a lot of effort for the first four weeks before the amount of features came slowly to a halt. How about you? Look back at your side projects — how long does that feeling of excitement last? My guess is that as long as you’re excited about the project, features are being completed.

Perhaps for you it’s three weeks. Or even two weeks before that excitement begins to fade.

My suggestion: Excitement breeds engagement. Determine how long the excitement level usually lasts for you. Have that be your timeframe for MVP.

Step 2: Determine MVP based on your experience and skillset

After determining your MVP timeframe, evaluate your skillset from past experience and select features you can realistically complete within the allotted time.

Each of us is at a different place in our development journey -- you may have more exposure and expertise in back-end languages and frameworks while I may have more when it comes to the front-end spectrum. It’s important that you don’t compare yourself to others; it can be detrimental and instantly kill your excitement and drive.

Now that you’ve determined a known timeline and have realistically selected features, begin work on your side project and continue the push towards MVP. 🎉

But what about bringing value to the client or customer?

Right about now I can probably guess what you’re thinking:

Braydon, this is dumb. The point of a MVP is to produce enough features for customers to gain value from the project, not to identify features that fit within a predefined timeframe!

I know. I hear you — and I agree when we’re talking about projects specifically for clients. That's a totally different beast.

But when it comes to personal projects that are being worked on during your spare time, I believe the project has a better chance of seeing the light of day if the excitement is continually fueled and features have a realistic chance of being completed.

What is success?

The feeling of success is a major ingredient for excitement to live on in the project. But how do you reach success in a side project? If you achieve the defined MVP, you are successful! If you don’t reach MVP, but you learned something new, you’re still successful.

But consider this: because the MVP timeframe was determined and a feature-set defined, you should have certainty that MVP will be completed. That, in and of itself, should give you a boost of energy to diligently work towards that end goal!

What do you do after crossing that MVP-line? Plan your next goal - whether that’s a single feature or if you’re ready to make the push towards public release!

Isn’t this just working in sprints?

As I’m writing this article, I asked the same question. Is what I’m proposing just another way to say that you should be working in time-based iterations? In a way, I guess.

In a traditional client project, you may work through several iterations with many demos before reaching the defined MVP. For side projects, it’s usually much more informal. Rather than working in multiple iterations, I suggest following the steps defined above and reducing the scope of MVP to ensure you achieve that goal in one-go.

Conclusion

There’s a lot of opinionated points in this article, but let me summarize: we’re more likely to stick to something if we’re excited and see completed value.

What can you get done in 4 weeks? What features do you realistically believe you can complete in those 4 weeks? Figure it out, create a plan and go for it. My hope is that your success rate improves and your project graveyard will slowly stop getting new gravestones.

Thanks for reading! If you liked this article and want more content like this, read some of my other articles and subscribe to my newsletter below!