Steve Blank - … We don't have a beta, it's a product with a minimum requirement

There are so many things that we would like to integrate into our software and then let our customers "test" them... This is often called a "beta version" and it reveals functions that we may not want at all later on. Why not provide the customer with a product with the minimum requirements? It's about more than just wording.

Some time ago I published a very detailed article about "Minimum requirements for your product", which I would like to recommend once more to you. In this article we'll call it "MVP" for simplicity, which roughly translates into minimal product requirements. In our last two posts, we've split them a bit more in terms of physical and digital products, now what exactly is at the end?

If you have planned and partially implemented all possible functions of your product, you can think about which of them might already be relevant for your potential customers. But don't let this get out of hand and really concentrate on the absolute minimum possible. In our case it was our video player with the ability to combine multiple voice tracks. When we finished it, we got our first customer feedback and gradually developed more relevant features. We always made sure that things could be used, marketed and monetized as self-sufficiently as possible.

In the past this was inconceivable and basically always happened according to scheme X. They had thought up a concept, calculated the costs, then set up financing, developed it, tested it and then went into sales. We also dealt with this, it is also called the "waterfall process". For many years, the fact that computers became faster and faster and applications more and more agile played into our hands. This makes it possible for us today to plan software much more easily and then develop it in applications with minimal requirements. Whereas in the past you regularly had to deliver betas to your customers (unfortunately this is happening again today! See Windows 10...), today you can focus on the core in many areas.

The essential difference already exists in the workflow. As I described above: Idea / concept ⇨ Development ⇨ Alpha ⇨ Tester ⇨ Beta ⇨ Tester ⇨ Sale of the complete package. Let's take the concept of the MVP, we will not define as a target version 1.0, record it on the drawing board and thereby incorporate all the ideas of the founder. We go to the customers and ask them what is important to them NOW to use this product and what it would be worth to them. Then we decide which functions we install.

And the golden rule: Even if it should look like a beta product - we don't use this word! It is a product, which we have developed perfectly for the customer and his minimal requirements, we are customer-oriented through and through.

This article is written by our CEO, Bernd Korz. With his experience as an entrepreneur, he shares his vision about the lessons provided by Steve Blank. Join us every week for a new article on Steve Blank’s lectures.

More information on Steve Blank:

• alugha Videos
• Google Search
• Wikipedia
• Amazon Books
• Twitter Steve Blank
• Twitter Bernd Korz
• LinkedIn
• Medium
• Website

#alugha

#multilingual

#everyoneslanguage