I believe anyone can have a design career — that said, it might not be right for you

Product design appears to have gained some popularity in wider culture, which is great, in my opinion. There are certainly many things that are attractive about it — like other roles in tech, it offers a great lifestyle: great compensation, remote jobs, high quality colleagues, interesting work, etc.

But, like other roles in tech, getting into it takes some work — while it requires zero certification/education (i.e., zero dollars), the barrier to entry is not zero effort. This, alone, might be the part that many interested people have the least awareness about.

Setting expectations

Every career requires some upfront cost in order to get into it. Let’s consider the surgeon.

For surgeons, that upfront cost can look like certifications you must acquire through cash-intensive programs approved by the state, many years of repetitive action and tutelage, etc. You cannot easily learn on the job, as the required skills are extremely niche and hard to acquire (i.e., you need access to patients to practice on/observe from — most people are not willing to be experimented on for your benefit alone). This is an example of a career where the toll one must pay to enter is extremely high.

What’s more, when you’re finally practicing, you also take on significantly more risk when compared against, say, a professional motivational speaker. As as surgeon, your margin of error is extremely small (your error can cause severe quality of life drops for patients — or worse, death), meaning you are exposed to enormous occupational risk (litigation, physical injury while performing services, etc.). Luckily, their rewards can be high: owning their own businesses, being in high demand, commanding high compensation from clients, etc.

But then consider tech: it is unusual in that it is a highly rewarding industry with no formal, upfront cost, and low exposure to occupational risk over time — the margin of error in one’s design practice being pretty wide, one can be not great at the job, but one can learn to change that over time.

Your greatest risk is not easily acquiring customers, particularly as a lower quality designer. But this isn’t really a risk: while it might not be easy to acquire customers, it’s not impossible; what’s more, you can still sometimes get them anyway, especially if the customer is not discerning, allowing you an opportunity to improve over time, if you’re enterprising enough. In the same way that there are lower quality surgeons, there are lower quality professionals of all sorts. It’s a market — someone somewhere will buy something, and since your services aren’t going to get someone killed, there’s a wider base of customers at your disposal who are less risk averse, and more willing to take a risk on your services.

To continue with the example of the lower quality surgeons, for example, they can get customers, but they won’t get them as reliably as more skilled ones; likewise, the higher quality customers will often pass them up, meaning they might have a lower quality of life: lower rates of customer acquisition due to smaller customer base, lower quality customers, less pay, less quality employees who want to work with you, etc. This mostly explains why some designers have hotlines blinging, and others do not.

For reasons that I likely do not need to convince you of, tech is rightly considered attractive to many. But you still need to pay that upfront cost of attracting customers at all. While it doesn’t require the amount of work and risk that an attorney, surgeon, or doctor would need to put in and tolerate, you still need to put in some amount of work.

But you have to make the decision for yourself concerning whether or not you are willing to put this amount of work upfront in order to reliably acquire customers. After all, effort isn’t something that can be taught — you just have to do it.

Right, so what now?

As we’ve established, there’s no other way around this: you need to pay the toll. What surgeons need to acquire reliable customers will look different than what a product designer needs. So here’s what you need:

• Reasoning skills, specifically applied to products and businesses. This is sometimes called entrepreneurship. It can be a measure of good cognitive ability, among other things.
• Good visual design skills. You need to make things look professional, but ideally more than professional — beautiful.

Of the two, visual design is the higher cost (not in terms of price, but in terms of time invested) skill to acquire, and it is extremely high priority, but it’s not the one I’ll be focusing on in this opinion piece.

You need good reasoning, specifically pertaining to software products and business. Here’s how to think about this: your job is to determine if products or features have a reason to exist (i.e., if it has market demand, or what I call “plausibility”), and then you have to figure out the best way to make them work for people (what some people call “usability”). Both of these are cognitive abilities. More on these below.

#1: Plausibility

The first order principle: the software you make must have reason to exist.

Quickly, I’d like to talk about something called “product-market fit.” An article written by the great people over at Mailchimp details:

“Product-market fit,” writes startup coach and investor Marc Andreessen, “means being in a good market with a product that can satisfy that market.” When an entrepreneur identifies a need in the market and builds a solution that customers want to buy, that’s product-market fit.

This concept might seem obvious, but it’s important to make sure there are enough people who want what your business offers and to define your value proposition accordingly. Product-market fit can matter more to the future of your business than creative ideas, masterful teams, or any other factor, and is critical to take into consideration when you build the product. For any business to survive, there must be people who will buy what it sells.

There should be real, market demand for this piece of software. You can propose and build anything. You can make software do anything. You can write anything in a text editor and push it up to an AWS instance. But why would you do all this, specifically? What products and services do people want? Aside from recreation, there’s not really many reasons to build products that no one could ever hope to want.

Besides, how can one really reason about something that obviously has no utility, no market constraints? If you’re making something that has no reason to exist, as in it’s purely for fun, it’s more akin to fine arts (e.g., making a painting, a sculpture, or a digital installation, etc.): it’s fantasy, and the constraint is, well, whatever you feel like. Nothing wrong with that, but products are different: they exist to (ideally) respond to a market gap. So they have constraints: i.e., demand from real people — ones who will bounce if they hate your idea, or its execution (if it’s bad enough). Thus is the power of the market.

For many of the most amazing digital products that exist today, the initial idea was totally accidental — someone was having fun on a weekend project, a few friends started using it, some more friends started using it, and then it started to dawn on them: this cool, weekend project has wider appeal than initially intended. This serendipity is common in entrepreneurs — they tend to be enterprising individuals who have lots of interests and make lots of cool stuff, then one day accidentally strike digital gold.

But this is not the only way to build products. Some people experience less serendipity, and more intent from the outset — sometimes with some serendipity on the way. For example, Slack started as a game company, where they made products for entertainment. They struggled to find fit with the games they made, however. Over time, they were messing around with some ideas and getting close to running out of money, and then someone made something that people seemed to respond well to. Based on the way people responded, the team decided to take a risk and go all in with that idea. At the time, many would have called this a crazy business decision — when one considers the risks, it can seem kind of crazy to be an entrepreneur, at all.

But the capacity to reason through market demand and then make — and invest in — something that responds to that is fundamentally what you need to function as a product designer (or product manager), at the bare minimum. Investors have to cultivate this sense for what’s a reasonable product, too, at the risk of potentially billions — and even they make mistakes (numerous investors passed on early opportunities to partner with Slack — look, it happens).

This is also why you are called a product designer. You design products. You’re not often the person to come up with that chat bot idea that ends up with a four billion dollar market cap ten years later, but you might be the one building that initial prototype leadership uses to ask investors for help, or working on it as it matures as a product once it has clear product-market fit, so it behooves you that the product area make sense to you.

Besides, if you’re working on a product that really, in your heart of hearts, has no real product-market fit, what can you really do to make that product make more sense to the people using it? Honestly. Fundamentally, it simply makes no sense to people — no one has any incentive to use it. It does nothing. No amount of well-placed buttons or toggles or copy will plug this plausibility-shaped hole in what you’re working on, whether it’s a side project, or something someone is paying you to build.

Here are some examples of products that are plausible:

• An app that lets you chat with every single colleague in your organization. It’s not easy to discover your colleagues, threads get too long to reasonably read, it’s not easy to upload media, email clients all render content differently, there’s too much unique formatting in emails that causes noise, it’s not easy to pointedly tag people and manage email communique, and things get lost. No more of that. You can spin up a chat instance for your workplace easily, it’s private to your organization so you can tag your colleagues, kick off quick, async chats, make bots automate stuff for you, and keep all your chats neatly in one place without clutter or management needed. This is called Slack.
• An app that allows you to call a driver to take you somewhere you want to go. You don’t have to call anyone and deal with attitude problems or miscommunications, you don’t have to call to get an update about the driver’s location or status of your request, you’ll always get the opportunity to cancel, and the driver doesn’t need to be part of some exclusive organization. It’s just a driver and a car, and a pedestrian with a destination. This is called Uber.
• An app that lets you order groceries. You have reasons to not want to go to the store yourself, so you can just tell someone else to get it for you. You pay for those items, and the delivery person for their time. This is called Instacart.

It’s obvious why someone would use a product called Slack to exchange messages with colleagues and start org-only chats. It’s obvious why someone would use a product called Uber to call a cab. It’s obvious why someone would use a product called Instacart to get groceries delivered. There is real, obvious, market demand for all of these when you think about it. So your job is to do that: think about it.

Here are examples of features inside of products that are plausible:

• A feature in Slack that allows you to kick off quick calls to discuss something that can’t quite be captured over text. Slack now has a feature for this.
• A feature in Uber that allows you to request repayment following a group ride you called in. Uber now has a feature for this.
• A feature in Instacart that allows you and your family to add items to a group order together. Would also be nice to be able to split the bill, especially if it’s you and your roommates buying a group order together. Instacart should have a feature for this, in my opinion.

It’s obvious why someone would want to spin up synchronous video/voice chats in a chat app they’re already using with their colleagues, right from the convenience of the app. It’s obvious why someone would want to order a cab for themselves and their friends, and then expect repayment after from their buddies right within the convenience of the app. It’s obvious why someone would want to make group orders for the home on Instacart and split the costs with their roommates right within the app.

This is your singular order of business: to use your reason to respond to market demand, and then make products and features that respond to this demand. You make products for a living, necessarily meaning that you have to have basic reasoning skills about why someone would want a product, and how they would reasonably expect it to work — which leads me to my next point.

#2: Usability

The second order principle: the software you make should be easy to reason through.

“Usability” is a word people often use to describe how pleasant something is to use — namely, whether someone can easily figure out how to use your software to accomplish their goal. You can think of this like a user is “hiring” a product for a specific “job” — they want an outcome, so give the people what they want! They don’t want to do more stuff than is obviously necessary to get that.

Consider this: would you prefer to get up and walk over to some part of your house to find a phonebook, go to the business section, look alphabetically through all the businesses for doctors, check their addresses manually to see if they are near you, hope they are still in business or in the same location, find their number, walk over to the place where your phone is plugged in, and then call? Or would you prefer to open a rectangle in your pocket, type “doctor,” be sure beyond reasonable doubt they’re still in business at that location, and tap on something that kicks off a call for you?

To use the example of Slack: a user wants to send a message to a colleague. How easy is it to find a way to message their colleague? Do they have to reach out to another colleague who might know them and ask what their email is? Do they have to go to a webapp where there is a way to look up your colleagues and find their contact info, then open their email client and copypaste their email and send the message that way? Or can someone combine this phonebook of emails with a chat app, cutting out some of those annoying steps?

Now that you’ve done that, is it easy to type one’s colleague’s name in and have them come up? Is it easy to see a list of people with that name, and a way to identify them as the colleague one had in mind? Is it easy to see if they are available, or even still at the company? Is it easy to kick off a chat with them? Is the entry point to kicking off a chat obvious to the average person? Is it easy to see if they are messaging you back? Is it easy to have casual, quick conversations? Is it easy to press send? Is it easy to find the chat with that colleague after they refocus on to something else? Is it easy to get notified someone sent them a message? Is it easy to type into a text box? What if you close the chat, can you still know if they’re messaging you? If you walk away, is there a way to be notified on the go that they’ve pinged you? Can you also message them on your small rectangle, or do you need to go to your big rectangle?

One can go on, but if a user wants to send a message to a colleague, that’s the job they want to get done. Yours is getting them to that outcome without much fuss. What is the easiest possible way to facilitate this so that they are able to get this “job” done as quickly as possible, and in a manner that seems predictable and reasonable to the average person?

This process requires reasoning: you’re trying to deduce whether you’ve put buttons in the right order that people can quickly reason through without much second-guessing, and predict what’s going to happen next without much doubt. You’re trying to determine if each step in your proposed process seems reasonable, or if there’s a better way to go about it.

There’s a real rigor to this. It’s pure reasoning, deduction, and you have to think step-by-step, consider edge cases, or what parts of the product the person might be entering this feature from and how that changes things (if at all), and so on.

At least I’m not a surgeon

If you’re like me, you dread the thought of being a surgeon. While I have enormous respect and admiration for people who have the courage to take on this line of work, it’s very obviously not for me: I’m deeply squeamish; I don’t understand how one can predict what place on the body is safe to cut; I don’t know what to do if you make an error, or if you even can; I don’t understand how to optimize for the best possible healing; I don’t understand how to work when everything’s all bloody; I don’t understand how to strategize for each patient’s differing anatomy; I don’t understand how one can memorize all the entry points while under duress; and so on.

I don’t “get” it and, if I’m honest, I have no intrinsic interest in changing this. It’s possible I could, but I really, sincerely doubt I have the level of interest or grit needed to dedicate my life to this pursuit. In this way, there’s virtually no chance being a surgeon will ever be right for me. The work simply does not interest me — in fact, it terrifies me. A surgeon might sincerely have a hard time understanding “what the big deal is” when I say all this, though. To them, it’s a Tuesday.

Likewise, product design might not be for you. To me, figuring out if a product has a market — and if the way I’ve put the product together to respond to that market need makes sense — is usually something I intrinsically enjoy. But some people may not feel this way. It might feel like a chore — like there’s no intrinsic interest there at all. This is totally fine. Diversity is the spice of life, as they say, and it takes all kinds.

Anyway, I can totally see how this lifestyle would be enormously boring to someone. It requires serious, step-by-step reasoning through how a product or feature should be made in order to determine if something makes sense; every product’s business is always different, which can be dizzying sometimes; you have to onboard on to a product and its business before it gets easier to even start to make suggestions about how the product should work, which is annoying if you’re feeling impatient; there’s an edge case for everything, something you didn’t consider every single time you feel you triple checked — to say nothing of all the other stuff that can be less than ideal about planning and building digital products. It does take decent cognitive ability, an understanding of how software works, and patience.

Also, a lot of the software you will work on in your career will probably not exist in short order: it’s software, so lots of iterations got done before you, and lots more will come after; lots of things just don’t ship, as priorities frequently change; most businesses fail to find fit with the things they make your team build, even at big companies (e.g., Reels); product patterns are not super complicated, so you can pretty easily memorize a good portion of them, meaning that the ceiling of complexity can be low compared against engineering complexity, which can be boring; and so on.

But if you don’t want to do any of this at all, for any reason, you will not really be able to take up this line of work. And that’s okay. But, if you do want to, there’s no way around these upfront costs I’ve described. You will need to pay the toll.