How to build MVP like an architect?

For a successful solution, always put the customer first, while taking care of architectural constraints. Think backward from the customers' needs, determine what is critical for them, and plan to deliver your solution in an agile way. One popular method of prioritized requirement is MoSCoW, where you divide customer requirements into the following categories:

• Mo (Must have): Requirements that are very critical for your customers, without which the product cannot launch
• S (Should have): Requirements that are the most desirable to the customer, once they start utilizing the application
• Co (Could have): Requirements that are nice to have, but their absence will not impact the desired functionality of the application
• W (Won't have): Requirements that customers may not notice if they are not there

You need to plan an MVP for your customer with must-have requirements and go for the next iteration of delivery with should-have requirements. With this phased delivery approach, you can thoroughly utilize your resources and overcome the challenges of time, budget, scope, and resources. The MVP approach helps you to determine customer needs. You are not trying to build everything without knowing if the features you've built have added value for the customer. This customer-focused approach helps to utilize resources wisely and reduces the waste of resources.

In the following diagram, you can see the evaluation for a truck manufacturing delivery, where the customer wants a delivery truck that gets delivered initially, and you evolve the process based on the customer's requirements:?

Here, once a customer gets the first delivery truck, which is fully functioning, they can determine if they need a more significant load to handle, and based on that, the manufacturer can build a 6-wheel, a 10-wheel, and finally, an 18-wheel truck trailer. This stepwise approach provides working products with essential features that the customers can use, and the team can build upon them, as per customer requirements.

You can see how the MVP approach helps to utilize limited resources in an efficient way, which helps to buy more time and clarify the scope, in comparison to an approach where we turn up the first time with an 18-wheel truck, only to find out

we only needed a 6-wheeler. In terms of the other factors, when you put the working product in the customer's hands early, it gives you an idea of where to invest. As your application has already started generating revenue, you can present use cases to ask for more resources as required.