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:
- The options were progressive, with a few covering all use cases and a few covering more specific, high volume use cases.
- 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.
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!
