Ask HN: For a new product, do you favor simplicity or flexibility?
How do you decide whether a minimum viable product should favor flexibility* or simplicity^?
Do you focus more on breadth or depth?
If flexibility comes at the expense of complexity is it worth it?
If simplicity means you shrink your market size is it worth it?
Take cost of development out of the picture.
*flexibility: refers to how easily adapted the software can be to new users/markets. Could also refer to how rich of a feature set it has.
^simplicity: ease of use (UI/UX), how targeted the product is to a set of known customers.
4 comments
[ 3.6 ms ] story [ 17.2 ms ] threadfrom pg:
When a startup launches, there have to be at least some users who really need what they're making — not just people who could see themselves using it one day, but who want it urgently. Usually this initial group of users is small, for the simple reason that if there were something that large numbers of people urgently needed and that could be built with the amount of effort a startup usually puts into a version one, it would probably already exist. Which means you have to compromise on one dimension: you can either build something a large number of people want a small amount, or something a small number of people want a large amount. Choose the latter. Not all ideas of that type are good startup ideas, but nearly all good startup ideas are of that type.
Imagine a graph whose x axis represents all the people who might want what you're making and whose y axis represents how much they want it. If you invert the scale on the y axis, you can envision companies as holes. Google is an immense crater: hundreds of millions of people use it, and they need it a lot. A startup just starting out can't expect to excavate that much volume. So you have two choices about the shape of hole you start with. You can either dig a hole that's broad but shallow, or one that's narrow and deep, like a well.
http://www.paulgraham.com/startupideas.html
What about when depth adds complexity and over serves some of your users. Is it worth it at the early stages of development to spend the time keeping the software simple for those users who don't need the additional functionality but available to those who do? Or do you just leave all functionality in there that's required by all of your known users, train the early adopters who don't need the additional complexity to sift through it and then once your customer base is more representative of your market you worry about simplifying workflow?
https://firstlaw.wordpress.com/2011/10/18/ashbys-law/
According to Fred Brooks, manager of the project to make the first operating system for a 360 mainframe, there is "essential complexity" which is intrinsic to the problem, and then "accidental complexity" which you bring to the table.
You cannot get complexity below the minimum required by the problem (Ashby) but you can reduce accidental complexity. The first time you do something, however, your solution will be too complex in some ways, and it is very hard to remove accidental complexity once you put it in for quite a few reasons.