Minimum Viable Technology (MVT) — Move Fast & Keep Shipping
A technology team can be the biggest asset or the worst bottleneck for a growing company, based on their strategy. In the name of future proofing engineering, technology teams become a hurdle to a company’s goals. You can see the hidden frustration in Amazon chief Jeff Bezos' words below:
“Engineers should be fast acting cowboys instead of calm clear-headed computer scientists”
When the task is to build a bike, the product and technology teams would plan for a product that can later run on motor, seat four people, sail in sea and even fly in the future. This hypothetical building of castles in the air digresses the focus from the real problem to be fixed. This is what Bezos is suggesting to refrain from, as it wastes resources and agonisingly delays the time to market.
Being defensive, the product/technology teams usually build a cannon for killing a bird.
Minimum Viable Product (MVP) philosophy evolved, to avoid this ‘unnecessarily over-thinking and over-preparation’ problem that plagued products in all companies. It encouraged building the minimum required at a certain point of time and then iterating and improving it going forward. The MVP approach enables the much needed 'fast experimentation, fail fast and invest where needed' strategy.
But, no such philosophy evolved for technology. Therefore, the decades-old defensive and paranoid philosophy still prevails (which made sense during older 1–2 year-long waterfall releases). This becomes a competitive disadvantage for startups usually fighting for survival or growing fast.
The fundamental problem is that the engineers tend to ape the strategies followed by large companies, considering them to be the standard. But, corporates and startups differ widely on their needs of scale, brand, speed, impact of a feature, loss by a bug etc. Startups enjoy more freedom to make mistakes and they should exploit this to their benefit.
Strategies used in big companies are more often irrelevant and even detrimental to a small growing company’s interests.
Minimum Viable Technology: The solution to the above problems is to build the minimum technology that makes the product and its foreseeable further iterations viable. Make it live as soon as possible and then iterate and improve it based on real usage learnings. Every company is at a different stage of evolution. So something that is MVT for a big company can be over-engineering for startups.
If the task is to kill a bird, we should build a catapult/small gun to begin with. If that becomes successful and there is a need to kill more or bigger animals, then bigger guns/cannons should be built as required.
There is nothing so useless as doing efficiently that which should not be done at all, said management guru Peter Drucker.
Startups experiment a lot and only a few of them sustain the test of time. As per the 80–20 rule, only those 20 percent that are successful should get deeper technology investments.
Principles of Minimum Viable Technology (MVT):
- MVP + MVT + Agile is the complete package.
MVP is for product scope minimisation. MVT is for technology scope minimisation. Agile is for iterative technology execution.
- Most decisions can be reversed or fixed easily. Choose wisely by bucketing the decision properly into reversible and non-reversible ones and then judiciously decide how much to prepare for that case. (Read Bezos' two types of decisions).
It’s important to internalise how irreversible, fatal, or non-fatal a decision may be. Very few can’t be undone. — Dave Girouard, Founder and CEO, Upstart
- Re-factoring is part of the success plan: Getting to re-factor is a sign of success. Only components that are used and have evolved fast become complex, over time, and need to be re-factored. Be ready to re-factor or throw away and rebuild where justified.
The best code you can write now is the code you will discard in a couple of years' time. - Martin Fowler, Software Development Consultant
- Think long term, act short term:There is a fine line between under-engineering and MVT and one has to tread it carefully. Don't rush into execution without thinking completely, otherwise it will lead to more resource being wasted later. Thinking has to be complete and deliberate choices must be there to cut scope. The rule of thumb is discussing the ideal solution on board and then deciding what to take out of scope to make it MVT.
- Speed and quality must go hand in hand: Never justify the bad quality of your work by using the speed of execution as an excuse.
MVT is for scope reduction, not for quality reduction.
- MVP/MVT is applicable for every iteration/release: People relate MVP to the first release of the product only. But the truth is it applies to every stage. MVP/MVT need to be chosen from the remaining tasks at every stage. At no stage it is okay to waste time and resources.
- Deep understanding, conviction and confidence is needed for MVT: Going the MVP and MVT route entails taking bold calls like choosing a few tasks that need to be prioritised. While the defensive traditional approach sees people trying to cram in all tasks, fearing failure.
- Alignment across departments is a must for MVT execution. MVT reduces time to market in 80 percent of the cases by focussing on the core of what is needed. As per the 80-20 rule, only 20 percent will need re-factoring and re-architecture later. But often mistrust and friction between departments makes people look for faults in others. This leads to the engineers (and others) being defensive and over-preparing to avoid any mistakes. This is explained and solved in Solver Teams post. In this approach, all parties are in sync and are aware of trade-offs made while executing. So there is a strong understanding and support for such efforts.
Move fast. Keep shipping
* The term 'Minimum Viable Technology - MVT' is coined by the author.
* The article is based on engineering execution done in a startup from scratch.
This article was first published by the author on LinkedIn
(Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views of YourStory.)
