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 windows to install the dependency.
Puzzled, I opened my Laptop 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:
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 real-world problems. 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 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 used 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 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 number of features came slowly to a halt. How about you? Look back at your side projects — how long does that feeling of excitement last? I guess 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. Has that been 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. You mustn’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 toward MVP. 🎉
But
what about bringing value to the client or customer?
Right about now I can probably guess what you’re thinking:
hanii, this is dumb. The point of an 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 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 toward 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.
Final Words
There are 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 the completed value.
What can you get done in 4 weeks? What features do you believe you can complete in those 4 weeks? Figure it out, create a plan and go for it. I hope that your success rate improves and your project graveyard will slowly stop getting new gravestones.
🙏 Conclusion
Thank you for reading it till the end, I really appreciate it. I would be grateful for any feedback, so feel free to reach out to me or leave a comment below. It has been an amazing journey, and I really enjoyed it!
Top comments (0)