MVP for Enterprise: Great Potential, Great Danger

Enterprise MVP — A Growing Threat?

MVP for enterprise is a growing phenomenon, reflecting the change of mindset of enterprise decision makers who, realizing the need for technology innovation and the power of agility, are open to new ways of working.

There are two major forms of MVPs for enterprise:

1. Internal Enterprise MVP — created by a specific enterprise for its own use.
   These are becoming popular as the methodologies of agility and Lean development originating in the startup world are being adopted by enterprises.
2. Startup MVP for Enterprise — created by a startup whose final product is intended for the general enterprise market. These are becoming increasingly popular as more enterprises are willing to collaborate with startups by becoming design partners or as early adopters of the startups’ MVPs.

While they share many positive and negative aspects, collaboration between startups and enterprises intensifies potential conflict between the innovative and Agile mentality characterizing startups, and the reliable enterprise mindset.

As a software system architect who works with startups developing for enterprise, as well as with enterprises eager to adopt innovation, I have been astonished to witness dangerous actions taken by people on both sides. In some cases, they were jeopardizing multi-billion dollar companies without justification.

I believe this is due, at least partly, to a lack of sensitivity to the disparities in work standards and mindsets. For this reason, I have undertaken to write a series of articles, highlighting some of the basic differences. My goal is to help create an awareness of the complexities of combining enterprise advantages with those of startups, and to promote the discerning approach of “Startup Innovation and Agility Synthesized with Reliable Enterprise Mindset.”

Solving the MVP-Enterprise Mindset Conflict

While some people regard an “enterprise MVP” as an anomaly, I believe that, with proper respect for the positive aspects of an MVP, as well as the enterprise mindset, it is possible to achieve an integrated approach maximizing the advantages of both.

The synthesized concept is based on the MVP model, whose attributes of agility and minimization of initial scope should be retained, but counterbalanced by a clear emphasis on the product’s viability from an enterprise perspective.

I have therefore chosen to refer to the resulting synthesis as a “Minimal Enterprise-Viable Product” (MEVP).

What’s at Risk?

If you are developing an MVP for a startup, your risk is limited mainly to the investment in the MVP. Setbacks could require additional capital for improvements or pivoting. Obviously, the worst-case scenario is having to give up, forfeiting the entire investment.

If you are part of an enterprise, however, using a non-viable MVP can potentially cause damage on a much larger scale. For example:

1. An MVP of less than a million dollars may be jeopardizing a multi-billion-dollar business.
2. An MVP that is intended to bring in new customers, or increase usage by existing ones, may instead endanger creditability with a client base which has been built over many years.

Startup/Enterprise Stakeholders’ Responsibility

If you are an entrepreneur developing an MVP for an enterprise, you must ensure that you fully comprehend the requirements of an MEVP. Having sufficient resources of both time and money are crucial elements for its success.

If you are a decision maker for an enterprise, who is considering collaboration with entrepreneurs, either as design partners or early adopters of their MVP, you must be wary. Although they may far surpass you in their understanding of innovation and technology — don’t take it for granted that they share your enterprise mindset, and will be able to provide the level of reliability required. This does not mean you should ignore the great potential in leveraging of emerging technologies. It does, however, require that you form a plan of governance for such endeavors.

Here are several examples of potential conflict between the startup MVP approach and Enterprise-Viability.

Enterprise MVP Process

If you are an entrepreneur developing a new standalone application, you can easily start off with users who are more “forgiving.” This can be achieved by gradual rollout. For example:

1. Start with an alpha using friends and family.
2. Run a beta with a wider audience who will be happy to give feedback in return for some small reward, or with the hope of impacting the product’s outcome.
3. Publish a free app that will become a paid app after feedback is accepted and the product is stabilized.

This process enables flexibility and change, based on client feedback.

If you are developing an enterprise MVP, however, you will not have the same “trial and error” privileges. Yes, you will still be required to do phased releases, and it would be advisable to do beta testing with a subset of customers. Nonetheless, it must be approved by existing business customers whom you cannot afford to disappoint. Especially if it is integrated with a CRM, an ERP, or other systems, excessive change may be overly disruptive.

An MEVP must be reliable and stable from the first release.

Design for Rapid Scale

As an architect, I believe that proper architecture of code and databases, along with the use of horizontal scaling resources, can enable seamless scaling, avoiding crisis situations or the need to dump your code and start from scratch.

If you are creating a standalone MVP, you can save development costs and time-to-market by making wise architecture decisions based on gradual scaling and actual usage patterns. If you are successful, you are likely to reach points of scale where changes should be made.

An Enterprise MVP will probably need to cope with large volumes of users and data in its early stages.

Examples:

1. For a startup, you can begin with a well-organized monolithic application, then later split into distributed microservices, when there will be justification for it. For an enterprise, you are more likely to start off with a microservice architecture.
2. For a startup that is not expected to amass large volumes of data in the short term, you can implement web client data grids with simple free client-side paging plugins, until there will be a sufficient volume of data to justify implementation of server-side paging. For an enterprise, even a minor feature such as paging can wreak havoc on the entire customer experience (e.g. tables of 50 thousand rows with client-side paging).
3. For a startup, you can postpone handling archiving processes until you have accumulated such a volume of data that it is affecting storage costs and performance. For an enterprise, your initial design of data, processes, and integration with other systems, must lay the foundation for archiving, even if the actual implementation of the archiving procedures will not be carried out in the first release.

An MEVP must be designed to support large volumes of users and datafrom the beginning, based on the actual needs of the enterprise.

Safe Leveraging of Open-Source

There is definitely increased adoption of open-source by enterprises. Although this trend can be very beneficial, several vital considerations for enterprise usage must not be ignored:

Licensing

Some of the open-source licenses are legally prohibited for enterprise usage. Due to a lack of awareness, this is often overlooked by startups whose product is in fact intended for enterprise customers.

Scalability

Not all open-source code has been battle tested with large-scale platforms.

Quality Assurance

While integrating open-source can save a lot of development time and cost, the need to fully test the open-source components cannot be ignored. A common false assumption is that, if there is a parallel enterprise version of the same open-source component, both versions must be sharing the same code base, and therefore be equally reliable. This has proven to be a wrong assumption. I myself have been surprised to encounter severe deficiencies in open-source solutions, which have parallel successful enterprise versions, both having been developed by the same well-known organization.

An MEVP can leverage open-source solutions, provided that they have adequate licensing and proven capabilities.

Automation of Business Processes

Entrepreneurs tend to postpone the development of automated operations, arguing that they will do some work manually themselves, or with cheap labor, until there is a large enough client pool to justify an investment in automation.

In many cases, this may hurt the customer experience and have a negative effect on client adoption. However, assuming you start with a free/cheap application with flexible enough SLA, the risks are limited.

With an enterprise MVP, you will be required, from the beginning, to handle operations of many customers. Inability to provide them with proper services and support can severely damage the enterprise’s existing customer base.

In an MEVP standard processes should be automated from the beginning,

Interface for Administration

Another issue ignored by many entrepreneurs is the development of an Admin Client Interface. All too often, one of the consequences is the necessity for a developer’s ad-hoc intervention with data directly within the database. The risk for a small standalone MVP is reduced if this developer is the one who is currently responsible for the code, and thoroughly understands the rules and implications of each data change.

For an enterprise, however, manually changing data in a database can have severe repercussions.

An MEVP should have an Admin Client Interface providing all required administration operations. This will guarantee that any change of data is validated, and all aspects of each operation are thoroughly handled.

Conclusion

We should be well aware that combining startup and enterprise mindsets can introduce conflict, and enterprises may be endangered by incorporating poorly designed MVPs.

Nevertheless, the great potential in these growing trends certainly outweighs the risks.

Startups who develop products for enterprises must understand their mindset and incorporate enterprise software standards.

Enterprises must strive to embrace innovation and agility, yet at the same time maintain their credibility.

Collaboration between startups and enterprises during developmental stages of a startup’s MVP can offer great value for both, and is therefore recommended, as long as the startup can ensure it provides a truly Minimal Enterprise-Viable Product 

Awareness of potential threats is the key to a discerning approach, one which synthesizes startup innovative and Agile mentality with the enterprise mindset of reliability and stability.

In the next article, I will discuss startup-enterprise relationships in the context of a startup MVP for Enterprise collaboration, and offer suggestions for maximizing the outcome for both parties.

We are anticipating great progress and expansion in this exciting arena.