Less Sooner MVP
Valued Output. Less Sooner. Checkpoint Often. Timely Iterations. These are Xentity’s delivery purposes. Across all our data services, when I ask my team during our quarterly check-ins which delivery purpose challenges them the most, I receive the same answer: “Less sooner is where I struggle the most.”
So, I ask them, “What does less sooner mean to you?” The usual response is something along the lines of, “delivering the smallest valued working bit of functionality the soonest.” That is close (if a bit of a mouthful). I can see where they lose the meaning of “Valued” functionality. Close as that may be, the concept of less sooner does not come down to “Value”. It is an honest mistake. This confusion serves as a perfect opportunity to emphasize a great concept Xentity holds dearly: Minimum Viable Product (MVP).
Before we get into just what MVP is, it is important to first understand just what the concept is made of. The four parts of MVP are 1) Functionality, 2) Reliability, 3) Usability, and 4) Emotional design (which is three parts in itself: a) convenient, b) pleasurable, and c) meaningful experience). Too often developers, managers, and operators look to build and release more functions and features. Yet they have not even tested out one workflow, scenario, query, or user story to see if it resonates. Only the user can tell you whether you are providing valued output.
Whether it is the pace of the operating cycle, not over-engineering a design, or herding cats to obtain a healthy strategic dialogue, the term “valued” comes up constantly. However, my coaching on “less sooner” to our team begins with a question: “Tell me what you know about the MVP concept.” The three most common answers people give me? “No idea,” a joke about introducing yet another concept, or “Get the least amount of high-priority functionality I can deliver fastest.” They were close with the last answer. Unfortunately, they still miss the mark, like with the term “valued.” Feel free to take any potshots you want at my obsession with frameworks. I like to think it is a necessary evil.
A blend of Lean and Agile concepts, MVP is the new acronym du jour in development. If you are an Agile groupie who digs startups, then you know Eric Ries and his baby, Lean Startups. Eric brought this two-decade old term back into applicable use. The correct answer to my aforementioned question revolves around MVP, which attempts to obtain the quickest reaction possible from your client. It could be a simulated concept model, a new template not in final code, a design in mockup form, or a new configuration on cloud sandbox.
To all the sourpusses out there who remember the pre-internet days asking, “Is MVP actually new, or is it just some old, recycled concept in new hip phrasing?” I say, “Yeah… sort of.” Back in the client server days, we would mock-up the client UI and flow in rapid-design workshops with GUI editors, such as Visual Basic. Once our mockup worked on desktop, we would print it out and tape it to boards to review with clients, then rapidly fix them back at the client site. We would then do process modeling workshops while faking back-end data with the smoke-and-mirrors of Visual Basic in order to simulate the screen flows.
Use MVP to Get the User Reaction Before Building
It is easy for solution development teams to focus on quality and scope and forget about time during project design phases. In our field, unlike early phase product development, the mindset needs to shift to time as the number one driver – time to react, that is. When we do not focus on the user reaction element but instead focus on making cool, maybe complicated, possibly clumsy features, our first user experience is often the dreaded, “Hmm, that’s odd, worked on my machine.” Whether you were the offender or the victim, this likely sounds all too familiar. Either way, neither you nor your client valued that experience.
If your “designer” brain is hoping version one will solve your clients’ problems, then stop! Set aside your ego and get the architecture in place for the foreseeable functionality to begin. Be prepared for version one’s software, hardware, or data model to be a lot of throwaway. It is called “version one” and not “version done” for a reason. It might take longer to reach fruition, but since you have got them moving with MVP alphas and betas, you have already given them a valued output that you and your clients can build off. You have given them “less sooner”, along with the instant gratification of a small victory. Nowadays, our society is used to that instant gratification with data and information, making the return of MVP very timely.
Point being, a client’s end strategy may be a Cadillac, but your first phase needs to deliver a skateboard architecture to get them moving immediately. This is the heart of MVP. That the skateboard can then be upgraded to a scooter, then a bicycle, then a motorcycle, keeping the client moving faster and faster every time. By giving them incremental improvements in functionality, positive experiences they value, you can finally move on to the Cadillac architecture.
The Cadillac Analogy
What Less Sooner and MVP Mean for You
Not only does “less sooner” and MVP provide valued, positive experiences on a consistent basis, but it is also far more efficient way to develop a client solution. Imagine not using the MVP method, and you do all that work, only to discover it is incorrect or not what your client even wanted. Now you have wasted time and resources that you could have saved. However, had you simply used the MVP method for constant checkpoints to remain on the correct path. Remember…Valued Output. Less Sooner. Checkpoint Often. Timely Iterations.