How Technology Became So Addictive

I have heard several times now that tech companies hire psychologists in order to hack their users minds and create more addictive products. I’ve also heard that some game designers record the vitals of people playing their games in order to ensure their experience provides a sufficient level of stimulation, as revealed by the test subjects’ blood pressure, heart rate, and piloerection. 

But when I interned at Google and YouTube, I never once saw a psychologist around the office nor did I find any scouring the company organizational chart. Where were these elusive professionals charged with devising ways around our minds' defenses? All I saw around me were software engineers and product managers and designers. If there were no psychologists tasked with using our own minds against us, then what was making YouTube and other apps like it so addicting?

During my last internship at Google, I became quite familiar with what I believe to be the fundamental reason tech is so addictive. It’s all in the way the software is written—the product development methodology. It's the way in which teams work together to create an App. The methodology goes by many names and has many variations, such as Design Thinking, Agile Development, Iterative Development, or the Lean Startup method. Although details differ among them, most have three general steps. First, a change to improve the product is proposed, also known as a hypothesis. Second, the change is implemented for a small subset of users. Third, the data from the experiment is analyzed and a decision is made to discard, modify or accept the change. This process is repeated day in and day out and spans different lengths of time depending on the significance and scope of the change. 

The best way to understand this methodology is to go through an example. We all have used YouTube before so I will use that App. When you enter a search query on YouTube, you are returned a list of videos related to what you are looking for. At least, this was the way YouTube was, before it made certain changes to its search results. Now, after you scroll past the initial results, you may see a group of videos under different headings, such as “people also watched” or “recommended for you.” These videos are not strongly related to what you searched for, but are additional recommendations personalized for you. Now you may not see this feature when you go on YouTube, because they may still be testing it out on a subset of users. For example, I couldn’t find these groups when I was searching today, but I know I saw them at one point in time.

The question becomes why were these recommendations added to the search page. After all, when people search for videos, they want those types of videos to show up, not some random video unrelated to the query that is going to be distracting. I don’t work at YouTube anymore and don’t know which team worked on it, but from my experience, this is probably what happened. An engineer or product manager had an idea on how to improve search results. Someone sketched out a design proposal for this feature. It was approved by higher-ups at Google and the work began in earnest. After finishing the feature, the engineer responsible wrote a script to show the feature only to 0.1% of all YouTube users. For a week, only these users saw this particular feature. What likely happened is that when they were searching for videos, a thumbnail caught their eye and they got carried away watching something they didn’t even search for. At the end of the 1-week experiment, the engineer opened a dashboard that showed him/her how great an impact their new feature had. Watch time, one of the most important metrics for YouTube as it’s the way they generate revenue, probably grew as users were enticed by the new videos in their search results. As a result, the feature was incrementally rolled out to additional users, all the way until it became a permanent part of the product. The team responsible celebrated their achievement and some ambitious engineers documented the dent they made on YouTube’s bottom line in their applications for promotion. Maybe it was enough for someone to get that raise they were working so hard for. All the while, YouTube becomes that much more addictive and takes up that much more time in peoples day. 

Some form of this exact product methodology was used by business for centuries. There is nothing new about the process of building something and then getting feedback on it from users. But, this methodology is an unstoppable force when used to build software and internet products for three reasons.

The first reason is because software allows hypotheses to be generated quickly and cheaply. If I were a shoe manufacturer and I wanted to test a variety of colors, shoe laces, sizes, or sole designs to identify which product consumers liked best, there would be an upper bound on the candidates I could evaluate. Each candidate has a cost and the number of candidates grows exponentially when testing combinations of details. In the world of software, however, each test I run costs nothing after the initial investment to create the design. I could create a landing page and test 1 million button colors to see which shade makes users click it the most, all in only a few hundreds of lines of code.

Secondly, the scale of software companies today allows them to test these hypotheses with little risk. If I’m Snickers and make a change to my candy bar and only know that my customers despise it after I roll it out to millions of people, I am going to suffer a huge loss. But if I’m YouTube, with over a billion plus active users, I can test a hypothesis, even an outlandish one, on a tiny fraction of my users. If they like it, great. If they don’t, I learn my lesson quickly and revert the change. But make no mistake, with the scale of tech companies like YouTube, even 0.1% of users can be enough to produce generalizable results, since 0.1% of users end up being thousands of people. 

Thirdly, software products are much better than other products at providing a clear signal on what users like and don’t like. Back to the Snickers bar example. If I create a new flavor, the only way I know if it's good is if I survey customers or track sales data. The former is costly and low-scale—how many people can I possibly recruit to try my wheatgrass peanut butter combination. The latter is delayed, since I need to wait months until these delicious treats start flying off the shelves. But with software, especially consumer software like YouTube, I have a good idea of whether or not users like the new update I made—they will spend more time on YouTube. In this way, software allows companies to continuously survey what users are thinking about the changes they make. 

I hope you can appreciate how powerful the combination of software and this product development methodology is. It carefully understands what users want and don’t want and then conveys this information to engineers and product managers. So there aren’t a group of sinister Silicon Valley villains plotting a heist of our limbic system. There are only meticulous engineers, filled with ambitions, harnessing tools that reveal much about the user.

Please don’t mistake me. I am not criticizing people who work in Silicon Valley at all. The individual engineers and designers at these large tech firms want to do better at their jobs. They don’t want to let their team down. If you or I were in the same position, we would do the same thing. But the unfortunate truth is, so much of the time, the better the job an engineer does, the more addictive and destructive the product becomes for the user. If we want to fix the problems of tech in the world, we are going to need to start at the methodology in which ambitious, intelligent engineers are rewarded for designing tools that will ultimately harm their family and friends.