Building MVP for developers

Usually when building a MVP, the developer's focus is on getting things done and shipping as fast as possible. While this is a good thing to do - spending energy only where it is needed the most, it can result in an unusual problem. Many a times, when the product becomes a hit, the technical debt that has been accumulated in earlier iterations impedes rollout of features for larger audience in future and slows down growth. In other scenarios, the lack of a structured approach comes back to bite the developers hard, since they didn't think through all angles of the problem.

Developers usually end up making a lot of these mistakes early on in the development cycle, and the end cost is significantly much more as a consequence. So this problem inspired me to research strategies and best practices, that help one develop fast, but still avoid future churn.

In this post, I'm summarizing some principles that would be important to adopt early on:

1. Identify the opportunity before beginning the solution

It all begins with what market opportunity you have identified within your domain. Be sure that you understand the requirements from how your users would want it, and ensure that you've brainstormed on the requirements enough to have crystal clarity on the delivery plan. Know what your target customer segment is, and what they need.

2. Account for Biases

It is very easy to be blinded by assumptions. What works at one place may not work at another, and what works for one user may not work for other users. Try to think of the problem from the point of view of multiple customer segments, and identify the solution that would provide the maximum coverage. Every bias you uncover is an opportunity to sharpen your understanding of the opportunity you have

3. Establish success metrics early on

For every feature that you do, establish how would you check if it was successful or not. Build these metrics from both the technical and business angles, and get buy-in from any other stakeholders. This helps ensure that your scope is well defined, and makes the steps byte sized for everyone to follow. It is okay if the metrics are sometimes not monetary or performance related - but they have to be present to justify why you are spending time on this feature.

4. Ensure that you build for everyone in your target customer base

If this means having personalization, regionalization or internationalization then let so be it. Make preparations for this from the beginning if it is part of the end goal but don't obsess over it. Most frameworks have internationalization APIs and packages, use them for formatting your results. It is always better to externalize resources and never hard code, as otherwise you would end up doing technical rework and more quality checks. As general rules, avoid string concatenation, and make sure that your images are appropriate, i.e, they avoid metaphors and cultural sensitivities

5. Iterate based on customer feedback

It is very important to listen to what your users are saying in the early phases, but don't be blindsided by their comments. It is your job to figure out what the user is saying, and extract meaningful parts which apply to most of your customer base. Prioritize solving for issues that affect the larger customer segments.