Perfection Is the Enemy of Perfectly Adequate: A Lesson for MVPs
A brief advice column outlining suggestions to keep in mind when designing MVPs, creating processes around them, and what it takes to deliver a 'perfectly adequate' MVP.
Join the DZone community and get the full member experience.Join For Free
A couple of months back, I wrote a blog titled 'The price of excellence is eternal vigilance' that was published on my company's intranet portal, tying it to the need for constant monitoring/surveillance of data flowing through a distributed SaaS system. The quote is directly from the stellar TV show 'Better Call Saul.' I've recently come across another quote from the same show which I believe is appropriate for the design of a minimum viable product (MVP). This credo can hopefully help agile development teams find that perfect balance of delivering the right amount of value with minimum effort.
What is a Minimum Viable Product?
As defined popularly, a minimum viable product (MVP) is an initial version of a product designed specifically with just enough key features, that can be delivered to a few customers to validate its purpose and vision that in turn, enables the development team to get early feedback. This early adoption process is beneficial to both parties as the customers spend less to try the product, and the developers and product owners (POs) will get their assumptions validated.
MVP is a tenet of the Lean Startup movement where getting customer validation of a product through its use sooner is going to reduce the expense and effort of development teams, rather than spending a large amount of time in delivering a full product based on assumptions. MVPs have gained popularity in software companies and given that this concept fits right into the agile development manifesto principles, 'Customer collaboration over contract negotiation' and 'Responding to change over following a plan,' more and more teams have started adopting it into their development process.
This does introduce challenges. More often than not, it is hard to identify when you call an MVP 'ready' for adoption. As any developer wants to build a feature to perfection, given the innate quality of MVPs, it is important to efficiently design the subset of features of the product, so that you can deliver it to the customer as soon as possible.
Striving for 'Perfectly Adequate' Over 'Perfection'
What does it take to deliver a 'perfectly adequate' MVP?
1. User Story: Acceptance Criteria, a.k.a., Definition of Done
In a typical development workflow, any feature/product starts off as a user story in the team's backlog. The PO writes the story and works with the team to groom it and get into the sprint backlog. While defining the acceptance criteria of an MVP, the PO has to be extra cautious. The acceptance criteria and use cases should clearly define the requirements that justify and outline the minimum value you're trying to provide to the customer while walking the fine line of defining the pre-established, standard requirements for the product that should be met. Once this tight scope of requirements is established, the developers can execute on it.
2. Design, Develop and Deliver
There are various facets to designing an MVP as it takes different teams (architecture, API, UX, etc) to come together and build a unified product. Each team has to put their thinking hats on, and cut off excess fat when designing an MVP. For your API design, evaluate your strategy and ask how fit is your API for its immediate needs? In terms of UX, there are Lean UX Loop principles that can be applied. The architecture and software design is a tricky one, as you're formulating the base of the product, prototyping has to be done with thoughtfulness and forward-thinking. You still have to lay a strong foundation, but you can leave a few gaps in the software development phase, which can be filled after the feedback loop. A compromise can be reached in terms of software quality with the understanding that you're not changing the contract too much later on. The key here is to not overlook the 'viable' part of the MVP which guarantees the testability of its intended functionality. The more robust the delivery pipeline, the faster you get the MVP into the customer's hands. Depending on your product or feature type, the delivery methods can be different and the teams may use their discretion to not follow the traditional channels.
3. Customer Feedback
This completes the trifecta of a 'perfectly adequate' MVP. Not only does this step validate its 'minimum viable' characteristic, but it also helps create solid building blocks for future MVP design and delivery. Establishing a continuous feedback loop that includes the customer and cross-functional team members will ensure mutual satisfaction. This first-person experience and feedback will reduce assumptions while writing product requirements and overall enable the team to deliver more appealing products that always satisfy the customer needs.
As I wrap up, I'm not implying achieving perfection is necessarily a bad thing. In the context of MVPs and their user story readiness, it is absolutely okay to be "perfectly adequate" as we want stakeholder and customer feedback as early as possible, which will only make us develop quality products.
Opinions expressed by DZone contributors are their own.