Intercom on Product: Understanding your customer is key to good product judgment
It might sound like a sixth sense but product judgment is a tangible skill that can be learned by listening and observing.
You may have noticed we’ve taken a break from Intercom on Product over the past few months – we didn’t feel it was an appropriate conversation to continue in the midst of the tragic events unfolding around the world. This week however, myself and Paul decided to get back in the studio (remotely of course) and record a new episode to share with you.
With this in mind, we’ve stuck to our regular Intercom on Product subject matter because we felt that we wouldn’t add anything to the discourse by discussing COVID-19 and we also wanted to give you a respite from the daily coverage. We hope this episode provides a welcome dose of normality in times that feel anything but.
This month’s episode looks at the contentious notion of “product judgment.” What is it? Why does it matter? And perhaps more importantly, how can you develop it?
If you’re short on time, here’s five quick takeaways:
- Why do we say product judgment as opposed to product taste or instinct? There’s a lot more specificity when you’re talking about judgment – it’s based on experience rather than subjective preference.
- There’s only really one way to develop product judgment and that’s through direct interaction with your customers.
- It’s hard at times to ensure that PMs and designers are getting that direct feedback loop with users, but it pays enormous dividends.
- Place and time are everything. Product judgment can be domain specific and it has an expiry date. Make sure you’re exercising the right instinct for the right circumstances.
- Create a safe environment for sound product judgment to develop by ensuring feedback is immediate, clear and concrete. Foster an environment where it’s ok to admit your product judgment isn’t suited to the area in question.
If you enjoy our discussion, check out more episodes of our podcast. You can subscribe on iTunes, stream on Spotify or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of the episode.
Des: Hi and welcome to Intercom on Product episode 10, we apologize for the significant break. A lot of stuff has been happening in the world since we last connected. I’m joined as ever by our SVP of product, Mr Paul Adams. Today we are not going to talk about the tragic events unfolding around the world around COVID. We are going to stick to our regular topics because we believe that we don’t have any unique or expert insights we could offer you in this regard. If you are pressing play on the Intercom on Product podcast, I’m guessing you want to hear about product, so that’s what we’re going to talk about.
Paul, today’s topic is going to be potentially inflammatory. It is product judgment and why it matters. Why does every designer and every product manager need a really sharp sense of product judgment. Can you expand on, and I’ve heard you say this phrase before, can you expound on what you mean by product judgment?
Paul: I sure can. So product judgment, like you said, is a notorious topic because when most people talk about it, they don’t define it. And I guess that’s what we’ll try and do today. It has other names, product judgment has other names too. It’s sometimes called product taste, it’s sometimes called product intuition, sometimes called product instinct. It often manifests itself in people saying things like “Hey, that person has great product judgment” or “That person has great product taste,” or “That person doesn’t have great product instinct,” or “The decisions they make means they don’t really have good product intuition.” So it’s a real thorny one like I said.
The reason I use the term product judgment, more than the other ones is that I just think it’s a bit better. At least with “judgment,” you can kind of start to think about ways in which you might inform that judgment or build it over time. And the way I define it is the idea that you can use your own judgment. So you’re just using your own judgment, like in a meeting or workshop or whatever, then you can use your own judgment to one, accurately predict what your customers need, want and value. And then two, design the right solution for them. So that’s what it is, at least in my definition.
Des: I can immediately see where any label that is not hyper-specific is likely to upset people. Frankly because of the lack of specificity. If I said to you “You can’t speak German,” you’d probably say, “That’s true.” If I say to you, “You lack taste,” you’re almost certainly going to take offense from it.
When I think about the importance of it, I think that it’s mostly an accelerant unless a product manager or designer role play multiple different futures in their head where they’ve designed it this way and users reacted. They design it a different way and users reacted. And they can think not just about the user, but also about the logical flow that the user would now be in and their likely future behaviors. And in an ideal case, can think about how that will trickle down in terms of core user metrics and how it will ultimately impact the business.
That is why, and I make that distinction why, when we’re talking with these decisions, it’s not like my shade of blue is greater than yours, or I think the button should go here and you think it should go there. It’s about your ability to assess the future anticipated business impact based on the decisions you’re making in your Figma file or in your scope sheet as a designer or as a product manager.
Gain direct experience with your customers
Des: How do you acquire it? If we left Intercom today and went to go and work for a different company, how would you go about tuning your product judgment?
Paul: There’s a lot to this. So let’s break it down. One thing that I thought about when you were talking Des, was when people use their judgment to make recommendations or decisions or choices, “I think we should go with A instead of B,” or “We should design it this way, not that way.” A lot of it’s done subconsciously. So I think they do do what you said, which is to walk in the shoes of customers. But I think they often do it subconsciously. And their subconscious brain fasts forward a million different inputs they’ve had over the months and years to surface up that recommendation for option A.
Which actually then speaks to your question, which is how do you get it? In my experience, I think there’s only one way to get product judgment and it’s really simple. It’s obtained through direct experiences with customers. And that’s it. We can get into the details of what that means but it’s direct experiences with real customers doing real things, while really using your product. It’s not indirect experiences or second hand information.
Des: Let’s spend a second on this, because I think you used quite specific words there. And I’d like to understand them. What’s indirect and what’s direct for you here?
Paul: It’s definitely a wide range here. An example of direct is, I’m a PM or designer, I’m sitting down with a customer or on a video call with a customer, they’re a real customer and I’m watching them, observing them and talking to them, in a structured way about what they’re doing. So I’m observing them really, really using a real product.
And one version of indirect is the research team did that activity and now they are telling me what they saw, what they observed. Or I’m reading the research team’s report. That’s the same thing happened, but it’s indirect. Other things that are indirect are things like surveys, analytics or data. These are all obviously valuable things too. And I’m not saying don’t have a research team. That’s obviously a valuable thing to have too in many cases.
But in order to build this judgment, which is kind of surfacing from building intuition, you need those direct experiences. And you need many of them. Many, many, many of them. Which we can get into specifics of that too.
Des: So if I could just interrupt there, it seems like, are you appealing for the anecdote to still remain? I could imagine if I’m a researcher, I could argue, why would a designer need to do this? I’ve already watched eight hours of users using the product and I’ve aggregated all the insights. And I’ve written them all up. And it’s easily digestible in a one page doc. Why on earth would somebody have to redo that work for themselves?
Paul: Yeah. So it’s really the distinctions and subtleties here are so important. So what you’re trying to do, again, remember that kind of top of a theme, what you’re trying to do is build judgment which takes months and years. So what you’re not doing it is a one off research study and then listening or hearing about the results of that study. “Hey, we tested this specific UI with these people and here’s what we found out.” What you’re trying to do is build that judgment over months and years. And like I said, over talking to hundreds of customers. You’re trying to build this really deep, subconscious, understanding of all the different ways in which your product is used. It’s pattern matching, pattern recognition, where your brain is seeing all this stuff in real time, you just have to put in the minutes and the hours, your brain is kind of-
Des: You’re sort of tuning a system in a sense. And the argument is like the sort of emotional visceral footprint of seeing someone struggle to close an archive, or a conversation in the inbox will last with you so much more than like, finding number four: participants seem to take longer than an average to close a conversation.
Paul: Exactly.
Des: That makes sense. So then, there’s two other parts to your formula. So it’s real direct experiences of real customers using your actual product in real use cases. And I guess what I’m hearing in the repetition of the word real, is that you don’t think we can fake any of this. You don’t think a non-user is a good source of learning, unless it’s maybe a prospect. You don’t think a fictitious use case as in, “Let’s pretend you wanted to send a customer a newsletter,” is a real use case and you don’t think that a mocked product, for example, like a paper prototype type thing, is real either. If I’m reading you correct, could you just expand on each of those as well?
Paul: I think there’s two things here. One is, again distinction, what I’m appealing to here, it’s not a one off research project. It’s almost like a lifetime endeavor, honestly. Like an investment over the course of your whole career. Especially as you move from company to company and product to product, which we’ll get into in a while. So that’s one and it’s not a one off project. Like you said, it’s basically a real, human connection. You’re building a real, deep sense of how people feel and think about your product, because it’s real for them. Like you said, you see their emotion, their frustration, their joy, their happiness. And then when you see it over, and over, and over, and over, again… oftentimes it’s not even the thing that a research project might be.
“You can just know, and predict with great accuracy, how people will respond to it. Whether they’ll value it, they need it, they care, or they can use it”
If you sit in on a research project, for example, you don’t have to do this interviewing yourself necessarily. It’s the direct experience and the direct observation, for me. You just build these patterns over many, many, many, many interviews. To use a real example, I worked on Gmail when I worked at Google. I worked on Gmail multiple times over my time at Google. I worked there as a researcher, predominantly. And just over the course of interviewing people about Gmail for years, on and off. A month here, two months there. Break for three months, then make a real flurry of activity over six months. You just build this instinct. An intuition for how people use Gmail.
So, when you start to talk to other people in the team, other PM’s, other designers, people with ideas, look at design, look at mockups and look at prototypes, you have this judgment. You just can know, and predict with great accuracy, how people will respond to it. Whether they’ll value it, they need it, they care, or they can use it.
“Testing is expensive versus intuition, right?”
Again, it sounds like it’s that ability to almost literally emulate a user whereby your brain can run multiple simulations of design decisions really quickly. I guess, it’s pretty obvious to me, in the opposite case, if you don’t have this, then your only option for validating the things you might do would be some type of exhaustive testing. Right? You’d have to be like, “Well, I’m going to try these three different versions. So let’s do a multivariate test. Let’s roll them out, let’s do extended betas, let’s see which one performs.” If we assume the goal is shipping things that actually work, with some degree of evidence that they will, your options are, “I really, really, really know my users and I know how to use case. And I know exactly what you’re trying to do and I’m very confident this will work.” Or “I’m going to test the hell out of this.” And testing is expensive versus intuition, right?
Big time. I think you can apply this pattern to other domains too. So for example, I’m kind of making this one up. I have no experience with law, or being a lawyer or anything like that, but I imagine that great lawyers are, in many cases, great lawyers maybe because they know their stuff and history and other stuff, other legal cases and so on. But also because they’ve sat in the courtroom day in, day out, day in, day out for months and months and years and years. And the best ones are the ones who take all those observations and can apply them to things that are happening in the future. Which is another thing which you’re going to need to do, which is the application of the judgment. The application of the observations, I should say.
“If you’re an ER doctor, the more times you’re in the emergency room, seeing and reacting, seeing and reacting, time and again. You build this judgment, you build this instinct”
It’s one thing to build all the observations, it’s another thing entirely to be able to apply them. But I think, if you think about this, there’s lots of fields of work where this applies. Doctors would be another one – where the more things you see the more judgement you build. If you’re an ER doctor, the more times you’re in the emergency room, seeing and reacting, seeing and reacting, time and again. You build this judgment, you build this instinct. And I think when you hear it that way, it’s kind of hard to argue with it. It’s pretty basic and fundamental in a bunch of ways.
These direct experiences with customers are the only real thing that can build the judgment. I’m sure many people listening are like, “Yeah, that makes sense. It’s obvious. I get it. I’m already there. I do it all the time.” But then the question I ask people is, “Do you really do it all the time? Like really?” Because many, many designers, especially, but PMs too, that I know and have worked with over the years, don’t do it. They do a bit of it, but they don’t really do it. And really, deeply internalize the need to do it.
Des: It’s a real dental floss statement. Everyone agrees and understands and will argue that they know exactly why they should floss every day. And then in practice, if you actually ask people to really honestly admit how often they floss, it’s almost certainly not every day. I think it’s similar to that in the Toyota production system, they have this phrase which is Genchi Genbutsu (I’m probably pronouncing it horrendously) but the gist of it is go and see. Get to the factory line, and watch what’s actually happening, so that you can take the right actions. I think, you are correct in saying a lot of people are probably nodding along going, “Well, how are you guys pissing away 10 minutes talking about this, when it’s such an obvious thing.” Maybe this section of the podcast isn’t for them. Maybe let’s talk to the people who are genuinely not doing it.
Keeping customers in the feedback loop
Des: What’s going wrong that designers and PMs aren’t spending enough time with customers?
Paul: I should say that I am absolutely guilty of this too and especially as I’ve kind of progressed in my career, I guess as I’ve moved into more managerial, leader positions, I’ve gotten worse at this. One of the reasons for this is simply that it’s time consuming. But the first thing that I would appeal to people is to be open. People who think, “Yeah, yeah. I get it, I get it.” To be open minded about this is the idea that they need to deeply internalize the need for this. It’s not like I’m working on project A and next is project B. And as part of project A, I’m going to talk to some customers, figure some stuff out. Okay, move on. Next project. Project A is done. Next project. Project B etc.
Paul: It goes deeper than that. Again, when I kind of reflect over the years, and all the different people I’ve worked with, in design in particular, the world class designers that I worked with, without exception, had internalized this idea. All they wanted to do was talk with customers and spend time with customers, or users, pick your favorite word there. That’s what they wanted to do. They loved customers and users more than Figma. That’s how you test one: “What do you love doing more, sitting in front of Figma or sitting in front of customers, talking about what you’ve designed?” And so that is a big thing. And so, to answer your question, it’s time consuming, it takes a lot of kind of proactive communication, organization, energy. I have loads of different memories of this over the years, but prior to Intercom I was at Facebook, before that Google, before that a UX consultancy called Flow Interactive in London.
And at Flow we were at the UX Shop. So we would do research and design and over the course of my two and a half years there, I interviewed about, I don’t even know how many, somewhere around 750 people, I think. Or 500 to 750, somewhere in that range. All different projects, watching them use products. And we used to do five people a day, six people a day. So I did like five or six hours of interviews a day. And it sucks. It sucks the energy out of you.
You’re just sitting there observing, observing, watching intently, doing it well. So it’s hard, but I think that’s the reason people do it. They try to do a bit of it, they get tired. It’s easier to stay in the office (not these days, but usually.) It’s easier to stay in front of your computer. It’s easier to just reopen the sheet, reopen the file.
Des: Figma doesn’t bite back. Figma doesn’t give you counter opinions about what better things you should be doing. So then on the idea that this is a skill that must be learned, and trained, and nurtured frequently to actually keep it sharp. How do you make it a safe thing to talk about? Because I could imagine most designers or most product managers would be distraught if somebody said to them, “Hey, you need to work on your product judgment here.” The allegation that would lead you to say that would be “having observed the designs you make or the decisions you frequently make, I don’t believe you’re getting them more right than wrong. And I believe the reason for that is that you are not successfully emulating user’s thoughts and concerns when you’re working here. You’re not prioritizing the right things, and as a result, I need you to spend more time with customers.” I still think that such a statement would irritate people. How do we take the harshness of the allegation away and make just one’s product judgment ability a safe thing to talk about?
Paul: That I think, is a key thing. One of the things that we’re appealing for people to do here is making this a safe thing to talk about. Because when you do talk and question people’s product judgment, if you don’t do it in the right way, you question their ability, and that obviously impacts their ego and all sorts of stuff and make people worry about their confidence.
There’s a time and a place
Paul: Here’s a good example. What I’m going to get into here is the idea that product judgment is domain specific. When I joined Intercom, which is now I guess nearing seven years, or something like that, like I said earlier, I’ll use Gmail for example because I think it makes sense. I worked on Gmail and I interviewed hundreds of people, watched hundreds of people use Gmail over the years. So I feel like back then I was pretty, maybe expert even in thinking about email, how people use email, et cetera.
“I’d never watched any Intercom customer using the product. I’d not talked to one single Intercom customer”
So I come to Intercom, Intercom’s a customer communications product and email is a communications product, and there’s similarities in the product. You can send messages and reply to people and talk and tag conversations and so on. But I remember when I joined Intercom I had way less of the sharp view and product judgment. I remember like you, Des, had spent, I think Intercom was 18 months out at that stage or, maybe two years. You and Eoghan and David and Ciaran had been working there for two years. And I remember – I can see this now looking back – you had very strong product judgment when it comes to Intercom. I had zero. I’d never watched any Intercom customer using the product. I’d not talked to one single Intercom customer. I, at the time kind of blindly assumed that because I could design Gmail, I could design Intercom. Because they’re generally the same-ish in a way.
And that was partly right and partly wrong. It was partly wrong in that I had no idea how B2B customer communications products were working. I’d never worked in it before. I’m sure, Des, you remember I made some pretty bad designs?
Des: I was going to say… Is this why we had seven different inbox designs?
Paul: That’s one reason. Well, probably the main reason. Turns out you can’t design Intercom like Gmail. So there was things that I just had zero product judgment specific to the product space of Intercom. But there were things that are similar. So how do you design good ways for people to send messages at the UI level? How do you design good workflows for tagging conversations? Well, you can do in Gmail and it works well. So the things that are domain specific, and so some of those examples there might be more in the design side, like a good composer looks like X, and a bad composer looks like Y. And I could apply those directly to Intercom and have good product judgment specific to that.
But then there was parts of Intercom that I had no idea about. And I had no product judgment and I had to build it. And the only way I could build it, which is what I did, was talk to customers. And I remember you at the time and Eoghan were very encouraging that I go do that and talk to customer after customer after customer. Then of course I’ve seen since how you do this. Where you’ve shown me screenshots where you would talk to customer after customer in your areas of Intercom trying to find product market fit, customer after customer after customer after customer after customer. Dozens and dozens and dozens of customer conversations.
And so that’s how I built it at Intercom. So I think it needs to be safe for people to evaluate themselves and product judgment and see where they are and talk about it safely to their peers. So for example, if you’re a new person to a company, there’s specific domains where your product judgment is much poorer than people who’ve worked in that company for a while. Even if they’re way more junior than you. Or it could be the case that you just haven’t talked to the customers. You could be more senior, or you could be more seasoned, you could be there for a while, but you just haven’t had the opportunity or never prioritized it. And so you haven’t had those direct observations, and therefore your brain hasn’t pattern matched to the conclusions and the judgment.
Des: I’d also say it expires as well because, if you think of a product like a conversation with the market. Over time, the product evolves and the market evolves. What I mean by that is, obviously when I used to sit down with customers who would use our inbox or our messaging features, it was 2013 and Intercom looked a lot different. But also our customers’ forgiveness was probably a lot different as well because back then because a lot of what we were doing was relatively new. Whereas now we’re seven or eight years later, a lot of the things we’ve built have become mature technologies and people’s expectations are now a lot higher as well.
I think this is more maybe a lesson to early stage employees or founders, whatever. Just because you had a good grip once, it doesn’t mean that it sticks around forever. If you don’t keep meeting customers, you will ultimately, all your knowledge will expire. But in a way, it’s even worse than if you’re a new employee. At least a new employee knows that they don’t know for the most part, unless they’re super confident. Whereas there’s nothing worse than living the phrase “It isn’t the things you don’t know what to kill you, it’s the things that you know for sure that just ain’t so.” I think that that’s where I find myself often having to relearn things that I was once very sure about. “Hey, our average customer’s probably a CEO of a small startup.” That’s just absolute nonsense these days. And I’ve had to retrain myself a lot to understand that we’re in a different world.
Creating a safe space for product judgment
Des: I think on the judgment piece, to folks out there who want to make this a safe and open conversation in their company, the thing that I try to always remember is that a lot of this discussion will be around feedback. And feedback usually needs to be three things. It needs to be immediate, clear, and concrete. So immediate as in it can’t be like, last year you made a bad call. Clear as in, it needs to be very specific about what the bad call was, and concrete meaning it has to stand up for itself. It can’t be just fundamentally I prefer a different color of blue.
“Until it’s a safe space, what you’re going to get instead is a lot of false confidence and bad bets”
So when you actually want to talk to somebody about where you think your tastes your product judgment or their product judgment is lacking or very strong, it’s important that you have those traits because the exact opposite is where most of these conversations can go. The feedback is delayed in that you hear about it weeks later. I never really liked what we shipped there, type thing. The feedback is abstract where it’s like, I just think that’s a bit weak, but you haven’t been tied down to actually be clear about what that is. Or it’s opaque in that no one can actually infer if you’re doing a good job or not, because you’re not letting the idea of product judgment stand alone. It seems to be the anointment is passed to somebody who gets to decide what is good. I would just encourage in trying to make this an easier conversation to have you, you need to think about those three things.
The other piece I’d say is (and this is definitely a message more to leaders) that you have to know when it’s okay to say, “Hey everyone, I know you’re looking to me for decision. I do not have enough good product judgment in this area. So because of that, I suggest that we all go and spend more time with customers in this exact topic, because I don’t think any of us are yet at a point where we can make a significant bet here on making an informed one.” Until it’s a safe space – and this is why it’s important for leaders to say this – if it’s not safe for people to say that, what you’re going to get instead is a lot of false confidence and bad bets.
Paul: I think that’s spot on. There’s actually three different situations a leader could find themselves in. And actually these three situations are also something that, if you’re not a leader, if you’re just a designer or PM or someone on the team.
If you’re looking to your leader to try to understand how they think about these things, you can look for these three too. One is that people with strong product judgment are very good at saying when they don’t have that judgment, you know? And they just innately know that, “Well, I didn’t talk to the customers about that. And so I can’t possibly have good judgment about it because I understand how judgment is built over years. And therefore, either let me defer it to the people in the room who have talked to customers and build judgment about this thing.” Or “hey, let’s get talking to customers ASAP about this thing and start building some judgment.” So that’s the compounding nature to think people with strong judgment are good at saying when they don’t have it.
The other extreme is the most dangerous of all, which is people who think they have strong judgment but don’t. And this can range from junior folks with a false sense of confidence, they don’t really understand how these things work yet. And they’ve yet to kind of be humbled by seeing their product fail, for example. Or like senior leaders who can often have a greater false sense of confidence. And then typically that pattern is where they attribute product successes to their own judgment, rather than actual causes such as timing or luck or whatever.
And so that kind of leads me to this middle ground where you can have people with strong judgment who know when they don’t have it. You can have people who think they have it, but they don’t. And then you have people who do have it, but can’t explain it. And this is like the trickiest of these three to kind of disambiguate. They just know something is the right option, but they find it hard to articulate it because their subconscious brain is short-cutting to the recommendation.
“Your conscious brain is a tiny percent of your brain’s processing and it’s all the stuff underneath. You got to just do the time”
But I think you can typically tell if a leader or manager is a person who’s built up strong product judgment by just seeing how they talk about customers. Do they have interest in talking to customers? Do you know that they’ve a lot of history talking to customers? You may not have seen them talk to customers recently, but you know that the history of their work at this company and in this domain is that they’ve spoken to dozens and hundreds of customers over the last few years.
Or, they insist that everyone around them talks to customers. There’s an insistence. So there’s this kind of like just bias towards talking to customers, talking to customers themselves historically, or in the future. And I think that’s how you can kind of disambiguate some of these situations.
Des: Let’s finish on some rapid fire stuff. I’m going to give you hard, multi-paragraph questions – I need real quick answers. One is, why can’t we document this stuff? If product judgment is so good, why can’t you just join a company and get the three pager that tells you everything you need to know? Isn’t that the more efficient way to experience and catch up on all this?
Paul: That’s a funny one. You can’t. That’s like saying, ” Can you experience life that way? Here’s one page on what it feels like to do a bungee jump.” “Oh, I get it.” No, you don’t. You’ve got to do it.
So you got to do it. You got to feel it, experience it. live it. Your conscious brain is a tiny percent of your brain’s processing and it’s all the stuff underneath. You got to just do the time.
“There’s no TLDR for life. Okay”
Des: There’s no TLDR for life. Okay. Another question, how transferable is it? If we take a company who people might pair us with recently, for example – Zendesk or HubSpot, If I walk out of Intercom today and go over to take a job at Zendesk or HubSpot (P.S., I’m not asking for a job.) how likely is it that my judgment will transfer well?
Paul: I think it depends on the domain. So the Gmail Intercom example is a good one, because some of the domain overlaps on the UI side, the workflow side. And some of it, it does not overlap at all – Gmail, at least, then was consumer email; Intercom, business communication product. So I think it depends on the domain. But Zendesk, you could walk into Zendesk for sure, having worked at Intercom. Both build customer support products. And absolutely use what you’ve learned at Intercom at Zendesk. But then there would be some things that are different at Zendesk and how Zendesk works that you’d need to learn about.
Des: That makes sense. The last question then, which is both of your previous examples have reminded me of. When you talked about Gmail, you talked what the similarities tend to be, for example: tag, compose, etc. Let’s call them the micro interactions and the workflows around them. I think in most mature categories, when something becomes standard enough, it becomes a kind of design pattern of sorts, right? So if you think about we had to invent a messenger that clung to the bottom right and popped up and overlaid and did all this sort of stuff. But now it’s a thing. So if somebody from one of the companies who took inspiration from us change jobs, the design challenge there is not really there anymore. There’s now just a way to do it.
“There are many things that never change. There are things that change slowly and there are things that change fast”
Just like there’s probably a way to build a visual campaign builder or a way to select users from a list, or say tie conversations and follow threads and all that sort of stuff that we bump into in the classic shared functionality of all B2B products. I actually don’t know what the question’s going to be here, but I’ll just hand it back to you and say, to what degree does product judgment overlap with general cop on for designing in a specific industry?
Paul: To me there’s basically three things here. Let me just say them, then talk about them each real fast. There are many things that never change. There are things that change slowly and there are things that change fast.
I think the things never change are things that are rooted in human psychology. “Hey, this is how human beings interpret X. Here’s a list of 100 cognitive biases that exist in human beings, exist in our species. They’re never changing, at least in our lifetimes.” So that’s kind of what design school is for, or university is for, people learning-
Des: Your banner should be red if it’s an error, that type of thing, right?
Paul: Exactly. Red means stop. Green means go, at least in most cultures. Not all. In some cultures, red’s a lucky color. So just learning stuff like that, human psychology, design patterns. This is stuff that does not change. And this is foundational.
Then there’s the things I think you were talking about there Des, that are things have changed slowly. So we now know that an X closes a browser window and a kind of a horizontal line thing that makes the browser window minimize. That probably will never stay like that, unlike say, a cognitive bias. It’ll change within our lifetime for sure. But it’ll change slowly.
And then there’s the things that are changing fast, rapid innovation brand new products, all the stuff that’s going on in the world right now is turning some industries upside down. And so when you’re thinking about product judgment, you kind of need to be able to distinguish the difference between those three.
Des: That’s a pretty comprehensive answer, even though I was only supposed to give you five seconds. We better stop here. Before we go, I want say first of all, thank you to you, Paul. And then to our listeners, we hope this has been a little sip of your normal prior life. And we hope you all are safe, that you stay safe. Take care and persevere. And we’ll talk again soon. This has been Intercom on Product. Thanks very much for listening.
