Nov 26, 2019
 in 
Design

Breaking Down Indifference

W

hen trying to achieve something, we all have to conquer the indifference of others. Whether that is subverting the indifference from our colleagues, lawmakers or potential buyers, we need a team effort that starts with them caring enough to eventually do something.

Involvement goes a long way in making this happen, but indifference is not just removed magically or in a one-swoop manner. It is more of a diligent, persistent process of adding reasons why to actually care.

We all have our problems and concerns, and little time to expand our focus into more causes. Sharing concerns with other groups of people is a social construct that is only possible when intent and timing coincide.

Take for instance the case of a new product. You may have the best of intentions, you set out to create something truly different, to fix an important problem and improve people's lives. You work hard, you grow your team and eventually come to the point where you are ready to sell this new product.

The road from indifference to action is hard to navigate. It takes a team effort and several processes.

How do you convey this new meaning? Entire sets of literature have been produced on how to bring something to market, but they always result in overly myopic prescriptions. Something like "Company X pioneered a way to accelerate time to market with Activity Y, therefore in this segment, companies should adopt the same model to increase ROI".

But explaining the success of a company or product after the fact is a big mistake. There are several reasons why an innovation can be diffused effectively, and even if we could break them down play by play, reproducing those with a different set of people, at a different moment and under different market conditions would probably not carry out the same way.

The key is to find what is it that drives the purchasing decision, obviously, to add value to your target customers. It sounds quite simple, but it is very difficult, and the reason why consultants worldwide make a lot of money talking about "product-market fit".

Our belief is that such a thing is hard to come by, and very hard to purchase through a consulting fee. It is very likely that if you get close to the types of customers you are seeking, and you do relentless demos, that you will understand this better than anyone.

If you are in the product development team, it is likely that you have the best understanding about the product's vision, possibilities and opportunities for change. You just need to get closer to understand how the target customer is perceiving what you have done so far.

Sales processes are not the formal top-down effort of the past. We have more space now to engage with potential partners and customers.

In my case, I am deeply involved in UX Design. It is that core activity that got me into making software. The craft. The thing that dreams up new possibilities. But those possibilities are often shaped by our imagination and the UX Case Studies we conduct. As designers, we often get close to core users at the start of the cycle, but then forget about staying there at the end.

If you work at a Startup, whatever your role is, there is the soul of a salesperson inevitably inhabiting your body. Most people deal with it as a necessity, or a hassle. But if we can get comfortable with failure, being exposed, and getting things wrong, we can get closer to the target user. We can hear the commercial feedback and inform our next decisions based on this.

It all takes shape when you collect enough data points to analyze a common pattern, and let this insight define the way your sales team talks about the product. The biggest common mistake I have seen in technology companies is that the sales effort is disconnected from the technical effort. The impression that they do not need to know how the product is made in order to sell it.

Even worse, the idea that they do not need to know what reactions the users are having at every stage, in order to adapt the sales approach.

At Interlink, we have had some challenges with this, as we created a new product with a new development team. The sales people were used to a different approach. They thought "you make it, we sell it". But the lines should be more intertwined.

Strings helps Internet Service Providers to manage their networks, anticipating problems and increasing ROI: https://strings.app

When creating Strings, a network management solution for Internet Service Providers, we wanted to do a lot of things differently. We had just over 16 years of learned lessons in what to do and what not to do for our users.

And yet when we first put the product out there to our potential customers, we did not obtain the fascination we all have for Strings. They were well impressed, but not amazed. This is not what you are shooting for when you create something radically different to what you have done in the past.

It was hard to overcome the indifference of customers who already use a legacy solution from us. They thought nothing was particularly wrong about the status quo. But we knew once they understood the difference, they would care enough to be amazed by Strings.

We had spent so much time on metrics, architecture, stability and scalability that we were late with the in-depth features that could truly set us apart. Those features where not ready yet, but we had interactive design prototypes.

We did countless demos of those to our existing customers, and the response was overwhelming. Everyone was more excited about granular control and detailed information. We knew it was important, we just did not understand how much the users cared for it. We thought condensing vast amounts of data into quick monitoring layouts was more interesting. How wrong we were.

So we got to work. We wanted to provide a true experience out of having Strings point out where attention needs to be placed, and to let the user sort through the data efficiently. We gave it several names and it took wildly different approaches over time, to become what it is now.

The Channel Browser helps people navigate the complex universe of metrics around an interface channel's life cycle.

In the end, we decided to call it Channel Browser. It lets you browse the channels in a network interface, and find out different things about the health of the interface, and the service. It saves people a lot of time and it is a pleasure to use.

So we made adjustments to give the Channel Browser more importance in the UX, and we set out to build it. It was our big, cracking dent on the barrier to bring down indifference. We are thrilled to start rolling it out to our users now.

-Mariano Malisani

If you are curious about how we plan to highlight the difference in crafting and updating Strings, check out the following video: