3 ms·
I noticed one important point mentioned in the banking app example, but not elaborated on: Shirnk critical scope. By this I mean if you can produce a simpler
by Tade0 4y ago
I noticed one important point mentioned in the banking app example, but not elaborated on:
Shirnk critical scope.
By this I mean if you can produce a simpler version of whatever is that you're doing and have separate tasks for expanding it, do it.
Your e-commerce solution can start off with just one payment provider. Your form validation can initially respond with just "nope!". You don't need that color picker shaped like a peacock in your MVP.
Especially if these things prevent you from delivering something that someone, anyone can use.
Also half of such things become irrelevant and ultimately get dropped.
- spongeb00b 4y agoI repeatedly see features being placed into a "phase 2" that appears approx 90% into a project as the deadline looms. Half of those features eventually get implemented, the rest it’s realised are not needed at all.
- alkonaut 4y agoThat's the correct way of going about any software development. The problem though is the customer will likely be unwilling to agree to a contract that doesn't have at least 75% of the scope or the product is "unusable". Their existing/previous product is usually better all the way until every single feature of it is available in the new system (I have not yet in my career ever seen a system that isn't replacing a previous system - at least if you count an excel sheet or a piece of paper as "previous system"). What you end up with when shipping an MVP is you also convert a minimum number of users and you end up with two systems. The "MVP" is thus often "whatever allows all existing users to switch" which is why projects snowball to be too big and too late. You won't realize what people used the old system for, until you try to replace it. And it always turns out it has 2000 features when your discovery had found 20.