The Five Stages of Building An MVP
A Developer’s Perspective on How Things Are Built.
by Glen Elkins
Stage One:
Excitement
It’s the beginning of a project and everyone’s excited. The sky is the limit! There are no concerns about timeline, budget, and the competition…yet. Stage one belongs to the dreamers.
The team comes together with an infectious optimism to start diving head-first into the project:
The Team
Visionary: The visionary comes to the table with the business plan and the vision to make their dreams a reality. While they’re not always a development or design expert, they are the driving force behind the project.
Tech Lead: That’s you (or me)! The tech lead handles building the MVP. Being a tech lead is empowering. You have the last say on all things technical, while keeping an ear to the ground to make sure they stay focused on what the visionary values.
Product Owner: The intermediary. The PO speaks some tech jargon, and more importantly, can gauge things like timeline and budget. PO’s run interference between the delivery team and the visionary. They can discuss tech changes to both sides of the fence (technical and non-technical).
Such a Thrill
Getting these roles together in a room for a new project is a thrill! There’s so much potential at this moment. Every role is empowered to contribute, and completely unencumbered by limitations.
Right now, your MVP is a blank canvas. It’s shapeless and limitless; Everything and nothing. It’s endless potential, tempered only by a tiny realization that one day you’re going to actually have to build it. One day, people will have to use it.
What Happens
While you can’t document every detail of the project in stage one, you do get a sense of the general problems your MVP solves. In stage one, you begin to understand who you audience is and what their goals are.
These are the assumptions you’ll be able to rely on through the project. They are especially important as your begin to decide where to start as a tech lead.
- What frameworks will you use?
- What back-end technology is a good fit?
- What features are going in first?
- What (if any) supplemental team members are needed?
Keep It Short
Since you’re (hopefully) using some form of an agile methodology, this stage should be pretty short-lived. Once you get enough warm and fuzzy feelings and a couple core assumptions to operate on, it’s time to get started building the damn thing.
Stage Two
Fun!
Stage two is called “Fun”, because, well-dammit, it is fun! It’s fun to start building something! As the developer, you get to scratch that itch and stand up a fresh new application. Much like Stage One, everything is still pretty open and the canvas is still “blank.”
Maybe you’ve decided on a specific framework for your backend stack. You probably have a handful of new tickets to work off of by now. Getting the first few things done in any project is such a joy because you’re free to execute them perfectly. There’s no legacy code to integrate with, and the initial features are likely simple ones.
You’re making progress in leaps and bounds! The MVP is still just an idea at this point, and you’re the magician turning it into a real “thing.” You’re breathing life into the visionary’s plans.
You feel indispensable and important during this stage. You’re empowered, creative, and productive. Life is good.
Locking Into the Groove
With a handful of tasks to start out with, you and your team can fully embrace the project. Typically, this is the stage I enjoy the most. I love getting everyone rev’ed up and started going. The decisions you have to make as a tech lead at this point are the fun ones. You’re able to use libraries or techniques you’ve always wanted to, but never found a spot for. You can solve interesting, important problems.
Right now, there’s nothing to worry about other than to deliver the best product you possibly can. There are no distractions and everyone is happy.
Stage Three
The Rapids
Great! Now you’ve built a few major features. Things are still going along smoothly and you have some testable functionality in your MVP. You also have a few design patterns established, some packages included and a decent amount of commit sunder your belt.
Patterns start to emerge from your code. You’ve wrapped up a few building blocks for the MVP, and understand the goals of the project. You’re now able to pull out functions and features and group them together.
After spending some time refactoring a few things, and making plans to code your next feature, you’ve never been more proud and confident in your MVP.
Hitting the Rapids
Then, perhaps, your team’s assumptions about the users shift around. That’s fine, you’re “agile.” You can pivot to meet the changing requirements. It just means you’ll end up with a better product in the end, anyways. Right?
A change in your design leads to a larger change in a major feature. That’s still “okay”, you assure yourself as tell your PO that this will push back your projected timeline.
That delay can be made up for somewhere else down the line. There’s still plenty of daylight between now and the project launch. Plenty of time.
In this stage, you’re always navigating the rapids between optimal code and new changes. It’s all manageable, but it takes finesse. It takes patience. It takes tact.
How to Navigate the Rapids
Don’t Flip! These rapids can be a stressful stage in the development of your MVP, but keep your cool. Things will only get worse if you start getting snippy at your PO, or get lazy by adding short-term patches instead of keeping your code organized.
Be Flexible: Everything has it’s breaking point, but your application should be flexible enough to handle a few small pivots here or there. Is it fun to throw away a feature you worked hard on? No. But it’s for the greater good, so you have to do it anyways.
This is also where innocuous things may creep into your project and destroy it’s legibility. Maybe “feature x” did a specific thing, and now it has a much larger role. If you don’t take the time to refactor, future you (or another team member) will have 0 freaking idea what the hell is going on. Change things like method names, variables, tests and organization as you go and avoid headaches down the road.
Be Accountable: If a comment that starts off “TODO: Do X thing later…” it will NEVER get done. It just won’t. Don’t let your code turn into a disorganized pile of meaninglessness. If something needs to be refactored so it makes sense to a future developer, do it now. That refactor will never be easier, more efficient and more rewarding than right now.
Stage Four
Post-Hole City
If you’ve ever been hiking in the mountains in the spring you know what post-holes are. Since that may be a minority, I’ll elaborate:
I live in Denver. I love hiking in the Rockies. There’s a month in the spring that local refer to as “Mud Season,” because all the melting snow makes the mountains a mix of ice, snow, and mud.
As the snow melts, it creates a frozen crust on top. A post-hole is created when a hiker steps onto that crust and it gives way under the full weight of the person.
What looks like solid footing is actually unsafe, and the only way to know if you can step somewhere is to do it.
Development can be like that. A small change here or there may appear safe and reasonable, but they could lead to larger problems. As your MVP matures, small decisions eat away at previous assumptions. You may find that a small change affects a great many things throughout the application.
This is why changes cost more as a project matures.
Best case scenario, it’s a knee-deep post-hole and with a little refactoring, everything can move along.
Worst-case, the fundamental assumptions you’ve based all your patterns on thus far get ruined. Now it the time for a major refactor or some ugly band-aids.
How to Avoid Post-Holes
Resist Premature Optimization: There’s a fine line between organizing your code and throwing as many patterns as possible at the problem. Over-developed solutions are often flexible in unimportant ways, and frigid in ways that matter.
Knowing which is which comes with experience. The best advice I can give is to try and resist making things “perfect” and just make things “great.” Subjective, arbitrary words, I know. Keep in mind that you’re building an MVP here. The whole idea of an MVP is that it will change, get added to, expand, etc…
Your launch code for an MVP should be great, well-organized, and performant. It shouldn’t prevent future improvement.
Be Heard: A good way to avoid a giant cluster-fuck in Post-Hole City is to constantly be on guard for small changes through the project. Make sure you understand what you’re building and WHY you’re building it, not just HOW you’re building it.
You’re in the weeds, your PO or client is not. You might notice if a feature of bit of UX doesn’t make sense before they do. It never hurts to discuss the 10,000-foot view and make sure your general understanding of the MVP jives with what you’re building.
Refactor Small, Refactor Often: Refactor is not a dirty word, it’s just boring. Often, the boring things get left for “later.” Don’t let that happen! Make sure to be building tests and small refactors along with the fun parts of the project. That way, when you’re MVP is more mature, you don’t have a mountain of busy-work waiting for you.
Unit tests may be the single most-important thing standing between you and a post-hole. Tests make changes just a little slower. That added time forces you to think through the larger ramifications of the change.
They also keep you honest. If your feature all have corresponding unit test, you’ll know right away if a small change is bound to spiral out of control or not.
Stage Five
Launch!
You’re done! Crack a beer, put your legs up, dispense high-fives all around!
If you got something out of this, or can related to my “normal” project development flow, it’d be awesome if you clicked the “recommend” button below to share with your network!
