Tag: Agile

Should USP be part of MVP

First of all, my apologies for the jargon, but this is a way to get attention of those corporate types who I hope to sell to. The MVP here in question is the startup-wala MVP (minimum viable product) and not the sports-wala MVP (most valuable player). There is no ambiguity to USP.

So it’s an accepted mantra in the startup world that product development should follow the “agile model” rather than the “waterfall model” (borrowing from software engineering paradigms). It is recommended that you put out a “minimum viable product” (MVP) out early into the market and get continuous feedback as you continue to hone your product. This way, you don’t end up wasting too much time building stuff the market doesn’t want, and can pivot (change direction to another product/service) if necessary.

The question is how “minimum” the “minimum viable product” should be. Let’s say that your business isn’t something that creates a new market but something that improves upon an existing product or service. In other words, you are building a business around “a better way of doing X” (it doesn’t matter here what X is).

The temptation in this case is to copy X and release it as your minimum viable product. This is rather easy to do, since you can just reverse engineer X, and put out a product quickly. That’s the quickest way to get to the market.

The problem with this approach, however, is that your initial set of users who experience your MVP will fail to see what the big deal about your product is – while they might hear your promises that this is only a start and you intend to do X in a “new improved way”, the first version as they see it shows no indication of this promise.

Worse, when your product is branded as a “new improved X”, it automatically gets anchored in your users’ minds with respect to X. Irrespective of what your product looks or feels like, once you’ve branded as a “new improved X”, comparisons to X are inevitable. And when your MVP is not very different from X, people might lose interest.

On the other hand, if you need to build in your USP into your MVP, it results in a longer product development cycle. In such cases, if the market doesn’t really want your “new improved X”, a lot more effort would have been expended, leading to higher risk (of market not accepting product).

Yet, if your MVP is nothing like what your “real product” is, then you are not really getting feedback from the market on your “real product” – only feedback on your MVP. And the MVP should be something such that you can make use of any feedback you get on it in terms of superior product design.

Agile programming and Parliamentary procedures

Supposedly the latest (ok not that latest – it’s been around for a decade) thing in software engineering is this thing called “Agile programming“. It’s basically about breaking away from the old “waterfall model” (which we had learnt in a software engineering course back in 2003), and to a more iterative model with quick releases, updates, etc.

I’ve never worked as a software engineer, but it seems to me that Agile programming is the way to go – basically get something out and keep iterating till you have a good product rather than thinking endlessly about incorporating all design specifications before writing a single line of code. Requirements change rapidly nowadays, and unless you are “agile” (pun intended) to that, you will not produce good software.

Agile methodologies, however, don’t work in parliamentary procedures, since there is very high transaction cost there. Take, for example, the proposed Goods and Service Tax (GST). The current form of the Goods and Service Tax is an incredibly flawed bill, with taxes for movement of goods across states and certain products being excluded from the ambit altogether. Mihir Sharma at Business Standard has a great takedown of the current bill (there is no one quotable paragraph. Read the whole thing. I’m mostly in agreement).

So it seems to me that the government is passing the GST in its current half-baked form because it wants some version (like a Minimum Viable Product) off the ground, and then it hopes to rectify the shortcomings in a later iteration. In other words, the government is trying some sort of an agile methodology when it comes to passing the GST.

The problem with parliamentary procedures, however, is that transaction costs are great. Once a law has been passed, it is set in stone and the effort required for any single amendment is equal to the effort originally required for passing the law itself, since you have to go through the whole procedure again. In other words, our laws need to be developed using the waterfall model, and hence have full system requirement specifications in place before they are passed.

It’s not surprising since the procedure for passing laws was laid down back at a time when hardly any programming existed, leave alone agile programming. Yet, it begs the question of what can be done to make our laws more agile (pun intended).

PS: I understand that Agile software development has several features and this iterative nature is just one of them. But that is the only one I want to focus on here.