What makes it a good product
A few weeks ago one colleague asked me a question — “What makes it a product good?”. I am not a product manager but it seems to be an interesting question. As a developer, I know how applications are created and what problems they face.
From my point of view, it is impossible to create an ideal product. At least I haven’t seen one. But let’s define criteria and understand how to improve products even if they are not good enough.
Here is a short list:
- No bugs
- Stablity (not the same as a previous one)
- Support provision
And much more. The more we think about it — more points we will identify. So let’s stop to review everything step by step.
First, a product should solve a problem. It should make your life easier, better! If product creates a problem and later solves it — I would say it is just a business to earn more money.
To be on the same page, let’s take examples of every bullet point.
Bad: dad wants to read and edit notes on every device he has (laptop, PC, phone, tablet). So he finds an application, but here is a limitation to the number of devices. Dad was asked to pay an extra $5 just to keep data offline on his personal storage.
Good: a photographer has a problem with a big amount of photos and he needs to keep them somewhere. Here he meets cloud storages, which is great for storing big files.
It does not matter how fancy User Interface or Artificial Intelligence under the hood you have. If no one knows about your application — nothing makes sense. I do not want to say you should ignore user’s needs and not implement features, but do not forget to build a brand on the top of your product.
Bad: Look at the castle in the mountain without a road. There you can find tons of gold in that castle, but you have no clue how to get there. People do not know what they don’t know.
Good: Google Keep for example — small and simple application has not so many features. But every Google user at least heard about it.
Good #2: If you need (or want) to get a good Git client with simple and fancy UI — you will find GitKraken. You may find it in some comparisons, articles. But after a research with Google you may see targeting advertisement about GitKraken.
It can be mystical to someone, but I can say — it is possible to write a code without bugs. On the other hand, an application may have some logical bugs created by ideas or changes. You can find those bugs in time and in a specific use-case.
Continue reading the article and you will find an example on how to live with bugs. I do not want to copy-paste. :)
Downtime, that is when you have a chance to disappoint your user. Even if we are talking about Google, GitHub, etc.. When your application fails — someone will joke in a manner “Did you see it?”.
Bad: an app failed, not a single user has an idea why it happened and when it would work again, so they switch to another, more stable application.
Good: an app failed, and the user got an email with notification of the issue. Also, he can access a link and preview the status and progress. Just have a look at Bitbucket status page: https://status.bitbucket.org/.
Every action should be clear to the user, he should understand all consequences. After pressing Save — display the notification about its results. Every icon should have a title with short (even 1 word is enough) description to display it on hover.
Bad: User paid for something, found out that money was charged, but he got no notification on the email/phone/any messenger. As a result — user feels robbed.
Good: After paying for a GitHub account — you get the notification on email, also you can review the history of all payments.
When a user does something, he should be able to predict how it will work (save/delete/create).
Bad: I finished the article in one application, let’s call it “Writer”. But when I opened the article in the afternoon — I found out that a half of the article wasn’t saved. But I expected the application to save my file.
Bad 2: The same was with one of the biggest cloud data storages. In 2–3 days after uploading a file, I found it was corrupted by a service so I could not delete/change/download the file.
There were examples of bad user flow or bugs I found. For good, I would say the app should do what users expect and do not fail on primary use-cases.
Good: When you want to change your email — it is inside of an area which is marked as dangerous. Also, you see a message informing you “Changing email may corrupt integrations with 3rd-party systems”. And to change email you need to verify that they both are valid.
Okay, let’s return back to our bugs, how to live with them. A user should be able to get support and find an answer to his question. Even if it is a link to the documentation, forum or FAQ. Better than nothing.
Bad: I was trying to understand how to use one task management application, but there was no answer, help, introduction, link to any tutorial, nothing. As a result — I deleted the app.
Good: something went wrong. You see a pop-up which gives you an ability to contact developers, and you are sure that the issue will be fixed soon. Also, you get links to FAQ, useful status pages, etc.
Product evolving is amazing, but it’s like balancing on a rope. On one side an application can be transformed into a piece of shit, due to requested changes from users. On the other side, we ignore users needs. As a result, everybody is disappointed.
Bad: Say “yes” to all feature requests users make:
Good: think about user’s requests, analyze them, give a feedback, add new features without breaking the core idea.
Here I described my thoughts on how to improve the application, what makes it a good product. How to make users hate you. There are a lot of metrics, approaches to make something better, do not forget about it!
As soon as we are on the same page, let’s define some “mark” to analyze your project. Sum the numbers and write in a comment.
-  Problem-solving — Does your product make a life of the user easier?
-  Recognition — How many people at least heard about your product?
-  No bugs — What is the percentage of Open/Closed bugs? < 15% is ok
-  Stable — When was the last crash in production?
-  Transparency — Does your product fit GDPR requirements?
-  Predictability — How many users’ “bugs” you close as a “feature is not a bug”?
-  Support provision — Can you share FAQ/Forum/Bug Report System?
-  Activity — How often do you release to production?
Grade from 0 to 18:
- 0–8 — App is not good enough, there is a lot of stuff to improve.
- 8–14 — Product is good enough, maybe you have some clients.
- 14–18 — Totally great! Just a few steps to shine like a star. :)
Thanks for reading! Share your thoughts.
Originally published at apastuhov.com on May 14, 2018.