Your Startup Needs An MVP- But It Really Needs A BVP!

Building and deploying successful software is difficult, and having a team of many people all trying to coordinate their work to form one piece of software ironically doesn't make things easier. I'm a huge fan of the Lean Startup mentality and the idea that until your business has found and is consistently producing profit everything is just an experiment being tested to find what works and what doesn't.

Building software is a huge undertaking, and there are many horror stories of companies blowing through millions of budget dollars only to never ship anything and have the source code that costs so much basically thrown away. I've often seen misguided companies spend far too long trying to build an "MVP" that is way too large and has suffered from loads of scope creep and last-minute features. This is what I called the "MVP misinterpreted".

The MVP Misinterpreted

The minimum viable product is for naive stakeholders the only thing on their mind. Some companies treat the "MVP" as the end-goal; they mark an arbitrary deadline on the calendar months (or even years!!) away that we are all marching towards and will [hopefully] all come together right at the end for a big bang release.

That sounds like classic waterfall development to me, and it completely misses the spirit of what the MVP is all about. This method is very risky because its hard to measure progress as there isn't much usable software along the way. There is often lots of waste, re-work, incorrect prioritization of features, and a large disconnect from what users actually want. Suffice it to say that this is not the type of MVP you want to attempt to build.

The MVP Done Well

I often see managers and engineers think of a project as a thing with a finite end. They think that the application will be worked on, it will be deployed, and then we'll be done! That is absolutely not the agile, MVP-style of development that I would recommend. You should be deploying relentlessly- so much so that it should automatically happen on every merge to the specified git branch! The MVP is nothing more than the first deployed version of your app that a user can get value from.

The MVP is nothing more than the first deployed version of your app that a user can get value from.

When you think about it like that, it's not such a scary and far-off thing. By being scrappy, having lots of experimental "spike projects" outside of your core project repo, and testing out different ways of doing something you can fail fast and truly learn from your users early while you still have time to build the right thing.

The MVP Is Just A Snapshot In Time

When I'm working with clients who are stuck in the mindset that the MVP is the finish line, I like to pull out this diagram I made. I apologize in advance for all the acronyms, and below the image I'll explain what's going on!

The main purpose of this above diagram is to show that the project is an organic, ever-changing organism that exists through time. I am a huge believer in continuous integration and thinking early on about dev, staging, and prod environments. In my opinion, after the initial project scaffolding is laid down it is never too early to start deploying, and ideally I feel that you should be deploying to a dev environment in the same week that the project is started. It's completely fine if your first deploy to dev completely explodes upon user interaction. It would obviously not be acceptable to launch the product at this stage, and so I call this phase the "Not Viable Product".

As long as these deficiencies are discovered, prioritized, and worked on then in time they will be pulled away. As long as there aren't major regressions and the verification process is quick (*hint hint- don't be afraid to leverage automated tests!*) then the application should naturally come to a state where it is an MVP.

Also, notice the common adjective between throughout these phases: viable. Google's current definition for viable is, "capable of working successfully; feasible". Keep in mind that the most important thing is building working software, and by "working" I mean that it is free of logical bugs and doesn't crash but also that it satisfies the users' needs and provides some external value to them.

When Is It MVP & When Is It BVP? Who Cares!

The MVP by definition is the "minimum" viable product. How you know when your application has crossed the line between "not viable" and "minimally viable", and how you know when you've gone past the MVP and you've done "too much work" for it to be the minimal product. Personally, would argue that it doesn't matter, and it is the complete wrong thing for which we developers should be concerning ourselves. No person within the company needs to ever declare the product as the MVP- you will know when the app is an MVP when at least one user actually uses it on his or her own free will!

I would also argue that the MVP is not what the engineering team should be shooting for. All they should be focused on is consistently coding and shipping incremental improvements to the software. Shooting for the MVP is like a student asking him or herself, "what's the minimum amount of studying I can do to get an 85 on this test?". It's cleary the wrong attitude to have. The student should be focused on incrementally learning more and more in the given time and attempt to get the best score possible on the test. Similarly, the developers should be focused on making the product incrementally better and better ad infinitum, allowing business and marketing to decide how much they want to push the product to end-users as development progresses.

The PVP - When Incremental Improvements Start To Pay Off

This is a methodology that really works, and I can say that because I've been involved with many dev teams over the years who have worked this way and enjoyed it very much. When you can at least demo something every week, even just a slightly different bug-free version of the previous week's demo, it really builds momentum within an organization. The smiles, the high-fives, the positive feelings from every stakeholder all increase when you release frequently, and whenever there is a bug it's noted and squashed quickly.

I have even used this development style on my own projects, and I am proud to say evaluates2.com and katefromhr.com are a few of the projects that I would consider to be in the "polished" category now, although there was a time when they were just-deployed MVPs and heavily-under-construction BVPs. It's very easy to get lost in development, and I think it's really a wonderful thing to once in a while stop for a minute, appreciate how far an application has come, and really get inspired to always want to add yet another incremental improvement, making it even that much better. Working this way is has been for the most part pleasant and at times even fun in my experience. With things "already delivered" all the time the projects hums along with low risk, and the team can utilize real user data from the live environments, even in the early "Not Viable Product" phase, which help validate the hypotheses and ultimate prove out whether there is a legitimate business model here or not.

Good Practices Build Good Products

One final point I want to make is that you should be diligent and disciplined in your work. There's an old joke that many software projects progress rapidly to 95% completion- and then stay at 95% completion forever! The scrum-agile nomenclature of "sprinting all the time" can sometimes inappropriately put too much pressure on engineers to cut corners are deliver too much, too soon. You should never allow loud, non-technical bosses to downplay the importance of having good automated tests, having a CI/CD pipeline, etc. Every week and every sprint should include tasks that clearly deliver value to the user and should include some chore tasks for tidying up the repo, automating things, fixing dev-ops issues, etc. In this way there is never a "big bang release", there is never a "we finished the MVP!" celebration, and deploying a new release is a no-big-deal event. Then one day you wake up and go to work and they say, "Wow, this app is so incredibly nice that we literally can't think of anything to improve right now!". That's the goal you should really be shooting for; the MVP is just one ambiguous checkpoint along the way.