Learn how to Build and Evolve your MVP from Ironman

As product managers we all live by the philosophy of MVP, that is minimum viable product. And for those who are new to the trade the biggest challenge they face is to understand what the right MVP for their product is.

While watching my favorite Ironman movie series especially the first one for the nth time, it dawns on me that I do not have to go further than the Ironman suit itself to understand the MVP concept.

In this blog I will take you through the journey of evolution of the Ironman suit from Mark1 right up to Mark 3 explaining how the evolution of the suit sets a great example of the minimum viable product. 

Note: A quick pre-requisite for the blog would be to see the first movie in the Ironman series if you have not already done that (I will be surprised). 

Building Mark 1:

Defining the problem:The idea of making the first suit Mark 1 was conceived by its ideator and inventor Tony Stark when held captive in the caves. Mark 1 was built to address a specific use case that Tony wanted had identified (he did not have whole lot of options in this case) and that was to escape out of the captivity.

Like a startup Tony had limited resources as he was being held hostage in the confines of the cave and also limited time to get it done, again similar to a product situation where product teams are running against the timeline to do go to market.

Lesson:

So, stripping the flab out of your problem definition is very critical.

Understanding the barebone requirements to solve the problem:

For Mark 1 Tony figured out that with limited time and resource he has to build the just the thing which help him escape and he had to build only those functions which can serve the goal or the use case in hand. The solution he identified was building a suit considering the below mentioned requirements:

1. To protect himself when attacked by his captivators.
2. To be able to attack in limited fashion if required to make a way for himself, basically to go offensively defensive.
3. Catapult himself out of the current location to some far-off safe space and land safely.

Lesson:

This shows that, as a product manager you should be laser focused on just the requirements that can help construct a solution to precisely solve the problem. For which the problem definition has to be as crisp and as niche as possible.

Constructing the product features to meet the requirements:

Based on the above requirements he had to figure the least possible functionalities and features to meet the requirements identified:

1. The suit to be bullet proof and strong enough to take any spraying of bullets even in the close proximity. In simple words strong enough to sustain the attack.
2. Weaponry to thwart any attack and since the primary use case of weapon would be to clear off obstacles for escape, fire made sense.
3. To build flight capability to take him somewhere away from his current location.
4. Last but not the least an engineering requirement, to build a power source which can sustain the heavy suit movement, the flight and most importantly keep him alive.

Prioritizing the features to meet the end goal only:

In-fact in order of prioritization the number 4 tops the list as everything else just fails if this is delayed or succumbs to non-feasibility. Then having a powered metal suit to protect himself, followed by flight capability and lastly the weaponry to attack. So below is how the prioritization stands:

4 -> 1 -> 3-> 2.

Lesson:

So, the idea here is to prioritize the core and most important feature or function first and save the good to have for the end. So that even if you are unable to meet the timeline it is the least important feature in comparison to others that gets pushed out and your product is still in a shape and ready for the go to market.

Compromise to align with the use case:

As a typical product manager doing an assessment for the MVP, with limited time and resource, you have to make some judicial well calculated compromise and Tony did the same with Mark1. Below are some of the compromises:

1. Building limited weaponry, just to get through the obstacles.
2. Build for onetime flight instead of sustained flight.
3. Use heavy metal sheets instead of something light for protection as per availability.

Lesson:

Whatever compromise we have to make due to limited time or resources we have to ensure that the core objective to meet the use case requirements never gets impacted while anything extra other than that solves the problem can be pushed for future development.

One other very important pillar to this MVP building process is ensuring quality in whatever we decide to build. Quality is an unsaid mandate, whether it is 1 or 100 features, all should work as intended and making sure all the features come together to make it work as one solution so that your MVP succeeds at least in the first customer proof of concept.

Building Mark 2:

Once your MVP is successful with your sponsored customer or the one with whom you are doing the proof of concept and has proved its credibility to serve the identified use case, it is time to evolve the product. But bear in mind that at any stage there will always be an MVP evaluation required as resources will always be finite, and the evolution of the product has to be a continuous process.

After escaping from the captivity with the help of Mark 1 suit, Tony Stark wanted to expand the use case for the armor suit to make it completely go for offensive defense with enemy of any scale.

While building Mark 2, Tony had the feedback from Mark 1 to improve upon, fill in the compromises made in Mark 1 and scale it to cover the wider use case resulting into a wider spectrum of requirements like:

1. To support the sustained flight.
2. Have power source to support the sustained flight.
3. Have full scale weaponry for assault and not just for defense.
4. Lighter but stronger material for the suit to make it more agile.

He was building functionality into Mark2 to meet the absolute desired requirements only. He was still not pushing for the value-add features or stressing on just the look and feel before the product proved its worth in the beta test.

Lesson:

The Product Manager has to have the vision in place for the product, but always align to build for the current use case identified. The requirements and then the features based on the requirements, all need to align to serve the identified use case and their expansion should synchronize with the expansion of the use case.

Building Mark 3:

Finally, Mark 3, where Tony Stark fixes all the bugs that he identified during the Beta testing of Mark 2 especially the sev1 like the icing problem at a higher altitude and also throwing the whizzbang to give the edge and make it completely ready for the combat. 

Lesson:

Once the base ground is covered, with the critical issues identifies and fixed, you can throw in the whizzbang with the look and feel and push in the features for more value add to the product. This will help you achieve two things with the product:

1. Make the product market-ready for general availability.
2. Give an edge to the product over its competition.

But all the whizzbang and value add will make sense only and only if the base use case(s) are being addressed by the product and has a predictable performance which can only be attained by ingrained quality.

Conclusion:

Tony Stark was the Product Manager, the Engineer, and also the User of the Ironman suit. So, maybe that makes his job a tad easier in understanding and defining the problem statement, capture the requirements, and then constructing the feature set for it. This will not be the same for a Product Manager in real life as he/she in most cases will not be the end-user of the product they are building. So, the only way to make up for it is to always be in the user’s shoes and build to address his/her problem.

I would name this MVP process as – Mark 123

Cheers!