Can “Old” Companies Disrupt?

No!*

OK, so Apple did it, and Steve Jobs is considered a genius (and he was) for making it happen. But for most companies, it just isn’t going to happen.Evolution, improvement and progress – sure – but real, iPhone-type disruption? Very, very unlikely.

Mind you, that won’t stop companies from claiming that they are disrupting this or that segment or vertical.Just like Sodastream disrupted the “home carbonated beverage” business a few years back.

As companies mature, the company will adopt a certain gospel. The employees will either believe in the gospel, be indifferent to it, or leave the company. So eventually, you are left with a company where everyone believes pretty much in the same “truths”. In an environment where everyone believes that the earth is flat, it is hard, if not impossible to fund research to show that it is spherical.

Obviously. there are quite a few obvious examples to contradict this theory; Google’s moonshot projects spring to mind, and 3M is perhaps a better example, but my impression is that these examples are the exception, and that the vast majority of companies at one point or other stop challenging everything they believe and just go back to the same old s..t.

To disrupt, it’s clearly not enough to just do random things that just happen to contradict what you believe. A recent example is the use of VR in video surveillance; I doubt any police officer would feel comfortable wearing a headset for hours on end, in a potentially nauseating virtual environment where you have to physically move your head in the direction you want to see, vs. just having a fully unwrapped panoramic image on a good IPS or OLED monitor. I fail to see how limiting your field of view is a good thing. So it just doesn’t make sense to me to throw money after such a project (but it did to a lot of other people).

It’s obviously very difficult to come up with something that make commercial sense, and challenge your gospel. You’ll most likely be pitching your idea with “I believe people will love this”, which will then go up against “well, the competition is doing x, y and z, and so we should do that”, in most cases, it is easier, and better for your career, to go back to your desk and put your ideas back in the drawer. So I guess most people do just that.

Another factor is that ideas have to be possible to implement. Not just theoretically, but in practice too, with consideration to the staff and financial resources you have. A small contractor would be better served bidding on projects he can actually finish, rather than drafting plans for a new bridge or skyscraper that he has no chance of completing even if he wins the bid. If you don’t have the financial capacity to actually fund the first batch, setting up logistics, handling returns and warranties, then why bother? It may be a great idea, but if you can’t possibly execute it, then it won’t happen. Dropcam was able to go to market by buying cheap cameras off Amazon, updating the firmware, relabeling the cameras and shipping them. It was clearly suboptimal from an operational standpoint, but it allowed them to discover that the idea was viable, even if it seemed to contradict the whole “open platform” mantra.

For newer companies, that are not carrying around a lot of outdated and perhaps questionable gospel, this is a golden age. It has never been cheaper to set up extremely powerful cloud based computing and storage systems, and I don’t ever recall a time where I could buy a fully functional and plenty powerful computer for $10 – including the OS!

Enough ranting, let me get back to doing something that aligns with our gospel.

*Betteridge’s law in full effect here

On Rationalization and UX

A while ago I read about a rationalization experiment conducted by Tim Wilson at the University of Virginia. Two groups were asked to pick a poster to take home as a gift. One group were asked to explain why they liked the poster before taking it home, the other could just pick one and go home.

After a while, they were asked for feedback. How did they like their posters now?

The group that were asked for an explanation, hated theirs while the others were still happy with their choice. This is a little surprising (it was to me at least). Why would explaining your choice affect it so profoundly?

I think this behaviour is important to keep in mind when we talk to our clients.

A potential client may be reviewing 4 different bids, and while they are pretty similar, the client decides that he likes #2. At some point the client may have to rationalize why he picked #2. If there are very obvious and compelling reasons to go with #2, it presents no problems. But what if all 4 are very similar, and the reason the client wants #2 is really because he quite simply, just likes it better. He can’t explain his choice by just jotting “I like #2 better”, so he will rationalize.

And so, unless there are very clear, objective, advantages of #2 over #4, we are entering that dangerous territory. The Poster Test (and other variations of the same thing), show that people simply make things up. It’s not that people consciously think “oh, let me just make up a story”. They genuinely feel that they are making a rational argument.

In the realm of software development, requirement specifications quite often deal exclusively with what one might call itemizable features. E.g. “open a file”, “delete a user”, “send an email”, and very little effort is put into discussing the “feel” of the application. When bad managers sit in a management meeting the focus is on Product X does Y, we need to do Y too, and then Z to be “better”, and the assumption is that the user doesn’t care one bit about how the app feels. Almost no feedback exists that complain about how an application “feels” (it does exists, there is just not a lot of it), and it is very rare that managers take that sort of thing to heart.

At Prescienta.com, the “feel” is important. I believe that if the product feels robust and thoughtful, that the customer will happily make up a story about why some small unique feature in our product is crucial. “Feel” is about timing, animations, and non-blocking activities, it’s about consistency and meaningful boundaries. Some companies seem to understand this, and consistently move towards improving the user experience, others give up, forget, or lose the people that have the ability to create pleasing user experiences, and instead let their product degrade into a jumble of disjointed UX ideas, inconsistent graphical language and bad modal activities (hmmm.. a bit of introspection here?)

A well designed application is designed with the technical limitations in mind – a good example is dropcam, where the audio delay is so large that the UI is designed to take this into consideration. The push to talk metaphor is a perfect way to handle the latency. If the UI was designed to work like a phone (that has almost no latency), there would be a massive gap between what the UI is suggesting and what the technology can deliver.

Another example, a bit closer to home, is the way you move cameras around in privilege groups. The goal here was to design the UI to ensure that the user did not get the idea that they could add the same camera to two different groups. If the UI suggests that you can do so, you may be puzzled as to why you can’t. I decided to prevent multi-group membership to avoid contradictory privileges (e.g. in one group you are allowed to use PTZ in another it is forbidden, so which is correct?).