3 ms·

There shouldn't be any difference. The fact there are differences is a symptom of a broken procurement process where you get your specs from the person who has

There shouldn't be any difference. The fact there are differences is a symptom of a broken procurement process where you get your specs from the person who has purchasing power, or an executive, or really anyone except the people who'll end up using that software. If you have a saying, you can advocate to include those who will actually use the product. If you are not forbidden to get in touch with them (believe it or not, some execs will forbid you to include the people you're building for in the conversation), you can try and tighten the feedback loop. If you're designing to a rigid spec, then it pains me to say it doesn't matter: You will get paid but nobody will use your software. Those are the bitterest dollars.

deleted 6y ago
[deleted]
victorbojica 6y ago
It's not really about what you put in your product, but more of how you design your product to accommodate all the data, actions and processes required for the people to do their job and not look or feel like accounting software or some oracle tool
- Jugurtha 6y ago
  What you put in your product is indissociable from how you design it to accomodate users. As per my other reply, the problem is wanting to accomodate all users for all the data, actions, and processes. This clutters product. As per my other reply, one solution is to break functionality down. Keep the core tight, the rest becomes plugins that users install to solve their specific problems or a family of problems (categories). No product can satisfy everyone and all processes and actions and be useful at the same time.
anotheryou 6y ago
What about easy peasy vs power users? The cash register has more buttons than my keyboard and that's maybe a good thing. No consumer product would do that.
- Jugurtha 6y ago
  That's at the functionality level. You have the common parameters or settings, and then the advanced ones. However, the software contains many functionalities, for different customers. A functionality that is relevant for one customer is irrelevant for another, hence my reply on using a plugin architecture.

deleted 6y ago

[deleted]

victorbojica 6y ago

It's not really about what you put in your product, but more of how you design your product to accommodate all the data, actions and processes required for the people to do their job and not look or feel like accounting software or some oracle tool

Jugurtha 6y ago
What you put in your product is indissociable from how you design it to accomodate users. As per my other reply, the problem is wanting to accomodate all users for all the data, actions, and processes. This clutters product. As per my other reply, one solution is to break functionality down. Keep the core tight, the rest becomes plugins that users install to solve their specific problems or a family of problems (categories). No product can satisfy everyone and all processes and actions and be useful at the same time.

anotheryou 6y ago

What about easy peasy vs power users? The cash register has more buttons than my keyboard and that's maybe a good thing. No consumer product would do that.

Jugurtha 6y ago
That's at the functionality level. You have the common parameters or settings, and then the advanced ones. However, the software contains many functionalities, for different customers. A functionality that is relevant for one customer is irrelevant for another, hence my reply on using a plugin architecture.