University. Lecture on higher algebra. A professor proves a theorem at the school board.
- It’s obvious that in this case A is a sub-group of B.
The professor keeps silent, falls into thinking, looks at the board for 5 minutes and goes out of the lecture hall.
In half an hour he comes back very cheerful:
- Yes, this is really obvious.
Short introduction
When I studied at the university, a wonderful scientist world-known for his achievements in higher algebra and having a couple of theorems named after him gave us lectures.
He worked with the students from the secondary school passing his sincere and fanatic love for mathematics. And as many talented scientists he had a very specific ingredient of character. From time to time, the professor forgot that he was talking to newbie students and started explaining the information in the way that implied us, students who has just graduated from school, have the same knowledge and expertise of the topical area as well as scoop that he had.
It inspired and motivated some of us making us get deeper into the science and try to understand what the professor talked about and understand peculiarities of his discipline. But most students just didn’t understand him, fall asleep and tire of the classes. Excessive difficulty on the initial stage demotivated and pushed the students off.
Some background
It so happened that we develop reporting and data visualization components, products that are used by both developers and designers who are far from programming (I won’t give more details not to be blamed for the products advertisement). It’s necessary to explain that this is a highly competitive market in which on top of everything else such business sharks as Microsoft and some smaller companies (that are nevertheless are big comparing to us) reside.
That is why we needed to differentiate and find our own niche. Our mission always was “to allow the user working with our components solve any, even the most complicated challenges”. And we had enough users for ten years. Usually, they were developers who wanted “to do something very specific”, something that the products offered by the big competitors and unified to address almost all requirements were unable to do.
But at some point we understood that the market of lovers of “something very specific” was too small for us and that we needed to grow. And here we faced problems that arose only when we had to struggle for our customers with the competitors (big and not too big). We left the blue ocean and got to the shark world.
To see the way
At this moment we understood that to compete for the common user who doesn’t need “something very specific” it is necessary to make him be able to solve his task with our product. Obvious, isn’t it?
In fact, it is important, but not primary. To my mind, the user should be able to see the way in which his challenge can be solved, to make him absolutely confident that our tool really suits him. And he must make sure of it very quickly.
From the first sight, it seems that one month trial, extensive samples library, detailed documentation and technical support we provide to all our customers are just enough to master our product and solve routing tasks with it.
But it works only when the customer doesn’t have choice, when he is really interested in purchasing our component since only it can offer the solution. If the user choses from multiple competing products he will always chose the one that will allow him to faster see the way how to solve the problem.
And what does it mean to see the way of solving the challenge in the product which main feature is to form and view reports? Yes, you’re right, it means to be able to build a document similar to the one required by the end user.
Do you think that when developing a prototype your prospect will read a set of manuals 100 pages each? Do you think he will send a request to your technical support asking for help? Most likely, no. He will run the component and will try to do what he needs. Probably, he will read a short Getting Started guide. You shouldn’t expect more.
That is why it’s getting clear that to duly compete on the market our component should quickly show that it is absolutely necessary to the prospect. To show the way to solve the problem.
We know everything better than anyone else
I gave the sample with the professor at the beginning of the article for a good reason. Getting deep in our software, we behave in the same way in relations with customers. We know the product well enough, so we just stop noticing its complexity. Namely, difficulties arising when evaluating the product.
Unfortunately, companies can’t afford working only with those who are ready to spend much time and effort to explore the product. It is possible if you are a recognized leader of the industry and knowledge of your software is a must for the vacancies. But small software vendors can’t expect the same thing.
So, one of our biggest problems is deep expertise of the software. I often hear how a programmer answers to a question of a junior technical support specialist on how to solve this or that issue: “This is obvious! Let him do…” and there goes a description of the solution that a usual human being who sees the product for the first time can hardly think of. And the programmer was absolutely sure that he helped to find a solution. Yes, a single user is happy (here we can dispute as well), what about the others? Those who decided not to contact our technical support, just uninstalled the product and left for competing components?
Will everyone send you a message and ask for help? Just for your information, surveys (even payable ones) are responded by 2-3% of the respondents. I.e. if one person sent you a question on “how to do something”, approximately 30-50 people didn’t do it and just left to competitors. By the way, if customers don’t have any questions at all, it doesn’t mean your product is ideal. Maybe they just leave at once.
Lowering barriers to entry
That is why we don’t have choice. You either make the product more intuitive by lowering barriers to entry, or you will have to leave to the other niche with no competitors. Though there may be no customers as well.
There are thousands of ways of lowering barriers to entry for users and it is worth writing a separate book. To my mind, the first and the most important method is observation. Find a volunteer who doesn’t know your product, sit next to him and watch. In no case allow him to seek help from developers who are always ready to assist (especially if the volunteer is a pretty girl).
Though, if you design components for programmers, it’s a bit more complicated. But here are some options as well. In some of the latest products, I demand from our developers to make product integration require a single line of code. It is not that easy sometimes. But it’s worth. After launching one of the latest products based on this concept we got lots of thank you emails stating “it’s great that your system is so easy-to-use!” This is very important. The user is able not only to solve the challenge but also sees how to do it.
I will give another small sample. One of our components (Reporting Services viewers for Silverlight, WPF and Windows 8) was initially designed to interact with the server via the intermediate service (sorry for technical details). It helped flexibly manage such processes as storage of intermediate data (cache), helped repeat user queries when no connection is available. But our customers had not only to deploy a visual component, but also setup this intermediate service; it required much more time.
Thanks god, our component was the only one available on the market. So, users had nothing to do but explore our product clenching the teeth. Our technical support team got tons of emails containing issues related to improper settings of the service. Once competitors appeared we began to lose ground.
Looking at this situation, we decided to refuse using the intermediate service and work directly with SSRS server. Yes, it brought some limitations and some product features disappeared. But now developers are able to use our software in the application by adding a couple of lines of code.
Thus, we made our product easier-to-work with; in this way it became more attractive for users. We also lessened the load of our technical support.
Summary
Why did I write all these pages? I wrote them to share a thought that seems to be obvious, but is often forgotten in a hurry of publishing new versions and designing new features. It doesn’t matter how flexible your product is. If you offer your product on a highly competitive market then one of the most important factors is ease of exploration. Besides, ease of exploration doesn’t mean poor functionality. But that’s another story…
