Applying MVP in IT FTW!
A Minimum Viable Product is a core concept in the software development world. However, the reasons why an MVP works for software development are not always applicable within an IT organization.
I’d like to take some time to highlight some important differences within IT organizations vs. Software Development shops and how an MVP could be adapted for IT organizations.
What is an MVP?
A Minimum Viable Product is exactly what it says it is: a minimum and viable product. But that self-describing, obvious, literal word parsing provides no contextual understanding of how to use it and why we should care.
In order to understand what an MVP is and how to use it effectively, it’s important to understand the context and origin of it. When terms like “MVP” become popular, there is a tendency for people to leverage the term for their own benefit. By applying it to everything they sell/offer, they dilute the meaning of it. Understanding context helps fortify our intellectual capacity to recognize the inevitable dilution that greed, envy, cargo-culting, and group-think causes.
The concept of a “Minimum Viable Product” was born from the “Lean Startup” movement coined by and evangelized by Eric Reis. Eric Reis is a tech entrepreneur and a disciple of Steven Blank. Steven Blank is most famous for “Customer Development” and his book The Four Steps to the Epiphany.
Customer Discover, Customer Validation and Product/Market Fit
Steven Blank’s “Customer Development” is the belief that it’s not sufficient to do product development alone, companies need to develop customers. And customer development has a strategy, process, and complexity all of its own, just like product development.
The first step of Blank’s four step epiphany is “Customer Discovery” and you do it by “getting out of the building” and learning from them.
In a startup no facts exist inside the building, only opinions. — Steve Blank
You cannot discover who your customers might be if you do not talk to people, learn their pain/problems, and then offer them possible solutions that they think could help them.
Which brings us to the second step of the epiphany: “Customer Validation”. They need to believe in the value of your product enough to buy it with actual money.
That’s the literal definition of a customer. Your discovery is not validated until they buy your product. Don’t be distracted by engagement, eyeballs+ads, big-brother/big-data strategies; they still develop customers even if their users are the product they sell.
The process of discovery and validation, is the cycle of getting a good “product/market fit”. An MVP is an essential tool to determine product/market fit. That’s the context.
Using an MVP
So why is all this important when discussing an MVP? An MVP can be thought of as a hypothesis of “product-market fit”. We may believe we have a great product, but if there are no customers, it’s not a viable product to build a company around. Ideally, we want to discover and validate our hypothesis with minimal investment of resources. Hence, “Minimal Viable Product”.
If an MVP proves to be in sufficient demand at a price that sells, then you have validated your customer discovery process and have made progress. Eric Reis asserts this principle:
Progress in manufacturing is measured by the production of high quality goods. The unit of progress for Lean Startups is validated learning-a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty.
The fundamental assertion underlying this is that product development progress is about validated learning. You need to learn what product people will buy.
If you talk to your friends and family, they may encourage you because they are your friends and family. They may say “that’s a great idea!” or even “I would buy that”. And no doubt, they mean it. But it’s still theoretical and based on what they see in their mind’s eye, not something tangible they find online or see on a shelf.
In the real world, until someone buys it, it’s not viable. You want to learn product/market fit with the minimal amount of product development. Product development is expensive and risky; minimizing expense and risk is a good thing.
If the hypothesis fails and the MVP is not viable, lean startup advocates a “pivot”. Once you’ve learned that your hypothesis is not viable, try something related, but sufficiently different. It can target a different market or be considered a different product.
Why does an MVP work?
If you’re enough of a capitalist to believe in positive market forces, then you can understand how an MVP tests your product within a market. Consumer choice and vendor competition guides the invisible hand.
The reason why an MVP works is that it gets real data that you can bank. If people buy your product, you have found product/market fit. An MVP is a vehicle for Customer Development. Once you discover the wheel, over time, you can build a car. You can iterate on an MVP and learn about your customers through every iteration of the MVP.
But the important philosophical shift required to leverage an MVP is to see your organization as one of learning about people. Indeed I could, and would, assert that our life’s path is learning about ourselves and others. This is no different.
A core component of Lean Startup methodology is the build-measure-learn feedback loop. The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible. — Lean Startup Principles
IT vs. Startup distinction
In regards to an MVP, there is a big difference for IT organizations vs startups. The advantage, and disadvantage, for IT organizations is that their “customers” are IN the building.
Let’s talk about the advantage: IT organizations (should) know exactly who their users are. They should be reasonably certain who their customers are (different from their users). In other words, “Customer Discovery” isn’t really a thing, most IT organizations can simply look at the org chart.
This is also the reason why IT folks (myself included) prefer to talk about stakeholders rather than customers. It more accurately describes the dynamic that’s involved. The dynamic within IT is less constrained by monetary transactions for services and more constrained by the application of technology towards shared purpose/goals, mindful of periodic accountability.
So why is it a disadvantage? Because an IT organization’s “market” has little or no choice or competition.
No choice, No market
For capitalism to work, certain things need to be present. One of those things is people having a choice to buy your product, buy a competitor’s product, or ideally, not to buy anything at all.
This last option is sometimes called the “null-choice” and is an important factor to consider. Consumer power is greatly enhanced if they can do without your product or your competitors. Not all markets have a “null-choice” and consumer power is typically weakened in a market they can’t easily walk away from or at least postpone purchasing.
The problem for IT is that there is limited user choice within systems that IT supports, purchases/builds and integrates. There are few competitive offerings to drive prices down to benefit consumers. And there is often no good null-choice. If you’re not in IT, how often do you feel like you’re being held hostage by IT?
The fact is, the building blocks of modern IT services are typically purchased rather than built. With the emergence of SaaS vendors, the build vs. buy calculus is heavily skewed in favor of buy. Modern IT’s work is mostly about integration, configuration, and customization. Therefore an IT organization doesn’t really have “competitors”.
No competition, No market
While it is possible for business units to independently commision outside services to accomplish their IT goals this isn’t common practice in most healthy organizations with a centralized IT department. Business units generally work with IT and there is a cooperative/collaborative relationship between IT staff and external vendors/contractors/consultants.
For startups, the game is different. VC’s and experienced entrepreneurs want, accept, and identify competition. Competition defines a market. There may be non-obvious competition or outdated competition, but in a healthy market, there should be some competition. The key is to identify what advantage your MVP has over that competition and leverage it. (Yes, there are completely emerging markets, but they are extremely rare and very risky.)
The main point here is to say the dynamics for a entrepreneurial startup are very different than IT organizations. We must acknowledge and understand those differences before we attempt to apply an MVP within IT.
Notice I’ve only discussed differences of viability so far. What about minimal?
Minimal or Viable? Pick one?
This is kind of the “iron rope” of MVP. Which do you emphasize? Consciously or subconsciously, there is usually one that organizations naturally favor over the other.
If you are well funded, viability tends to get more of your focus. Why? Because the point of “minimal” is to do the least amount of work (i.e. least amount of investment of time, money, and resources) in order to test your hypothesis and complete a learning cycle. If you have more resources, work can, and often will, expand to consume those resources.
If you are a perfectionist, arrogantly believe your own hype, or ignorantly chase the unicorn, you will emphasize viability over minimal.
The irony is that short cycles lead to more learning in less time, which only helps determine viability. By NOT aggressively leaning into “minimal”, cycle time is increased and the ability to find “viability” is reduced. These dimensions push and pull each other in complex ways. This is the art of the MVP practice.
In well funded IT organizations, minimal is usually not as minimal as it should be. Organizations are hesitant to allow their IT departments go belly-up and their colleagues fail.
Because of the lack of this market force, there is a tendency to keep putting good money after bad. We don’t like to “throw the first one away” much less throw away anything we’ve worked so hard to build. Letting go is hard. IT “pivots” are also more rare and more nuanced because there is no bottom line score.
Well funded IT organizations typically push deadlines rather than cut scope. This further delays the cycle of learning.
And let’s face it, many “Enterprise Systems” suck. Enterprise systems suck because their viability isn’t tested as ruthlessly as Consumer systems. They are not forced to be minimal enough by virtue of limited market forces, therefore viability suffers.
I believe there is some benefit to being slightly under-funded. Not underfunded in PaaS tooling, but in terms of specific project based funding. This tension forces organizations to be more minimal than they want or like. It forces them to innovate faster. Because of this, IT organizations should make a conscious decision to ruthlessly embrace minimal. Enterprise, disrupt thyself.
Create Virtual Market forces
So how might IT apply an MVP in ways congruent with market forces? It’s a tough problem and that’s the challenge. I don’t claim to have the answer.
One way to leverage an MVP is to create a virtual market by running multiple systems side-by-side. IT organizations can do this for a limited time until one “wins”. This is the idea behind A/B testing and works well for cheap/fast/easy changes to web pages and such. Try both, test, and measure.
What if it’s not that cheap/fast/easy to setup these systems? Enterprise Systems YAY! What do you do for these kinds of systems?
Option: Outsourced MVP
If there is no existing system, organizations often used shared spreadsheets. Throwing Airtable at this problem isn’t a wrong strategy. Start there and leverage Airtable’s API for more capable/custom systems if necessary.
When people use spreadsheets as a database, it’s a strong indicator of IT’s deficiencies. Do not fear or squash Shadow IT gap analysis; use it.
If there is an existing system, evolutionary side-by-side migration can work well.
Option: Side-By-Side Migration
In these situations, IT is migrating from one system to another. While the eventual “winner” is predetermined, IT can usually find a way to run these systems side-by-side for some period of time.
In every system migration, there is always a “cutover”weekend/evening/period where the old system is retired and the new system becomes the “system of record”.
Many IT organizations declare a specific date and coordinate a bunch of activities like user training, data migration/conversion, user story/given-when-then scenario documentation, various forms of testing, etc. And then they do a big release all at once. Users show up on Monday and are expected to apply this training seamlessly. Data is expected to be converted cleanly. There is no feedback/learning cycle. And then the fun begins…
Instead, do not declare a specific cutover date, but work the process. Run both systems side by side. Until the cutover, the old system still serves as the “system of record”. The new system can be used for testing purposes if a specific example comes up or users want to test a certain use case.
The key is to allow users to play with the new system whenever they want to do so without negative consequence.
Running systems side-by-side can allow users a far better sneak peek as to what their lives will be like after the impending cutover.
When to cutover can be their choice. Or, at the very least IT can get a few cycles of solid feedback before you decide to flip the switch.
Now you’ve introduced some market based forces back into the mix. There’s some choice and competition. You’ve incorporated some amount of user agency in the product development cycle rather than relying on sterile and often synthetic user acceptance testing.
Milestone dates can be useful to time box progress and discover “minimal”. This is very much an Agile idea, however it’s only useful here if you actually deploy after each sprint and get feedback from it. If you practice a variant of a “water-scrum-fall” Enterprisey-type Agile process, and do not deploy regularly, you cannot leverage the benefit of a time boxed feedback loop effectively.
Finally, if the data migration applies my Rules For Data Conversions, it will run frequently and can be segmented to include current/dynamic data. If users can see real and recent data in the new system, the quality of your feedback will go way up. It gives IT the chance to clean up data further, or even adjust fundamental models and architecture while maintaining business service continuity. This drives minimal and viable.
Option: Ruthlessly Minimal
If your IT organization tends to emphasize viable more than minimal, there may be non-obvious ways to cut scope further.
Be willing to play messy small ball. Brainstorm and explore ways to decouple interdependent systems by using adapters, proxies, and/or other integration patterns. Hack. Divide and conquer. Be ruthless. Progress is better than perfection.
Final Thoughts
MVP’s are an invaluable tool for finding product/market fit within the context of Customer Development. They can work for IT organizations, but only in the right conditions and only if those conditions are understood. I hope this blog provided some context and helped clarify the hows and whys of using MVPs within IT.
