MVP allows you to have a product in the hands of users quickly, at a low cost. The sooner the product is used, the sooner you learn from real users to improve it. The best way to learn and evolve your product is based on usage. This is much better than looking at a blank sheet of paper trying to visualize how a system should work.
One of the challenges the MVP approach presents is that it can lead to lack of architecture. When building a product from scratch, the rush to deliver it may come at the cost of building a sustainable architecture. There must be balance between speed of delivery and internal quality. A minimum viable architecture (MVA) is required. This implies being able to develop new features quickly and then measure its impact . Your architecture must be optimized for it.
So how do we define what is the MVA? These questions help:
– How many users will use the system in the initial release? In the first 6 months? Within a year?
– Initial users will be internal, external, or both?
– How many transactions per second hope at launch? In the first 6 months? Within a year?
– What level of security and audit required at launch? Within 6 months? Within a year?
There are several other questions to guide the discussion. These questions help the team set the basic requirements to launch in the market. Even though you are not looking for the perfect architecture, you must seek what is good enough. The focus is on how much investment is required to launch and then set a plan to evolve the architecture.
Trying to build the perfect system is rarely the right approach. In case the product has a owners (a Product Owner–PO), then he/she would answer such questions. For example:
– There will be only five internal users in the first three months. Six months from now our first two external customers will be using them in pilot mode systems. A year from now we will launch the system to all customers.
– At launch there will be a trivial amount of transactions. Six months from now the traffic is moderate. Next year, the traffic will be extreme.
– Initially, we’ll add users to the system via an interface. In the future, customers will have self-service ID management. I expect this to happen in a year from now.
– We only need minimal security for the first version. For the pilot, we need security and complete audit.
Based on these answers, much discussion and resolution can be postponed to after the release of the first version. Why spend time on the cache strategy now? We can put out several ID management tasks for later too. You must avoid immediate discussions about requirements that will only come in the future. You should only implement the strictly necessary. But you must implement this minimum with awareness of the future possibilities. That’s why the MVA is so important.
This approach depends on discipline and trust between the product owner and the development team. Both desire the same result: the product is delivered quickly with a stable architecture.
[content_block id=4581 slug=read-lean-inception]
