
Ask HN: For a new product, do you favor simplicity or flexibility? - Mertax
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?<p>Take cost of development out of the picture.<p>*flexibility: refers to how easily adapted the software can be to new users&#x2F;markets. Could also refer to how rich of a feature set it has.<p>^simplicity: ease of use (UI&#x2F;UX), how targeted the product is to a set of known customers.
======
PaulHoule
I would look at this

[https://firstlaw.wordpress.com/2011/10/18/ashbys-
law/](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.

------
randall
Depth. You should absolutely shrink your market size at first. You should go
for demand shaped like a well, not a lake. You can always spread out later.
But if your initial cohort of users absolutely loves your product, you will be
in a great situation.

from 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](http://www.paulgraham.com/startupideas.html)

~~~
Mertax
Thanks for the insight, this makes a lot of sense.

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?

~~~
randall
You basically want to do anything you can to get your first user, but then
after that just be as simple as you can.

