Developing products in both directions
People who ever worked with me know that I’m not the easiest person to work with. Believe or not, this is the selling point. The hardest part typically consist of approaching things to be added: options buttons and screens. I tend to throw away a lot of stuff from designs and concepts, alienating people who craft those days and nights.
The hard part comes from having to say “no”. Having to convince others that “you don’t need that”, the other one too and the rest of it. It’s generally much easier to justify adding something in case of this or that, than to justify that those cases are irrelevant. The other hard part is having to structure products in a consistent way, sometimes against well invested thinking in how each part should work and look like. Structuring stuff in a generic way for the sake of consistency is much harder than structuring every single feature from scratch. You typically operate on a single argument of consistent design, stacked against a plethora of arguments why each part should have been designed individually.
Therefore many developers and designers I work with typically think that taking things out means disabling products, but I tend to think that opposite is true. Taking things out bears a lot of risk and takes a lot of discussion, however more often than not it’s worth it. There’s a gradation of arguments, with consistency and simplicity being the top reasons behind every single product decision, and there’s some room for a battle between them. Features and functions are secondary to both of them in every single case. Contrary to a popular belief, product development doesn’t mean “developing up” but works even better in the opposite direction. Stripping things out to the core leaves a lot of headroom for development of features that are really needed.
Oftentimes discussions boil down to a form of exchange: if you want add a feature to a product then tell me which one has to be taken away?