Minimum Viable Product (MVP)

Al Karlssen — Tue, 18 Jun 2019 09:46:27 +0000

A special form of the Lean method for startup is called " MVP - Minimum Viable Product ". MVPs should help founders, product managers and growth hackers not to develop products that no-one needs in retrospect.

How to develop a real MVP

Of course, again with the earliest possible market entry with the aim of getting real market feedback as quickly as possible. However, as an extension of the Lean methodology , MVP not only validates the startup
, but directly a working mini version of the product. Properly done, then the product can be extended on the basis of user feedback with always new functionalities and features.
Initial development times can thus be significantly shortened. However, the analysis effort increases. Is there a market for my product? What features do customers really need ? Which features are the most important after the MVP? A few MVP examples.

The big challenge of the product developers is to define in advance exactly which functionalities are really necessary for the user to generate enough benefits. It must not be too low a benefit, because then the user is probably lost immediately and above all forever.

A few examples of MVP features that are frequently discussed in product teams . Features that are often omitted in the first MVP because they do not ad hoc affect the user experience:

"Reset Password"
Payment function
Legally secure data protection and GTC texts
Automatic tests of the source code
Highly scalable staging environment
No "nice" design
Long loading times

Functionalities that, from my own experience, should always be included in the MVP:

Very good and easy usability
Ability to submit user feedbacks
Imprint

"If you are not embarrassed by the first version of your product, you've launched too late." Reid Hoffmann - Co-Founder of Linkedin

Tight schedules often stress the implementation of a good MVP, so that later the user is offered a not yet finished version instead of a very well working version 1.0 of the product. The product can not be finished, but the user must never notice this, especially not in the user experience. And please do not forget that especially the loading time of the application belongs to the user experience.

A phenomenon that can happen more often, especially in companies with multiple products. Assumption: The market is moving rapidly and the competition has presented a good feature. The product developers must therefore follow suit to equalize the lead of the competition as quickly as possible. The MVP is defined, implemented at record speed and put on the market. The sales department is congratulated and sent on the journey with the sale of the MVP. The work of the product developers seems to be done and you start directly with the next project or even the next MVP. From the perspective of sales people everything is optimal. They got their feature and win the sales pitches again. Everything so far, so good, or not?
No. This development is fatal for a company in the medium to long term, as it completely neglects the validation of the MVP at the customer. For a company, the worst case scenario is that it has many features and products only in the MVP status in the product portfolio, but none of them really impressed users. In the long term, users will not be satisfied with "unfinished" or "non-mature" products. At least not if the competition has only one product on the market, which is much better than the MVP version of this product.
For this reason, there is today the theory of the MLP - ie the minimum Loveable Products . This should certainly, that one does not just a small prototype on the market, which is then not further developed, but the core requirement that the users already like the product or might even love a little bit.

DevOps methods

Al Karlssen — Mon, 12 Nov 2018 09:12:48 +0000

Software development and operation in IT are two areas that traditionally work in isolation from each other due to their methods and processes. Both specialist departments can benefit immensely from each other and incorporate their expertise into the respective teams. Thus, the development of high-quality products can be delivered faster and a reliable operation can be guaranteed. DevOps is an approach that pursues exactly this goal, bringing together development and operations in IT companies
.

Methodologically, flexibility (development) and stability (operation) meet in the DevOps approach. Unlike agile methods that normally stop development, DevOps transfers the agile method to the entire software lifecycle, thus including operation in this method. The automation of these processes is the declared goal of the DevOps approach. This change means a big step for all participating teams but especially for IT operations.

Revolutionary DevOps methods

DevOps is methodically based on both technological and procedural levels, putting classic ITIL processes to the test. ITIL (IT Infrastructure Library) describes a structured process collection of best practices for service management in IT. ITIL is now part of the day-to-day business of many IT organizations that use the proven standard procedures to work economically and in a quality-conscious manner. Now, the innovative DevOps concept provides for "breaking out" of standardized processes, posing challenges for companies with stable process frameworks.

Technologically, DevOps offers development, code management, testing, and deployment methods:

Continuous integration.
Continuous delivery/ deployment
Integration into existing processes

Continuous integration

Continuous integration is a method of continuously assembling components into an application. Through continuous integration, the software quality is to be increased. In order for the components of the product to be transparent to all team members, artifacts serve to represent product components. DevOps uses continuous integration to target automated building of software artifacts from source code.

Continuous Delivery Deployment

Continuous Delivery is the next step in building on Continuous Integration. The aim of the continuous delivery is to (also) automatically deploy the previously automated artifacts. This means that the artifact is automatically tested and then installed in the production environment.

Integration into existing processes

Traditional companies have their established processes. Now DevOps has emerged from the understanding that standardized processes are no longer enough to stay competitive. Thus, the established processes are driven by higher customer requirements to adopt: DevOps is the driver.
A good starting point for implementing DevOps is to start at the process level. Here, for example, change management is a good idea. Change management according to ITIL is a process in which all changes to the IT infrastructure are controlled and executed with low risk. All adjustments are monitored and controlled according to the specified goals. If this process is redesigned in a transparent way, DevOps teams can more frequently replicate functionalities in production environments in a comprehensible way. The transparency ensures that the entire infrastructure is more comprehensible and thus more stable in the event of a breakdown, it can react faster and more directly.

Is your company DevOps-Ready?

What is the current status of your company? Would you like to use the innovative method to make your software development more efficient and to revolutionize the collaboration of your teams?

DEV Community: Al Karlssen