How to build a "simple" Product?
simple does not mean easy
It is hard to sell “simple” stuff.
Everybody wants complex, sophisticated, feature-rich products.
When comparing products they use feature matrix comparison, as if the more features the better.
However, not all features add positive value to a product. Some features can add negative value, and make the product too complex for the core use cases.
If you wanna build an easy product to use, it needs to be simple.
Simple is to have the minimal set of features or clicks required to perform a given action.
Reducing Scope
The first thing you need to do to build a simple product is to reduce the scope of it.
The scope is what you plan to build, and it can include many issues, tasks, requirements, and use cases.
The bigger the scope the more complex will be the product.
Reduce scope is saying no to a lot of “features” that sound good, but will cause more harm than deliver value
Every day try to reduce and simplify the scope to ship faster and ship a simpler product.
Another way to simplify is to have a hard deadline. When you have a deadline, the only way to deliver on time is to simplify.
Move most of the nonuseful requests to a v2, and you probably will never build anyway because no users ever asked for it.
MVP Mindset
An MVP is the simplest way you can build a feature or product to solve a given problem for a given user.
The MVP Mindset is to always try to build the simplest solution that can solve a given problem.
How can you solve this problem with fewer codes, fewer clicks, fewer components, and fewer interactions? How can you solve this problem with existing product features?
You should also use MVP when building a new feature for an existing product.
Instead of trying to simplify the product, you don't let it get too complex.
To have an MVP you need to reduce scope and remove features and requirements.
You need to keep only the essentials and avoid all complexity and +1 requirements.
Defaults and customizations
The more customization you add the more complex the software.
Avoid as many customizations as you can.
Prefer good defaults instead of providing customization.
The more customization, the more edge cases, and bugs you will have to fix and maintain.
Defaults let you simplify the customization you created for a few users.
The core or more frequent actions should be simple and require few or no configurations.
The defaults should attend to most of the users.
Prefer ephemeralization - “the ability of technological advancement to do ‘more and more with less and less until eventually, you can do everything with nothing’.”
Fewer clicks
If you know compression algorithms like Huffman, they provide fewer bits to frequent patterns and more bits to less frequent ones.
We can apply the same concept to clicks.
Common and core actions of a product should be easily accessed with just one or a few clicks.
A customization that needs to be modified once per year can have many clicks, as it won't burden most users.
Design System and Concepts
Design System can simplify design and the product because it adds constraints on what kind of components you can use, if some UI component does not exist in your design system you should not use it.
Prefer to reuse features and concepts than create new ones. A new feature requires more code, more tutorials, and more training, and increases the learning curve of the product.
Add constraints to simplify your product. The constraint of time (deadline), and constraint of scope (features).
Prefer to build a feature that solves many problems than one that solves a specific one
But be careful not to build too generic software that does not solve anything for any user
Simplifying an existing Product
Every day try to reduce and simplify the scope to ship faster and ship a simpler product.
I also recommend revisiting everything that you build and answering how everything fits together.
Your product is usually built by many people, so it is hard to keep consistency across the product features.
Going back and fixing this consistency pays off a lot.
Don’t be afraid to kill features or products if they are not working.
If they are not bringing enough value to your users.
If they added too much complexity, or if they are expensive to maintain.
Provide an upgrade path to existing users of this feature and move forward
Overall
All this work is like fighting entropy.
Someone is always trying to make your product more complex, and you should fight back.
If you listen to everybody and implement every feature request, in the end, everybody will complain that your product is too complex and hard to use.
That's what we are trying to do at Woovi.
We are trying to provide the easiest and simplest instant payment experience for businesses.
Our customers are non-tech people, so our onboarding and product needs to be very intuitive to use.