Align Before Design: The Psychology of Strategic Alignment (with Tamara Adlin)

Get episode summaries right in your inbox so you can easily reference, save, and apply what you learn:  thedesignpsychologist.substack.com

Why do so many user personas fail in practice, and what can we do about it?

Have you ever worked on a team where everyone had a different idea of who the user was? Or watched a beautifully crafted persona become ignored or misused? You're not alone. In this episode, we explore why traditional personas often fall short—and how alignment personas can change everything.

You'll learn how to cut through organizational chaos, align stakeholders, and get your team moving in the same direction. You'll also discover a fast, psychology-informed method to surface assumptions, prioritize goals, and build products that stay focused on what really matters.

Meet Our Guest: Tamara Adlin Tamara Adlin is a UX legend. She's the co-author of The Persona Lifecycle and The Essential Persona Lifecycle, played a key role in shaping Amazon's UX strategy, and now leads the charge with her new concept: alignment personas. Her work helps teams avoid derailment, align faster, and make smarter design decisions. She also hosts the podcast Corporate Underpants, tackling the organizational dynamics that show up in bad products.

What We Cover:

• Why personas started off strong—and where they went wrong
• What makes alignment personas radically different and more effective
• How executives act like "tornadoes" and what that means for your designs
• Why assumptions are more powerful than data—and what to do about it
• A five-step alignment process you can run in a single workshop
• Practical tools like the strategy wedge and purpose slide
• How to use design psychology on your own team to influence strategy

Key Takeaways:

• Most personas fail because they gather dust, get misused, or don’t align with actual business priorities.
• Executives often bring strong, unspoken assumptions. Unless you surface them, those assumptions will quietly shape everything your team builds.
• Data alone doesn’t change minds. But alignment personas help teams reveal what they believe—and align around it.
• You don’t need months of research. Just five conversations can expose misalignment, clarify direction, and build shared understanding.
• Design psychology isn’t just for users. It’s a powerful tool for navigating organizations, aligning teams, and protecting your product from chaos.

This episode is packed with real talk, powerful analogies (Greek gods and all), and methods you can use immediately. If you're ready to turn misalignment into momentum, this conversation with Tamara Adlin is your guide.

thedesignpsychologist.substack.com is the podcast newsletter. Get episode summaries right in your inbox so you can easily reference, save, and apply what you learn.  

Transcript

Welcome to The Design Psychologist, the show that helps you use psychology to design
better experiences. I'm Thomas Watkins, your guide to becoming a more powerful
psychology -informed designer. Have you ever joined a team where people had different
ideas of who the primary user was? Or have you sat in a meeting where marketing
and product and dev and maybe other departments were all talking past each other
because they were imagining different people at the other end of the screen or
service? Today I am thrilled to share a conversation I had with Tamara Adlin,
who I'll introduce momentarily. Together, we explore questions like, "Why do so many
personas end up useless despite making so much sense? What are alignment personas?
And how do they change the landscape of how we approach the problem? How do you
run a fast, effective workshop around product alignment that avoids fluff and gets
decision makers aligned in sometimes just two hours? What do Pornados,
toddlers, and Greek gods have to do with anything. What's a strategy wedge and how
does it stop the wrong executives from derailing the product? What's a purpose slide
and why does Tamara think it should be in every executive presentation? By the end
of this conversation, you'll have a clearer view of how design psychology can be
applied strategically. you'll see how you can cut through organizational noise and
align leadership and give your product team the clarity it needs to move forward
with confidence. So let's have a listen as I introduce and speak with today's guest.
Welcome to The Design Psychologist. I have a really, really special guest for today,
Tamra Adlin. She has had an extremely impactful career as a researcher, a book
author, an expert mentor and advisor to startup founders and large companies.
She's a regular community contributor throughout the UX community, a speaker. She's
known for a lot of things, but in her early career, her work with Amazon, she
played a pivotal role in actually shaping Amazon's UX strategy during the formative
years, right? So she's not just ex -Amazon during 99 to 2005.
Starting in the mid -2000s, she began a long path of developing and evolving the
concept of personas, a little bit of historical context around that. Personas were
originally introduced to the software world by Alan Cooper with this book. In '99,
the inmates are running the asylum. After that, there was an explosion of
practitioners applying the idea of personas in a lot of different ways. And through
this mass experimentation came a lot of ideas about how to do personas correctly.
So in the mid 2000, you had Cooper's second book about face, which I was personally
influenced by, but I was also heavily influenced by the book that Tamara Adlin,
our guest today had co -authored, which is the Persona Lifecycle, and I have it here
today. And we're not gonna be talking about this book mostly today, we'll be talking
beyond this book, but Persona Lifecycle, keeping people in mind throughout the product
design, and that's in 2006, one of the most influential books ever written on the
topic. Tamara is not the kind of person who is content with having an idea 20
years ago and then sticking to it dogmatically over her career. She is ultra
-pragmatic and is all about what works in real life versus what doesn't work.
In 2010, she co -authored the Essential Persona Lifecycle, which was a refined version
of the first one, but over the years has continued to really expound on the
evolution,
helping evolve what we know about that. Worked at a whole bunch of Fortune 500
companies, a multitude of organizations. What I think about Tamara uniquely bringing
to the table is that she's super practical in her knowledge and is intensely
experienced at applying what we call personas. And we want her to help us fast
forward to the point where we have a lot more insights that she's helped you know
gained over the years. So she told me the other week people hate personas right now
and she knows why and she hates them as well. Oh my God. And she's recently kicked
off her new podcast show corporate underpants, invisible panty lines that show up in
products. Oh my goodness. And she is continuing to innovate around the work of
personas and is working on writing her upcoming book, Align Before Design.
So we'll be looking out for that in the future. So with much excitement and
appreciation, Tamara, welcome to the show. Thank you so much. Absolutely thrilled to
be here. Thank you. I was at Amazon slightly shorter, 2002 to 2005. But otherwise--
Yay. I got a-- Two Yay. I need to replay that intro anytime I'm feeling blue.
Thank you. Appreciate it. So, yeah. So, let's, before we, a lot to talk about
today. So, just an overall map for you and the guests, what I'm thinking,
and we can change this at any point, a high level map of this discussion would be,
what's the problem Personas are supposed to be solving. What did Personas promise to
give us? Where did they fail? And what's a better approach? So there's a lot of
avenues in here. So let's first start off with,
what do you think is the problem? Let's start there with the problem that we're
trying to at the core solve period, just why personas came to be and then getting
to the discussion of where we go right and wrong. - I mean, my little quippy way
of saying is, as a user is a four letter word. I mean, the word user is
worthless.
Listen, the idea of personas as genius is, like I like to say is, was, always will
be. Alan Cooper did a massive service to our industry in bringing forward this idea
of having a specific individual in mind when you're building or designing a product.
This idea wasn't a thousand percent new because it existed in marketing before in a
different format. It existed in industrial design as back as the 1950s with Joe and
Josephine who were these archetypal human beings with, you know, average human being,
weight size, whatever to build car seats, things like that. But what Alan Cooper did
was bring in the idea and name it Personas in the idea into our world of software
and product design and user experience. In the book, the inmates are running the
asylum, why high tech products drive us crazy and how to stop the insanity. That
whole book, other than those three chapters on Personas, is sort of a diatribe about
how business people and engineers are the wrong people to design products. Because
when you're thinking like a business person or you're thinking like an engineer, even
if you could think about people, you can't do it both at the same time. So those
three chapters in the middle, 9, 10 and 11, were this idea that instead of having
bullet points full of data or using broad words like user, we should create the
equivalent of like characters in a movie because we are hardwired as human beings to
relate to other human beings and that that builds empathy. And of course, Alan
Cooper said the way to create these, although he was in specific just as of that
book, I don't think he realized how huge it was going to become this idea. He
said, you know, you look at data and you find patterns and you create personas,
which, of course, spawned gazillion conversations in our world. But that was the
whole idea, that we don't go to movies about chairs, we don't go to movies about
36 to 47 -year -old women in ex -urban areas, we go to movies about specific
characters and specific people. And it was supposed to solve a whole host of
problem, I think, which can really be summed up as empathy for users and really
understanding who the hell users are, which nobody was doing sufficiently until that
point. Just think of it as everyone using the word "user." It was supposed to solve
that problem. >> So let's walk through some examples. They can either be semi
-hypothetical or whatever, in stories of some situations where personas fail.
You have smart people, you have a team of folks who think they're doing the right
thing, they're well -meaning and they do what we would call failure,
which brings on the need for the stuff that you're gonna be talking about. - Okay,
so the ways in which personas have "failed," in my opinion,
I mean, there's several reasons why personas failed, and John and I wrote them in
an earlier article, and then Nielsen Norman wrote an article referring to that a
long time later, actually in our book, personas failed because the people doing the
research aren't the ones who are actually using the personas and all sorts of
reasons that you could read. But let's talk about what it means to have personas
fail. In the early days, what that meant is everybody got excited about personas
because anybody in UX or any field of product was like, "Well, duh, this is
genius," because it is. So then everybody tried creating personas, even there wasn't
a how -to manual, right? Which is why John and I and our colleague Holly Jameson
Carr were originally doing these workshops at the Usability Professionals Association
Conference in the year 2000 when we were approached to write the book. The reason
we did those is because everybody started trying to do personas and They created
their persona, their posters and their decks and whatever. And they put them on the
wall and they said, "Tada." And sometimes there was fanfare and like, "Oh, this is
great." Or people started to ignore them right then. Or they sat on the wall and
nobody paid attention to them. Or they went feral, meaning people started to use the
names of the personas, but they were describing somebody completely different. So
First, it was hard to create the personas because nobody knew how to do it. And
you could learn how to do it from Cooper by going to the Cooper Academy. But John
and I were like trying to figure out why were all these personas' efforts failing
since we knew it was such a great idea. So we had all these people come and they
told us why their persona efforts failed and we created this life cycle model to
solve that. So your question was, give us some examples of ways personas failed.
Well, I just told you like that the artifacts went up one way personas failed
people didn't know how to create them. Another way is that they create in them, but
they tended to be expensive. Another whistle that put a bad taste in the mouth of
the business people. Another way is they did great ones and they put them up on
the wall when they gathered dust, right? Or they went feral and people use their
names and were meaning something else. So Failing is an interesting word with
personas. I think it's because the promise didn't work pragmatically.
And as you said, I'm a very pragmatic person. It's not that the idea wasn't great.
It's not that data first personas isn't genius. It's that functionally something was
going wrong with the process of somewhere along somewhere along the process,
they were failing. And some of it was communication. - Now, so some of the things,
you know, where I've, we're gonna get into the process stuff 'cause that's super
interesting. What I've observed where personas would go wrong is where folks would do
marketing personas for stuff where you need behavioral patterns and they're looking at
demographic segmentations and focusing too much on that, and then they're useless. Or
it's a pretty good useful persona in the very beginning to help answer a few
opening questions. And then they sit on the shelf and collect dust. And that's kind
of what I've observed in my career. And then you've kind of seen beyond that, it's
just they end up not being useful as promised. I mean,
I think that there's a few great points in there. So the way I describe marketing
versus product personas is it's a different question about how you get eyeballs to
your product than once your eyeballs are there, how do you get them to move around
your product? So first of all, and who buys your product and who uses your product
are often two different things. But the question of where do you put your
advertising and it requires different answers than the question of where do you put
a button, right? And so I think you're right. I think the line got blurred there.
I also think that there was, you know, what I didn't mention is by their very
nature, personas are individual people. They are very specific, right? They are very
precise, but as Cooper says, they are precise but not accurate. 'Cause anytime you
create a single person to represent a broad group of people, it can't be accurate.
Even by calling it a male or female, it can't be accurate because unless it's an
all -male or all -female or whatever audience, you can't be specific.
You can be precise. So I think people immediately tagged on that to say, "Well,
they're useless because they actually don't represent our user base." And so anytime
anybody had any argument with a decision that could be tied back to personas, they
would say, "Well, what if it was a woman?" Or they would say, "What if it was a
person of color?" Or, "What if it was a person who didn't own a Buick?" And none
of those questions could be shut down effectively with a persona in the early days
because practitioners didn't know how to use personas to shut that down. Wow.
And so, you know, getting into this, there's a set of terminologies that you have
that serves as a good organizing vocabulary for the discussion.
And in your talks, you talk about whether you talk about tornadoes. So can you
ground us in this sort of framework for the rest of our discussion? I'd love to.
So, you know, in our fields, we always use the analogy of the house and building
the house and it's kind of how we explain like information architecture versus IA, I
mean, versus UX versus UI, UI is the wallpaper. You know, UX is like,
anyway, we're all familiar with that. So now let's actually picture ourselves as part
of the building crew and we're out in a building site outside. And what we're doing
is we're focusing on the process of building that house. Do we have the blueprints
correct? Do We have to go back and revisit the blueprints. Is the house facing the
right direction? Do we have the right teams coming in at the right times? Do we
have the correct materials? Can we get better materials? Is the general contractor
and the subcontractor scheduled correctly, right? All of that stuff. And that is the
equivalent of us focusing on our double diamond. And the double diamond is a
catchphrase for all the process that's in our domain, right? No matter what Lea
Bullse put on that double diamond from Discovery strategy all the way through
release. I started to get interested in the fact that if you're on a building site
and a tornado comes through, it doesn't matter how good you are at building,
at scheduling contractors, it doesn't matter how good the materials are, it doesn't
matter if the blueprints were correct. A tornado is a problem of another It has an
eye picture in my head, the double diamond floating away, also like a graphic of a
double diamond floating away on a floodwaters and all of those construction people
floating away. We are so focused on, it's like looking for our keys where the light
is best. We're focused on the double diamond because we consider that our domain.
The domain of tornadoes, which in practical sense, let's get back out of the analogy
into practical sense, looks like some executive coming in six weeks into the design
and development process and saying the logo needs to be bigger or saying we need to
gamify this or saying we need to put AI into this. Right? Or we need,
why isn't this on the blockchain? Which I'm sure all of you have experienced, not
one of the, AI especially. And you having no good answer, but you also having no
power. Because if a senior executive comes in and say we need AI in here, no
matter how idiotic it is. Like I worked on way back in the mid -2000s.
I've been through disruptive technology a zillion times. I was working with a bank
and they had an executive come in and say, "We need more community features on our
banking website." Too much my response was, "Who the hell wants to hang out on a
banking website?" But community features were all the rage. So we had, like, how do
you have an answer of that, right? He had gone to some conference or he'd been at
like some networking event and community or gamification. Let's gamify our bank
website. I mean, what the hell does that mean? Anyway, we are powerless against
tornadoes. And executives are one set of tornadoes. And they all, my friend, Katie
Jiminer suggested, what about earthquakes? Earthquakes are like when the market
changes, like AI or the entire government collapsing, Like, when there's external
forces, it has nothing to do with how good you are at the process we've learned
and honed over the years. It has to do with forces that we have considered to be
out of our control so we have not looked at them, which is why your podcast topic
and the focus back on psychology, and in my case, I think mostly organizational
psychology, although I'm sure I bastardize it, That is, to me, the missing key and
what it takes to become senior in our field is to get really, really good at
tornado management, which actually is more within our grasp than we thought. And this
is, I love this analogy. It's something that humans have had to deal with throughout
our existence. We could set up farmland or our huts or teepees or whatever, but
when that weather comes in, that's just a level beyond. And if we have the
technology and know how to say, hey, let's manipulate the weather, you know, kind of
in this analogy, and it's as powerful, it's difficult to do like with the
executives, then that's something that you have to pay attention to. And then what
you just alluded to is that senior practitioners can't afford to say, well, I'm just
going to focus on my little area and my draft sheets of the double diamond and
stuff, because that's just not, you You can't be senior and be like that.
- No, then we're just in an eco chamber talking to each other about how great we
are. And how everybody should listen to us or we're at the center of the table,
everybody should be gathering around us. Well, they're not chumps. So the other thing
I wanna say about the tornado analogy before we move on is if you look back at
the Greek myths or any mythology about gods and goddesses, Weather came from the
gods, weather came from fighting with the gods. Lightning bolts and tornadoes and
storms came from Zeus fighting with Poseidon over who was more powerful. That analogy
is very, very apt here because our tornadoes come from arguments that seem ridiculous
to us. We have no power over them and they are utterly destructive in our worlds.
And all we do would sit there and say they're acting like toddlers. But it's not
true, it's not true. In the case of Greek guys, it kind of was true, acting like
toddlers. In the case of executives, it's that their puzzle looks different than
ours, and we are snobbish about it.
- So that leads wonderfully into my next question, which is how you talk about data
-driven personas versus the assumption -based personas, and you have a way of flipping
that on its head. So when we come in here, we're like, okay, we are behavioral
experts, and we're designers and researchers, and we're going to use data. I mean,
we all love data. The world needs data. That's what science, if you're a believer
in science, then you believe in data. And we say, look, we want to use personas
that are based on data, not based on assumptions, like who wants assumptions?
Assumptions are wrong. Assumptions are someone's opinion, but data's correct is what
we think when we come into this. And so we have this dichotomy in our minds, I
think a lot of us, is we want the data and not the assumptions. We don't want the
assumption, but we want the data. But you got a framework that kind of flips that
a little bit. Yeah. I mean, I'm not somebody who says don't look at data, but I'm
the person who This data is powerless against powerfully held assumptions. I mean,
listen, right now the United States is a great case study for this. We can complain
about people making non -data -driven decisions all we want. That doesn't mean that
suddenly they're going to flip around and say, "Oh yeah, we see the light." I mean,
it's a great case study. Also, the joke, not so joke I make is that if data
really worked, no one would get married anymore, because data suggests it's not the
best idea, right? So, powerfully held assumptions, if we like it or not,
or snidely say assumptions, it doesn't matter, they're still more powerful than we
admit right now. And if we admit they're powerful, then we have to look at what
can change them. And also, we have to look at where they come from,
because in the quote -unquote assumptions that come from senior executives is wrong.
It's a different picture that they're looking at, and they are playing on a
different field which is usually bottom line based, right? And we have to associate
with that's a totally separate thing. We have to look at where they come from and
not be so snobbish about them. But we also have to say, if we want to change
assumptions, merely saying here's data that says Here's data will not change
assumptions because if I wanna get married, I know that there's statistics out there
suggesting that statistically it may not be the best idea. It doesn't matter why
because I think I'm different. I think I'm unique. I know me, I know the specifics
of me AKA our business. I know the specifics of my environment and my family AKA
the market. And I know I'm different, right. And if I know I'm different,
by the way, perhaps I'm not wrong. Lots of marriages do survive, right? So a lot
of these assumptions do work. Data is not going to change that,
change my mind just by just because you showed it to me. And then therefore,
you've got the interesting twist to it, which is our two options are not data
-driven personas versus assumption -based personas. It's a different set of options that
we have a choice between. - That's right. So originally I called this whole idea ad
hoc personas. And then, you know, after a conversation I had with them and when I
was teaching with Nilsa Norman Group, Don Norman wrote an article in 2006 called ad
hoc personas and empathetic focus. I mean, even back in 2005, 2005 is when I left
Amazon, because the book came out and I went to become a consultant, even at
Amazon. The journey there had started with me trying to create data -driven personas
at Amazon, who Amazon walked around saying, as if it was a person,
they had the most data in the world, biggest database in the world at that time. I
wrote a book on personas. I had one of the best data analysts and head of the
data center on the team. we had 12 people around the table creating data -driven
personas for Amazon and we could not do it. It didn't work for reasons that are
another show. What did work is at the same time I was working with little
individual teams around Amazon creating quick ad hoc personas just to get rid of the
word "user" and those were working, right? And we can talk about what working means
in another way. But so then much later, and I created this ad hoc persona creation
process, much later on just a few years ago, I renamed that same thing alignment
persona because that's the result instead of how they're created. Here's my thing.
And just in the past couple of months, I've sort of weaned away from, say, data
-driven personas to saying data -first personas. Like I don't have a problem or data
in personas. What I have a problem with is that data -driven or data -first personas
don't change assumptions. So I'm thinking about it. It's like, I'm thinking over, you
know, all of this in the Double Diamond, which is where most persona work takes
place, is great. It's just there's a bigger Mount Olympus with all these fighting
Poseidons and Zeus's over here, don't accept data -first personas.
They just, I mean, they look like they do because, of course, they look like they
do, but then they don't. Okay. So if that's the case, then what if we got all the
assumptions out on the table first, what happens when you do that is that suddenly
misalignment shows up? Because executives, I'm going to say executives, it could just
be a couple levels up, are used to talking each other in a room. There's all sorts
of politics going in the room. Usually there's a lot of dick measuring going on in
the room too, and there's a lot of insecurities. They're used to talking to each
other in a specific vocabulary. They're in their own echo chamber. If you get their
assumptions out on the table, they used to, they thought they were aligned and they
weren't. So how do you show them? How do you let them show themselves? These are
actually who you're assuming the users are, which is way too flexible,
because that's, I can't get another story. I can talk about this for seven years,
but the the other thing then is that once you get those assumptions out on the
table and you help them align them, you help them come to well, I guess you're
right. And I guess I'm right. And actually we are going after Philip and not
Genevieve based on our goals. Then and only then can you tell them,
guess what, Philip doesn't really exist anymore because AI has taken over all of
Philip's roles until you have Philip and you get them to agree how important Philip
is, you can't get rid of Philip. Philip almost exists and is so powerful that until
you get Philip and all of the other characters out of their brain, those loading
assumptions, those personas, those unarticulated personas are going to demolish,
no matter how great your data is, any other attempt that you make to describe
users. Yeah, so this is great because, you know, we're dealing with, so first,
the options it looks, we're either aligned around assumptions or misaligned around
assumptions. That's my thing. And you're just, that's your thing. That's my thing,
the alternative to alignment around, the alternative, the alternative, wait,
the alternative to misaligned.
around the alternative to alignment around assumptions is not alignment around data.
It's misalignment around assumptions.
So that's the first huge reality a check for all of us is that we're not choosing
just in It's not that you're not saying we can't you're just saying in the real
world. It's not data versus assumptions It's assumptions are there and are you
aligned around them or are you misaligned around them? That's exactly it whether you
like it or not whether you're snobbish or not whatever the assumptions are there and
Nothing we can do in the double diamond impacts the Greek gods
chill, we help the Greek gods get a little bit more organized. Okay, so since we
can't have nice things, is that something we should be sad about? Is that something
we should feel sad about? Or is there hope that you can, in some cases, if you
live long enough, mildly influence one of the Greek gods?
I mean, don't stop the sentence there, that's the magical part, right? If you say
we can't have nice things, like the other thing I say all the time in my talks is
I used to walk around thinking if I just write the right, ask the right executive
at the right time what they wanted me to do. They would tell me and I had this
huge face palm moment where I realized they don't know. And I think where most of
the conversation stops in our fields is they don't know and then some equivalent to
fuck them, or they don't know and dated rules. But if we stop for a second and
say, well, wait a second, what if we faced into the headwinds? We are the unicast
people in the world, most equipped ever, to help them. Instead of getting pissed at
them, how can we help them without getting fired? They are our users and we are
putting out a product that they don't use. Hi. Isn't that what we were trained to
like, yeah, fix? I mean, it's, I'm sorry, go ahead. Yeah,
being just extending from what you're saying, one of the things I just really love
about what you're talking about, I was thinking about the other day, it's like a
meta version of mental models. So if we look at a organization as like an organism
and every organism to survive needs a model of the outside world and you take
things where you can navigate around at night and you have some kind of modeling
inside your head. So I view you as you're a knowledge architect who deals with the
art of political savvy, right? So you are extracting,
we'll talk about some of these methods you've got in a second, But you are
extracting concepts, ideas from people's heads and you're organizing them.
And it's almost like, you know, like a function in your cognition, right? It's like
some part of your brain that's playing some cognitive role of, you know, of
assembling and, you know, consolidating, you know,
assumptions or whatever and helping to shift whatever that mental model is inside the
organization because the organization needs some kind of idea and it's got to be
organized. So it's based on assumptions that are loosely based upon individual execs
and their observations, but you're organizing that into something that is functional
and useful. Yes. So, I mean, in my first Corporate Underpants episode with my dear
friend Scott Berkin, who is an amazing author in our field. We talked about, it's
the idea of respecting what's already there when you walk in. There's an ecosystem
already, an amazing thing when you said an architect of mental models.
I was like, okay, well, you're architect of anything, you have to prepare the land
first. I'm like, and the land you're preparing is basically a septic field, and you
have to be willing to clean it up a little bit and also recognize that it's
dangerous, right? And unfortunately, that metaphor is probably gonna stick with me for
the rest of my life. Unfortunately, for anybody who listens to me, you have to
realize what's there first and respect it. Instead of going and blazing and saying,
we have a better solution, right? It's like, I mean, yeah.
- I mean, you know, so, you know, with this, it's using psychology, but It's,
you also talk about in some of your talks that we're taking some of this stuff and
we're applying it inward and upward towards the management.
And this is a form of, as a design psychologist, that is part of what we need to
do in order to get this sort of, you're using psychology to get the best effect in
the products and services that are being built. And you're applying them in this way
of creating this mental model and maintaining these constructs and guiding them.
Oh my God, you just now gave me a better analogy for myself, which I'm so excited
about. We treat data as if it's an SSRI. It's an antidepressant and we give it to
someone immediately. They feel better. Well, I'm saying no, no, you need talk therapy
to really uncut again and get to the root of the issue and change the way of
thinking. - Yes. - I love this. - Yes.
- It's not a pill that solves everything, there is no panacea. And you can't be on
antidepressants and get rid of the core issues. And the core issues are there and
can be resolved. If we're gonna go into psychology speak, if you give them some
room and you unpack them piece by piece in a non -threatening, non -judgmental way.
I think this whole psychology, I mean, this whole psychology thing is ridiculous to
say, but the remembering the part about psychology that you're doing is so important
in our field. - Well, 'cause so much of the conversation in our field is not around
the psychology, it's around screens
and the quote, is there and stuff like that. And sometimes it's like we actually
have methods. - And almost none of the psychology talk is about our internal
organizational psychology. It's about our users. But by the way, our primary users
are other people in our company and we're failing to create a great product 'cause
they're not using it. - Right. - Our products are the stuff like personas,
like wireframes, like prototypes, whatever. - Right, yeah, and so on the topic of
misalignment, how much does this correlate and how is it related to the effect of
silos? So when you think about areas like service design or things where you're
dealing across an organization, you have misalignment that's built in to different job
functions and they're seeing the world in a certain way to maximize their function,
and you have misalignment there. I wonder with all of the stuff that you're
clarifying about misalignment and alignment, does that apply to some of the effects
that we see that are silo -specific? That's a great question. So this reminds,
so in the original book, in the 2005 book, which is ginormous and out of print,
there are invited chapters in the back. And one of the invited chapters is actually
by me and Holly, and it's on reality maps and design maps, which is yet another
way of doing journey mapping. But the idea is that a reality map uses sticky notes
to illustrate the way something works across time today from start to finish.
And a design map is, and you can do that with users. And a design map is where
you look at that reality map and you design it better using sticky notes, again,
because of course, the sticky notes. And by the way, that chapter is republished for
free on my website. Now that it's been out of print for a while, it's just another
journey mapping thing. The reason I'm saying this is because I was one of the early
startups I was at was called Atenix. And it was a company that was doing software
for electronic discovery. And what that means is if somebody When we sue Microsoft,
electronic discovery means that a big part of the case is fought before the case
even happens. When Microsoft is asked for documents, you're the smoking gun document
or whatever, one of the strategies can be to deliver 17 truckloads of USB drives,
right, and that the defense or whatever the other side has to go through. And so
electronic discovery is how can you make that faster beyond just keyword searches,
et cetera. Part of the process I went through, and I am answering your question,
was we were owned by a law firm, which I wouldn't recommend joining a startup owned
by a law firm just FYI. - No way. - But we, it turned out not to be the greatest
idea. Weird, one of the things I did early was I did a giant reality map of every
step of that law firm's discovery process with documents which involved many silos
and one silo finishing or almost finishing its work and then handing it to the
next, to the next, to the next. By the end of mapping this, because I was using
paper, it was 25 feet long with standard size sticky notes.
I had it printed at a, you know, Kinko's on one of those long things. And we put
it up on the wall and people came down who had all been involved in this and
looked at it and were like, and even the woman who was in charge of it said, I've
never seen my world like this. And one more thing I'll say is that in the parts
of the map where it was a handoff part, I use yellow sticky notes for questions
and unclear areas riddled with yellow in the gaps. That's how you could tell there
was a handoff, insane amounts of yellow. So the silo problem already exists.
That's a graphical illustration of that problem. But there's a giant silo in the
decision maker team, the stakeholder team, and in any teams that are the pivot point
between business decision makers and people actually doing the work, which is
somewhere between you and the CEO. That's an even bigger one,
because that's not about how do my internal teams hand things off or when does
design stop and development start or whatever, or in service design, where do they
go to an automatic teller versus walking into the bank or whatever. This is about
this huge, powerful layer of business decision making that is over and under and
around every other decision and it's invisible to us. It's a black box.
- So is that part of why you say in your talks that the appropriate level to aim
for is the project level? - When you get started, never start this by doing what I
would do, which is coming in and slapping around an executive team, right? I can do
that because I've been it for years. What you want to do is go one level up or
your boss, your grand boss or your great -grand boss. And what you want to do is
start at the project level. And in fact, alignment personas are always at the
project level. I don't recommend doing personas at a company level. I don't think
they're useful. Unless you're doing an early -stage startup and your ideal customer
profile is the same as your user's whatever. But for most people, they're not doing
that. We could do a separate thing on early stage startups. For most people, what
you're trying to do is fix a problem that you see in an existing organization and
you're on a team within that organization and you're working on a feature or you're
working on maybe an entire site or whatever it is you're working on. You start
there, that's where you start to get the clarity. You're not aiming to change the
behavior of the executives. You're aiming to get one level clearer and get that
approved so that later on you can trace your decisions and explain them in a
language and based on a set of priorities that were clarified by important people
before you started. And that's not as... You would think, "Oh, just ask what the
priorities are, it doesn't work." Right. It requires clever methods to get that
language in the clarity, and you have a mad libs methodology. Do you want to talk
about that a little bit? Yeah. I have a process that I developed over many years.
It used to be many steps. Now I call it aligner personas or executive alignment in
five conversation. The five conversations are, This is what a line before design is
gonna be. This is what I do projects based on or coaching or whatever. That's the
whole pitch. That's it, done with pitching. - Yes, so be in any level of detail you
wanna get. - Sure, no, so the five conversations which I think almost anyone can do
are number one, business goals. Number two, getting them to say out loud the words
they use for users. Number three, using those words and recategorizing them under
statements that start with I want or I need. The fourth conversation is turning
those I wants and I needs into quick alignment personas, alignment personas. And the
fifth step is going back to those business goals that you did in the first step
and prioritizing the alignment personas based on those. After that, you can do
validation or invalidation with data. I just said a lot, but that just gives you
context for the business goals part. You could do research on the right way to do
goals or OKRs or anything for years, it has to be simplified for us to do this
and us not get wrapped around the axle of, you know, the kind of research we would
normally do. So instead I have this mad libs things, and I call them business
goals, even though what I'm saying is that for whatever project you're working on
right now, you need usage -based metrics that will let you know whether or not you
succeeded or not. These are not really "business goals" in the traditional sense,
but if you don't, you call them business goals because then your boss can't tell
you it's a pointless exercise. If you say we need usage -based metrics, they'll say,
"Well, you came up with them. You come up with them." If you say, "I need
clarification on the business goals related to this project," no one can say that's
dumb. Again, psychology, right? Look - We're walking around that. - Yes. - So the Mad
Libs that I use, and I do it this way, and I say, oh, poor me. Unlike you,
boss, grand, boss, great boss, I don't fully understand business code. I don't say
that out loud. But I say, in this really simple format that will help me
communicate your grand vision, oh, poobah of geniusity, we need it like this.
Increase or decrease, some important metric by some amount with a number in it
within some time period. So always it starts to increase or decrease, and then some
important metric, and I'll even give you lists of metrics for websites, for whatever.
Like a number of people who create new accounts, it could be a metric,
it could be a amount of time on each customer support call, a metric could be
decreased, the number of subscription cancellations, whatever it is a number, and then
buy an amount, not just decrease, but like how much, 20%, 50%, 412%,
what is that number? And there's a genius to ask you for that. And then in some
time period is to save our asses. So those usually look like within six months of
launch within three months, whatever that is, because immediately changing a feature
doesn't immediately change a metric. So, that's the broad brush and then,
you know, there's a couple that you would think it would be easy. It is never easy
for them to do this and the genius part. And then I asked them to prioritize them,
which is again, like another brain twister for them. But that number that I said
increase or decrease, like decrease the number of customer support calls, I don't
care whether it's 20 % or 3%. I don't care whether it's 20 % or 80%,
I do and I already know the answer parenthetically. But what I care about is that
the head of customer service says 1 % and the CFO says 75%.
If you don't get to that specificity and have them agree on it before you fucking
start your project, you're assumed because nothing you do will satisfy anyone. That's
the alignment. Each one of those things they could assume there, if everybody on the
senior team was aligned, that business goals mad libs would take five minutes.
Instead, every single time I hear we're not going to need to spend time on that,
we already have it, never once have I had clarity on that, that I haven't had to
help them with. I'm being snotty, but it's our job to help them with that,
without getting fired. - I love this so much because it's all about the art of
pulling out these constructs, getting them down physically, and then forcing explicit
decisions and ideas around these, because you could even say, "Yeah, we wanna
customer churn, but if this person is thinking 1%, that one's thinking 75%. That's a
recipe for disaster in six months when the numbers come in and everyone says, well,
I was right and you were wrong. And we should have done this. But if you get
people, then you can hash it out. If this person says 1%, that one says 75. Now
we have a conversation now to say, okay, well, what do you mean? Or, or why is it
you're saying that? Yep. It's a recipe for disaster, aka tornadoes,
because six weeks into the development process, if you're assuming that you only have
to tweak the number down a little bit and the CFO sees your design review, they're
going to freak out because they're like, how is this going to reduce it by 80 %
and you're going to be like, what the hell is happening? That's exactly it. And so
the other thing that I'm, the reason that I've like been like, God, Tim, are you
going to need to get back out there with this is I'm very proud of this process
and I'm proud of this process because it's deceptively simple and everything we do
in the world of product in UX, we know it's right when it seems obvious. But it's
really, really hard to get something down to simple and the simplicity of describing
the process, the simplicity of saying and demoting it intellectually by saying it's
business goals, math, lives, it's all on purpose because, and a lot of it is
showing your belly, so often what I say to people, first of all, do not do this
more than a level above you. The first time you do this, you say, "Boss,
here's what I think I'm hearing from you and the other stakeholders at our all
hands or at our last org meeting. I think I'm hearing that decreasing the time on
customer support calls is really important, And it sounds like by a lot. So I'm
assuming like 50%. And I'm also hearing that they're desperate to get subscriptions
up. So I have no idea how much they mean and on what time period. You send them
that and you say, "Can you help me understand, am I right, am I wrong?" And this
will really help me help my team understand it. You show your belly. And what that
does is it gives your boss an email that they can forward to their boss and say
how can we help clarify this poor Tamara and her tiny little brain, right?
Because it gives your boss cover as well. Right. Or seeing this, I've realized,
I don't actually know what you, you know, now I'm talking as the boss. Seeing this,
I don't really know. I realize, I don't know, do you guys want it down by 2 % or
80%. It helps them ask in a non -threatening way,
but you're asking a question that nobody can fall you for asking. And just all
provides focus and related to this seems to be the magical sentence. Can you tell
us about that? Yeah, the magic. Okay, so you go through this, business goals, mad
libs, and you create these alignment personas through that process, then you
prioritize them so that you get to a magical sense, which is if our primary goal
is to decrease call center calls, number of call center calls by 10 % within the
next three months. And we don't make Raven, not a Raven,
but any name ridiculously happy. What the fuck are we doing? Because Raven is the
one who is, or it's Carl, complaining Carl, Carl complainer.
If we don't nail it for Carl complainer, what the hell are we doing? He's the one
who's making the calls. So it's not even about who's more important or less
important, it's just like it's kind of a dull thing. Like if we don't nail it for
Nancy Newby and our main goal is to get new account holders, what the hell are we
doing? It's never going to be that groundbreaking for your team if you're in product
or UX. It's not. And that's why this alignment process is so interesting because
Most of the time, you don't need data to get really useful insights.
If you are doing like I did, you know, several financialists, I don't just work
with financial institutions, but if we end up creating personas and one of them ends
up being Nancy Newby, pro tip behind the scenes, one is always gonna end up being
Nancy Newby. You just need them to create it together to realize that. She's, first
of all, evergreen.
Second of all, you can look at the existing process for creating a new account in
one case that will forever stick in my mind. I tried being Nancy Newby and creating
an account and I physically couldn't on a website because of a third -party piece of
software that made it impossible that nobody had looked at in 20 years. So you end
up with a sentence. If our primary objective is to get new account holders in the
next six months, and we don't nail it for Nancy Newby. What the hell are we doing?
You don't need data to know that Nancy Newby exists. You may need data to know how
old she is or what her spending habits are or whatever, but you can also just look
at this through the perspective of the eyes of somebody who's never been to your
site before and see if they can create a fucking account, and most of the time
they can't. So if you create that sent and suddenly you have fresh eyeballs on old
problems and on really basic fundamental stuff that we shouldn't still have to argue
about. But we do. There are still major bank websites where it's really hard to
create a new account. If it wasn't, then you all could yell at me about data all
you want. Well, speaking of data. Yeah, go ahead. No, I'm sorry. No, no, no. Well,
no, I was just kind kind of extended for... So can you talk about the touch on
hypotheses before data and the importance of that? And what were you taught in
seventh grade? Well, yeah, that's right. It's fundamental of science that you're not
supposed to just collect stuff and then look at it and then say, "Hey,
well, it looks like ice cream causes murder." Right. Why? Lack of ice cream causes
murder, by the way. By the way, lack of ice cream in my world, why do we do
that? Why is that part of the scientific method? I'm going to turn it on you. Who
avoids spurious conclusions because unless you have some overarching, and I think it's
a bigger problem today because we have so much powerful technology to collect data
And potentially, you're right around the corner to make decisions, right? You know,
oh, we've got this thing running on our website and it collects what the users are
doing and then it updates and does design decisions, but you're not, that's so
bottom -up. You need some top -down in there. You do. And I'm not saying, listen,
and I'm trying to find people who are really great thinkers in diversity,
equity, inclusion, the problem with stereotypes, and all of those problems in
technology. Because I'm not sophisticated enough, I still have a lot of learning to
do. What I can say, and I would love feedback on this process from those voices,
when I am fundamentally saying it's not that the assumptions are all correct, it's
that you can't get rid of them until you know what they are. A hypothesis says
there is a hypothesis says, hypothesis is an assumption. It's an educated guess.
Yes, there can be whatever that is bias in looking at data when you have
assumptions about what the results are. Like predetermined, oh god, something, all
kinds of bias. Of course there can. But there is The bias that you're fighting
first is the bias of these very powerful assumptions that already exist in the mind
of your stakeholders and you cannot get rid of them until you know what they are.
That's all I'm saying. The follow on from that is that sometimes when you align
their assumptions, suddenly they get refocused on some really great fundamental stuff
that they've forgotten like there are new users trying to create accounts. And
everybody forgets about that, which is so fundamental that it doesn't require data to
say, there are new users here who might be confused by our website, right?
You can look at it and see that. They just haven't been able to see it because
they've been so focused on the Featuretron 5000 and the AI features and the widget
box of a new section of the advanced features. - Yeah,
there's so much good stuff today. You know, it's thinking about the opening analogies
with the house, the weather. I also think of while you talk about it of like a
physical launch, and you might have even said that, I think, in one of your, you
know, you're launching a rocket and you need to make sure there's no hurricanes,
tornadoes and all of this stuff so you can of a successful, clear way for your
lunch. - I didn't, but that's good. Now I'll just pretend that was clear. (laughing)
- Yeah, so, so much stuff you went over today. And I wanna make sure, you know,
so the audience knows that you flesh these things out in your workshops, and I'm
sure you point people to those when you've got those coming or whatever when your
book is getting ready to be published. They can get the details for how to actually
do these things, execute these things, you're hearing sort of the philosophy here,
but there's all kinds of nuance to the methods. Well, there should be more nuance.
There's huge nuance to the method. There should be more materials around it. I have
a problem. There should be courses, and there probably will be. Here's my full...
Let me give you an overarch of some of the structure here. Corporate Underpants is
my new podcast, and Corporate Underpants, the visible panty lines of org structure
that show through on our products and ruin experiences. That's this problem. It's the
problem of politics and personalities and process issues that ruin projects that have
nothing to do with our double diamonds, but demolish them. It's about the tornadoes,
right? And I'm not getting all book authors and stuff on here. I'm getting real
people who have tried to launch products and have these like train wreck stories and
who doesn't like a train wreck as long as you're not in it that we can learn
from. So corporate underpants is the result of launching a product that kind of
sucks because we underestimated or didn't control the tornadoes. Align,
alignment personas, align before design, executive alignment, that's all the solution.
And that's the solution, this this five step process that, you know, can be
shortened, can be lengthened, whatever that I do in any of my, no matter what they
think I'm going to do, I end up doing it in any of my contracts, right? And so
if people have projects they're interested in, and then I coach people who are
trying to become more senior in product and UX and whatever about these political
issues and how to get past them and how to become more senior by embracing it as
a fascinating problem rather than being snobbish bit you about it. We got to stop
being snobbish and bit you about this. So that's the kind of stuff that I do.
Workshops and classes and stuff. I've been really hesitant to launch stuff like that
in this arena because, not arena, in this climate of joblessness because I don't
want to be charging people for this stuff. I just don't. I want to, I mean, I do,
I'd love to have some money. I'm, you know, but this is what I'd like to do is
give the process away. So yeah, if people want me to create workshops on this or
whatever, tell me, encourage me, egg me on, be willing to be the audience so I can
record it, right? I would love that. Get in touch with me if you want to be a
test audience for this. And I'd like to teach all of us how to do this.
Yeah, so maybe create a book that's 20 bucks or something.
But then I want my projects to be the really, really hard ones. And that's what I
want to charge for. I didn't want to charge us for this. And plus my ego, like, I
want people to know about this and be like, oh yeah, that is really good. So
that's what I'm trying to do.
And that's, and so listen to Corporate Underpants, give it a review, just like I'll
give yours a review. I mean, all of you. And if you have crazy stories like this,
like you're someone who's been around the block a few times, tell me and maybe you
can be a guest. And then the line before design, just egg me on everybody, come
and follow me on LinkedIn. And if you want some coaching, if you're like, "Damn,
I need pragmatic help getting past the utter clusterfuck that my organization is
right now, especially because I don't want to leave my job because there are no
jobs out there and you have a budget for it, contact me because I can really,
really help you with that. I love this. I love this. I hope everyone checks out
all the stuff you're talking about, your podcast, corporate underpants, the upcoming
book, maybe it takes a couple of years to finish, but now that we're talking about
it, maybe it makes you extra.
(laughing) And folks can find you on LinkedIn and all of that. Tamara, it's been an
absolute pleasure having you on today. Thank you for being here. - Oh my God, back
at ya. I love that you brought up some of this stuff I haven't talked about in a
while, like the history of personas and all of that because I'm so focused on this.
So thank you so much for loving this topic of psychology and organizations and for
giving me a chance to have such a great conversation with you. So, to wrap things
up, this conversation with Tamara Adlin reminds us that personas aren't just about
understanding users, they're about aligning teams and shaping strategy and protecting
the product from being pulled in a whole bunch of different directions. We talked
about the reality that understanding tends to break down across departments and how
alignment personas can serve as a fast and powerful remedy.
We explored what happens when you get executives in the same room to surface their
assumptions by artfully asking the right questions, sometimes in just a two -hour
workshop. We looked at tools like the strategy wedge and the purpose slide,
not just as artifacts, but as bridges between vision and execution. And we touched
on what happens when design psychology, as it's normally practiced on the product or
service, meets organizational psychology and how narrative and empathy and shared
mental models can de -escalate chaos and give teams something to rally around.
One of Tamara's most important reminders is this, assumptions are a fact of life.
Every team has them, every leader brings them, but when you surface those assumptions
together, you give your team the chance to deal with them directly, to decide which
ones hold up, or which ones need fixing, Which ones are quietly shaping everything
you build? You know, someone back in college once told me that psychology majors
should always be successful in their careers, because they understand how people work.
Well, I'd like to flip that following today's conversation. Design psychologists should
be able to make any organization successful. We have the skill set not just to
shape products and services, but to influence the culture and clarity and cohesion of
the teams behind them. In the end, when we apply psychology inward toward alignment
and communication and decision making, we're not just designing for users anymore.
We're designing organizations that work better for everyone outside and in.