Feedback is the lifeblood of any product, service or production system. Closing the feedback loop as soon as possible allows for the best outcomes as one can accelerate things that are working and correct things that are not. Without feedback, we’re just playing a game of darts in the dark.
Only when we cut a release can we begin gathering feedback, therefore it is imperative to release as soon as possible.
But how can we do that if the Minimum viable product is too large? For argument’s sake, let’s assume we have a well-formed MVP. The MVP is actually the minimum and it truly does not make sense to our users as a smaller release.
I guess we’ll just have to ship the MVP then? Not so fast. We can still release sooner than that without harming our users.
Key idea: Breakdown a MVP to non-user facing releases.
Let’s go over an example to show how to break down an MVP. At Battlefy we support many games. Some games have a match result API. We would use this API to calculate interesting stats. Using a combination of our experience and user research, we decide on a set of critical stats. This set of stats cannot be further broken down as they provide context to each other. None of them make sense alone or as a smaller set. This forms our MVP.
This MVP seems small enough for a single release. But what lurks in the shadows?
…and the stats are not showing up?
Turns out we’re overloading the match results API. When we ran the test session it was only a few users but the API fell over with more load.
In hindsight, we should have done performance testing against the API.
With a single release, we detected this too late. So let’s do 2 releases! We’ll do over and rewind time to release the planning meeting.
…and users are complaining all the stats are wrong.
What’s going on? We did test the feature, but it was for a limited set of data and failed to see the issue with the small sample size. Had we seen a larger variety of real-world data this issue would have been easily caught.
Note, with 20/20 hindsight, in step 2 had we logged a sample of the data it could have been used to inform step 6.
With two releases, we still encountered bugs that were hard to detect. So let’s do 3 releases! We’ll do over and rewind time to release the planning meeting.
… and insert yet another failure.
I hope you get the idea. We can add an unlimited number of releases before MVP to detect all sorts of issues, but the question is, how many releases do we need?
There isn’t a straightforward way on how to break down a MVP into smaller non-user facing releases. Ultimately it is a tradeoff. With many smaller releases, we can gather feedback sooner but at the cost of taking much longer to plan and implement. With too few releases we’ll get feedback too late to detect problems.
Once you are comfortable in your own abilities, one of the most powerful phrases is “I don’t know”. If you are respected, this will send chills down people’s spines. Use this opportunity to propose a smaller release to gather the data to resolve your ignorance. Apply liberally.
Do you want to make smaller releases? You’re in luck, Battlefy is hiring.
