Your app is not a product

I think it’s wrong to refer to the digital results of our work as ‘products’ though. It’s nothing like real products. For instance, none of the software I’ve been involved in was ever really finished. Not because I didn’t deliver, but because as long as the projects had funding, people were working on redesigns and updates.

Using the word product for websites and apps can set wrong expectations for clients and business owners. Physical product development needs to be completed before products can be produced and sold, whereas digital services and outlets are regularly developed iteratively, gradually getting better functionality. Until business owners no longer ask what it costs to create a website, their understanding of what a website is and can do is still based on the old notion of buying a physical asset.

Calling software ‘a product’ also contributed to bad parts of programming culture. After all, of people believe code can be ‘shipped’ and the ‘product’ is finished after that. But that leads to engineers shuffling off responsibility and writing code that ‘works on my computer’ and is incomprehensible to future maintainers. I don’t think offending any programmers here, because many I worked with complained about this problem. This attitude of shipping code that only superficially works to pass abstract tests is pervasive though. So pervasive, that despite many countries and the European Union legally requiring accessibility, nearly all homepages have accessibility errors.

Treating software as a product hasn’t helped the design profession either. Beside industrial designers getting annoyed by UI designers appropriating their job titles, our product-based design processes don’t work well with agile software teams. Methods that require big design up front without considering the value of engineers during that phase are the legacy of physical product development. Designers hanging on to that could be a reason for design struggling to compete with product management and that its influence in organizations declined (sidenote: I hope this is just my subjective experience, but I checked a few companies, just to be sure. Neither Figma, Adobe, Apple nor Spotify have a someone dedicated to design on their boards, while do do have execs for engineering and 'product'. ) as a result.

Lastly, treating software like a product is misleading to end users. Nowadays consumers rarely buy a piece of software anymore. If they have the option to pay for a life-long license, it’s often just that: a license to use the software, not the software itself. They can’t sell it to someone else or pass it on to a friend. Even songs and books are ‘sold’ that way: as nontransferable rights. There’s something to say for selling software as a subscription service. Users likely want and expect updates, so that the software works on their new hardware and matches the looks of their updated operating systems. But especially in such a contract, there’s no product; it’s the service of getting regular improvements that customers pay for.

If product is the wrong word, then why do we use it so much?

From the day I first stepped into the faculty of Industrial Design Engineering of the Delft University of Technology, I loved design. The sheer notion that I could draw something on a piece of paper (I loved that already), turn that into a technical drawing with a computer (imagine using computers! for creative! work!), that people in factories would then make with high tech machines, so people could use the things—so exciting!

A few years later I found it even more exciting that I could skip the part where drawings were taken to factories. Anyone could use the internet to bring digital ideas straight to where ever on earth people would be interested in them. And the methods, skills and mindset I developed by studying design would be so useful to get programmers to work on those ideas with me!

I must be one of millions who went through such a process. Because the internet was so new and growing so fast, barely anyone was trained to create on/with/for it. At the same time, everybody creative and excited enough believed that whatever proficiency they had, was just what was needed to make things online.

As a result, the way I feel about making websites is still influenced by how I learned to think about designing physical products. And that is not unique to industrial design. Graphic design also had, and still has an ultimately linear process. Once the printing press runs, graphic design is finished.

Software development used to be mainly about systems embedded in physical products. Calculators, music players, even computer games were distributed as physical objects. Until phones and other personal computers replaced many of them, most digital electronics had embedded programs that couldn’t be updated. So software developers referring to their ‘product’ were in fact referring to something that existed physically, once it left the factory to be distributed.

Of course, that type of software still exists. But most designers and developers work on websites and mobile apps. Some of them do desktop apps. I don’t have precise numbers, but looking at Stack Overflow and their surveys, it’s clear that relatively few people work on embedded systems.

Referring to software as a product is an artifact of yesteryears. Almost all software today needs updates. At the very least for security and bug fixes, but also for hardware support and to run well on the systems that they’re created for.

The nice thing about the web is that a website made in 1996 could still work in your freshly updated browser. But it would look old-fashioned, broken even. But for all intents and purposes, the website ceases to exist if the bills aren’t paid for the servers hosting it or the domain name referring to it. Or, in the case of such very old websites, if they don’t have SSL, which make browsers show a big scary dialog that only daring web surfers dare and know how to circumvent. And even if that is taken care of, but the site’s backend software didn’t get updates, we can be pretty certain the original pages will be replaced with SEO spam, links to malware, crypto miners and e-mail spam bots.

With apps it’s not much better. If you’re not updating your app for a while, Apple will remove it from the App Store. After that, even users who paid for your ‘product’ won’t be able to reinstall it anymore. Not even when restoring a ‘backup’ from iCloud, or when they get a new device. That means that every app maker has to be frank about this: either you commit to working on updates indefinitely, or consider it more like the broadcast of a pilot episode of a series that may or may not be continued.

Committing to long term supports includes overhead like writing release notes, changing app store images and paying the annual Apple Developer Program fee. Made a nice app? Even have many passionate users, but no revenue? Keeping the app alive for 10 more years is going to cost you nearly a thousand US dollars.

Longevity of apps in the Google Play Store isn’t any better. Just like the Apple App Store’s, its terms are regularly changed. An app that has been through the tedious approval process can be removed after such changes, unless the creators file complaints, provide documentation and change the app’s code or its description.

You could argue these ‘products’ just need ‘maintenance’. But where tangible products may need a drop of lube or a replacement for a worn-out part, software needs to gets different changes each time. Where most cyclists can maintain their own bicycles, software ‘maintenance’ requires the same type of people who created the software. They’re not maintaining it, they’re changing it.

Maybe instead of products, we she should speak of events?

I don’t think we need new metaphors for the things we do with computers. But I like thinking about creating software as organizing an event. Here are some reasons why I think event is a better metaphor than product:

• An event can be long and big, like a music festival. It can also be a short presentation. Everybody understands intuitively that differently sized events have different requirements. Whereas with software products today, lots of people tend to believe they need the same planet-encompassing solutions that silicon valley giants have chosen.
• Events have an opening date and a closing date. Considering both should lead to a plan for making sure the event is attracting an audience and is safe until it’s closing.
• Such a closing date also helps to consider what’s supposed to happen what remains after the event. What happens to the URLs on your site that others linked to? How can app users still access the works they created with your app?
• Everybody knows events don’t run on their own. When the organizers and staff leave, things can and will get out of hand. This is why Designer News was and Twitter is made unusable by fascists and spam.
• Of course events need to be accessible to wheelchair users and other people with physical and cognitive attributes that are different from the organizer’s. I mean, your users’ need more color contrast in your UIs than your young eyes.
• If an event is supposed to happen for longer than an hour or two, you need an efficient, long-term energy supply solution and plans for when and how new visitors arrive and leave, and supplies are delivered. The hosting and updates thing I mentioned earlier.
• Technology is required for events to happen, but it’s not the main attraction. Rarely does an event need completely new solutions, so if technicians or designers propose such a thing, one has to verify how the event visitors and organizers would benefit from it.
• Events are only successful if enough people come, if these people get along well, and have some diversity as not to bore each other.

Just call it software!

I hope you enjoyed considering using event as an alternative for product. Maybe you have an even better metaphor?

I think the simplest, clearest word we can use is software. Even if that word is based on two metaphors (softness and hardware). That doesn’t matter, because software always refers to the programs and files created for computers. And every language is eventually a recursive set of metaphors and abstractions (sidenote: George Lakoff's book Metaphors We Live By convinced me of that. ) based on metaphors.

Of course, sometimes it can be helpful to be more specific. For that we can use the good words we have already, like algorithm, application and website. Not sure I’m on board with terms like library, extension and plugin, but that’s for another time.

Now what?

Of course I don’t think this one blog post will change the language that we use to refer to what we create at work. But I hope that it helps refine our thinking about creating software and the processes we use for that.

I want to end with a prediction: future generations of programmers, designers, managers and people in other, new roles in software creation won’t like to use the p-word for what they create. We won’t only have software engineers, but also software designers (sidenote: Obviously, design and product management encompasses much more: user experience, service, business development, customer acquisition—these areas are exactly what most projects need more of. But by referring to all those things as product or UI like we do today, doesn't do them justice either. ) and software managers.

True digital natives grow up without the mental bias towards products. When we’re old, remind me to be patient with them kids inventing seemingly arbitrary roles for themselves.