Think SFSP not MVP
Abstract
At IllumiDesk we are starting to use SFSP (Smallest Feature Set Possible) instead of MVP (Minimum Viable Product). This helps clarify the intent when shipping a new product or epic feature, increasing the likelihood of success.
Introduction
We have been debating quite a bit about what features should be included with the first version of our product or a new epic feature within our product.
Everyone that I have spoken to, including myself, loves Eric Reis’s Minimum Viable Product (MVP) concept, coined in 2009. Other experts (as pointed out in the referenced Wikipedia entry) consider that an MVP must be salable and we completely agree. However, what about maintainable, iterable and securable products or epic features? We made the mistake of interpreting MVP to not only include the minimum number of features possible to launch, but to also not include characteristics that would guarantee quality and provide a process to allow for quick iteration (read: help move up the value chain).
Changing our mindset to think of the minimum number of features for a launch but always include everything we needed helped us reduce risk and allowed us to become more agile as a result.
The Problem
We personally got caught in a trap of having to ship things fast but (although we don’t like to admit it) cut corners which ended up costing us time medium and long term. For example:
Not including the minimal level of user facing docs to use the product/feature
Circumventing the minimal level of unit and integration tests, because we can “add those later”
Not defining a full process to develop new features, because it just takes too much time. We are a startup there shouldn’t be any red tape!
The Solution
Change your mindset from MVP to SFSP.
Establish an end-to-end process to ship new products or epic features. At first, this process will naturally be manual and non optimal. However as you ship more products or epic features, your process will improve (you will automate or tune it, unless you are a masochist). And the more you practice your process the better you will get at it. And the better you get at it the faster you will ship.
The process should include, at a minimum:
Planing and validation phase (wire frames, mocks and in some cases interviews)
Unit testing
Integration testing
Code reviews
Load testing (not to say that you have to support 100 million users, but at least know when it may break)
Security (just best practices to start)
Documentation (code docs, internal docs and customer facing docs)
Deployment pipeline
Monitoring, feedback loops and on-going maintenance
Example #1 with MVP
Product Manager: “Hey guys, I have an idea for a product. Let’s build it! Remember we need to ship this as an MVP, then we can iterate and improve it.”
Lead Developer: “Yeah that’s a cool idea! I’ll get my team to build it fast. You should have something in one month!”
Product Manager: “Sweet! We can sell it if you have it by then. We can add the other stuff later.”
“Other stuff” in the example above is where things tend to break down. The intent was good and in line with MVP, but not specifying exactly what’s necessary to take someone's money in exchange for your product leaves things to interpretation, and, generally speaking, that leads to sub-optimal levels of quality.
Example #2 with SFSP
Product Manager: “Hey guys, I have an idea for a product. Let’s build it! Remember we need to ship this as an SFSP, then we can iterate and improve it.”
Lead Developer: “Yeah that’s a cool idea! I’ll get my team to build it fast. You should have something in one month! I’ll also make sure I go through the checklist of things we need to work on in parallel to make sure we can ship this with the minimal level of risk possible.”
Product Manager: “Sweet! We can sell it if you have it by then. We can add to the checklist and also improve upon the product with new features moving forward.”
The Outcome
Our DevOps pipelines became more efficient because who likes to click through the UI every time you are going to deploy? And who likes to type the answer over and over again when end-users have questions? Or who likes to see errors pop up again that had been previously fixed?
This small change in mindset forced us to improve our whole process when shipping new products or epic features. Forcing ourselves to think about shipping with SFSP instead of MVP allowed us to change our mindset and improve our quality. Perhaps it could help your team too!
Would you like to learn more? Feel free to register for a free account and chat with us today. We are here to help!
