From idea to MVP

Entrepreneurship and personal leadership are highly valued skills within any organization, but especially within modern flat organizational structures. So how do you harness personal leadership skills within a flat organization?

Where to start

I must admit, I did deceive you with this blog’s title. A good Minimum Viable Product (MVP) doesn’t start with an idea, it starts with customers’ need. Socially and culturally, the focus of entrepreneurship has always been on that one great idea that generates millions. The inception of a brilliant mind far ahead of its time. While those cases certainly do exists, there are downsides if you start with the idea. If you do so, you essentially end up making more assumptions about the problem it solves and you then need to find a market that matches those problems.

Effectively, you end up spending more resources in order to prove the problem is worth solving because it requires the implementation to validate the solution.

But this is not how it works, customers don’t care about your solution, story, or idea if it doesn’t solve their problem or needs. Therefore, the best way to start is to identify what needs solving to make the life of your customer easier. To provide a map for this journey, I’ve sketched the following diagram:

The goal

Before embarking on this journey, it’s a good idea to formulate the main objective. Many people make the mistake that the result of this process should be a minimum viable product under any set circumstance. However, this shouldn’t be the case. The main goal of this process should be to identify with a minimum amount of time and other resources if a problem is worthwhile to solve.

Of course, the solution is part of this process since it can put restrictions on value delivered. For example, if a solution requires you to address current

technology gaps it might not yet be worthwhile at the time even though the problem is still perfectly valid. The solution comes much, much, further down the road, so for now we’ll switch into first gear and touch on how to identify problems.

Identify Problems

Everybody in the world faces problems and it’s impossible to solve all of them at once. The first step therefore is to reduce the universe of problems to those you can and want to solve. This will also help to make clear which value you provide to a business by solving their problem(s). The first reduction of the problem space happens by identifying the customers of your business and picking one.

After this step, you can start by exploring the problems they face. This can be done through numerous method including but not limited to:

• Asking the target market directly
  You can contact your customers, or set out questions on forums and online spaces where they are most likely to convene. In addition, experts also share their problems in hope of getting the answer from others in the same field. For example on LinkedIn and Quora.
• Building a focus group
  Find the people in your organization who deal directly with the customers and receive their inquiries. If possible, include stakeholders and problem owners from outside of your organization to your focus group.

Luckily, whilst practicing entrepreneurship in an enterprise environment there is no shortage of problems waiting to be solved. After this brainstorm session, you should have an abundance thereof. The key is to decide which one to tackle first. For each problem, it is worth asking if it is really a root problem or merely a symptom. One of the ways that can help you get to the bottom of it and arrive at the root cause is by asking ‘why?’ five times. You can use the famous fishbone diagram for this (see image).

As you can see it allows you to identify all causes and note the details and sub details for each cause. This allows zooming in on the main problem and mapping all intricacies. This list of causes and problems is valuable not only for developing the solution but for marketing as well. You can use it to craft marketing messages to appeal to the various customers, whilst still providing a solution to their main problem. From this large list of problems, you can decide which problem to pick. There is no hard science, but you might want to use your own judgment to see which problems get you excited or which may have the most potential. The main condition should be that you can get enough support from the people involved to make it to the first version.

Design a solution

The next step is to figure out what the absolute minimum is that should be  done and develop a plan for its achievement. A software product most often consists of parts that are not strictly necessary in order to deliver value to the end-user. So after you have established a rough idea, ask yourself what part can be excluded for now. For example, often times it is not necessary to build a full-fledged admin interface for example.

It surely helps to operate the system easier, but you can do without it if the problem you want to solve isn’t targeted at admin users. Keep this in mind when designing the solution. Which component does the solution have? What are the  functional interfaces of the product? It helps  to use a modeling tool like ArchiMate  to sketch out the answer to these questions.

Just ship the product to the test users and facilitate configuration yourself. It makes no sense spending time on extra features before knowing if the solution is valid.

Be very liberal in what you scratch from the MVP, in some cases, you don’t even need a backend and a database! For example, you can just store all the data in the browser localStorage. Keep in mind that the main objective is to ascertain if the problem is worth solving and that the solution is a solution to the problem. The next step is to document all these choices and make sure that you create tickets for them and user stories where applicable. Not only do tickets and user stories help divide the work, but it also gives a general sense of time to market. It allows you to communicate progress to all the stakeholders and even rally colleague developers to contribute to your MVP.

Implementing the solution

This part is where all the fun and magic happens. So let’s fire up your favorite IDE and start developing. Be mindful though about some preconditions and our ultimate goal: ” To produce an answer to the defined problem of a client, as soon as humanely possible “.

To ensure that you do not waste time, try to use as much of the existing technology as possible, even if isn’t quite the best fit. Remember, the customer doesn’t really care about how you solve it.

Effectively we are taking a “non-recourse loan” out of the technical-debt central bank. Meaning, if we decide to abandon the solution, we don’t have to pay off this tech debt. But if we move forward we will eventually. To keep this tech debt manageable in the future, even in an MVP there are some functional areas you can’t really take shortcuts on. These are:

• Project Structure
  Your software does need to adhere to the logical structure of other projects in your enterprise. For example, builds may need to produce Docker images. It may need to be built with certain build tools, include documentation, and the front-end and back-end should be split up.
• Good conding practices
  You might tackle, the MVP alone, but you still should develop as if any member of the team can drop in at any time. This entails that you document your code, keep a clear separation of concerns. Keep in mind an MVP is not a prototype. A prototype can be discarded, but an MVP can be built upon in the future.
• Seperation of concern
  Whilst this is also a part of good coding practices, separation of concerns deserves a special mention. If you speed up on implementation details, it is of quintessential importance that your domain, repositories, and APIs are defined well. This allows to swap out parts with a better implementation if deciding to go forward after the MVP phase and prevents a lot of  headaches.
• Development Workflow
  While it might be tempting to skip steps in the normal development process in favor of time to market, this is not advisable. Going to market fast does not mean that you shortcut the process which guarantees a stable product. Decisions made should be reviewed by peers and deployments should be tuned to play along with the rest of the instruments of the DevOps orchestra. Not only is this vital for support by the rest of the organization, but it also ensures the base is sound enough to iterate on in future versions.

Evaluate the solution

So now that we’ve developed a solution the next step is to distribute it among the stakeholders and collect feedback and observe interactions. The best course of action at this point is to meet with all the stakeholders again and discuss the results and observations. Decide if it worth to continue, to take another approach, or to abandon this problem and move to the next one.

Conclusion

As you probably have noticed a lot of the process of building an MVP is to actually speak with people who are experiencing a problem and testing if it is really a problem. The implementation of the solution is much less important as long as we can demonstrate that it solves a problem worth solving. This way, we can test out the waters before becoming too invested and end up with a product happily received by the customer.