MVP: Solving for the Lowest Common Denominator

SingleSprint

June 26, 2020

Every agile sprint gets us one challenge closer to solving big problems for our clients. This series aims to share those incremental problems, fixes and results.

Problem

One of our small product development team’s is working with a growing leadership development firm. We were brought on to design and implement an MVP (minimum viable product) solution aimed at automating their assessment reporting processes. When designing how an assessment project, and the participants in the project, would be defined, we had MANY options. Several ideas were exchanged between our team (SingleStone and client), but given the MVP nature of our working agreement (tight timeline, budget), we could only pick one approach.

Fix

To facilitate the decision making process, our team put together simple sketches of the options to represent flow, estimated the effort of each option, and annotated with important decision criteria. In that process, we realized a few key things:

  1. The options were progressive, with a few covering all use cases and a few covering more specific, high volume use cases.
  2. Some options were significantly more effort comparatively and would require trade-offs in order to maintain MVP timeline and budget.

We knew that for every project, our client would need to be able to add individual participants, at a minimum. Our team presented the options to our clients, and with skepticism, agreed with our recommendation to move forward with the simpler option that covered all use cases. The more complex options were kept in the product backlog, prioritized for near-term enhancements post MVP.

MVP automated assessment and reporting process

Results

With MVP’s, you have to keep it simple and solve for the majority. From there, you have a baseline from which to enhance, make things easier, etc. We called this “solving for the lowest common denominator” when evaluating options, and I have used that tag line effectively several times since. In just a sprint, we designed and implemented a solution for creating new projects and documenting the various types of participants.

By making this choice, the team was able to maintain space in the plan to learn and adapt as MVP design and development continued. There were larger, more important, problems to solve as we moved forward. Ultimately, by focusing on the lowest common denominator, we delivered an end-to-end solution faster, and then identified the most important areas to invest remaining time. Those areas were far more critical to the success of MVP.

How are you using the MVP approach? Better question, are you looking for a new gig? Come work with us!

Sign Up to Hear More

Get notified when more posts like “MVP: Solving for the Lowest Common Denominator” are available.

  • This field is for validation purposes and should be left unchanged.

Gray Hollins

Lead Consultant
Gray Hollins, our Software Solution Lead, firmly believes that your organization’s approach to technology determines whether or not your systems serve as an anchor or an accelerator. He leads a talented team that create high-performing software to support our clients’ business goals. In his spare time, he's a busy family man, sports fan and bass guitarist in original Americana bands.

Leave a Reply

Your email address will not be published. Required fields are marked *