Design Meets Business

Christian: Jehad, it's a pleasure to
have you on design Meets business.

Welcome.

You have led design for some very complex
products and very complex ecosystems

such as VMware and even today in your
role as Chief Design Officer at Toast,

where you're shaping how design connects
across product and platform and culture.

We'll get to talk about that in a second.

You also write extensively, and
you have written in the past about

organizational design, ai and the
evolving role of design leadership.

We'll hopefully get to talk about
all of that today, but to set the

stage before we dig in, could you
share a little bit about your journey

and what led you to this point?

Jehad: Yeah.

Thank you for having me.

I'm, I'm excited to chat about all these
topics and more I am an engineer by

training, so I I started computer science.

I started my career as an engineer.

And the more I spent time writing code,
the more I realized one of the things

I deeply enjoy about the process of
building product is actually the kind

of problem solving piece and working
closely with customers on what problem

are we trying to solve, how do we solve
it, and how do we translate the mental

model of a problem into a product which
was really exciting, which is what got

me into spending more time on design.

And then where I am today, and I'm like
a hundred percent focused on design.

Product building is still
how I think about design.

It's solving the customer problem,
but also the problems around the

customer problem . How How do you
solve the way you build product so

you build a better product . How do
you think about the tools that build

product, whether it's AI or before?

Design how you translate problems into
solutions in my mind, which is one of the

most exciting careers someone can have.

Christian: Yeah, it's uh, you get
to build the future, isn't it?

If you work in

Jehad: product.

So I guess,

Exactly.

Christian: How uh, was that transition
from, for you, from being probably very

technical and sitting in front of a
computer writing code and all of that to

moving away from that and expanding into
product and design, which are, they're

adjacent, but also probably on a daily
basis, quite different, aren't they?

Jehad: Yeah, I think so.

There are interesting
similarities and differences.

AI is changing this a little
bit, but there's nothing more

powerful than hands on keyboard.

So the ability to be able to write code
and translate an idea into something in

production is just massively powerful.

Gives you a ton of agency.

Vibe coding and AI prototyping
tools are kind bridging that gap.

So like tons for designers to get more
agency and get more ability to be closer

to the keyboard if that makes sense.

There are a lot of similarities.

You're solving problems as
an engineer solving problem.

As a designer, you may be solving
slightly different problems, but

you're in this problem solving space.

You're creative in both.

Very creative in both.

So I think the transition wasn't
as, as extreme as you would imagine.

The one thing I would say is knowing
engineering and knowing design.

The, The way I would describe it to
teams is I feel at times like I'm

bilingual and I can bridge gaps in
the conversation between the two.

In the discussions about, for example,
should designers code or should designers

know about product management or
whatever, I think like languages, the

more languages you know, at a certain
level, you don't have to be fluent in all.

Then the more of a true native experience
you'll get in any country you go to.

So like, I wish I can speak
all the languages in the world.

So when I visit a country,
I'm actually closer to that

experience, closer to the culture.

And even if you speak a little bit,
even if you're able to get a word

here and a word there, you're probably
better off than going somewhere else

and speaking your own native language.

I think of engineering, product,
sales, customer support, whatever

organizations you deal with, the more
you learn about them and speak their

language, the closer you are and the
more likely you're able to build deeper

partnerships and deeper relationships.

So I'm lucky to have that background
in engineering, but every single

designer has a background in something
or is passionate about something or

really wants to know about something
and that's extremely powerful.

Christian: I've never thought about it
in the same way that analogy of it's

like a language and it is so helpful
even if you just know a few words.

And I think looking back at my own
experience, I've I can't say I'm

trained as a computer scientist,
but when I started out very young,

I did start out by coding as well.

And after a few years, I realized
it was not my, it was not my thing.

I preferred more the design side, but.

It did come in really handy, just as handy
as knowing a few words when you go to

Spain on holiday or whatever it may be.

Just as handy as that, just
enough to be able to communicate.

Not in the sense that I'll be able to
hold a dissertation in Spanish, but

I'll be able to order something in
a restaurant or ask for directions.

And I if we use that analogy in a product
team, I think oftentimes I hear from

engineers, some of their frustrations
are, design is coming up with all these

things which maybe look great in Figma and
they can be done, everything can be done.

But they're not thinking too much
of the trade offs of, okay, if we're

spending so much time to do all of
these things, which is great, then

we can't do or we have to ship slower
or we can't do these other things.

There's just so much there.

And I think when you know the
language, you all can also think

a little bit of the trade-offs
and you might design differently.

And I guess the same

E

right?

Jehad: Yeah.

And I don't know if this analogy is
gonna take us, is gonna work, but

kind of continuation of the analogy
and the locals deeply appreciate it.

So even if you go to a country where
they still speak English as an example,

the ability to say a few words is also
a signal that you appreciate the culture

you're trying to work with or you're in.

So your ability to, for example, even
understand the basics of how the sales

team sell or how the support team
supports, or how the marketing team

works and what they're focused on.

You don't have to be an expert, but
just showing to the curiosity is

deeply valuable in how you build that
relationship and deeply valuable to what

people are willing to do to also do the
opposite, which is learn a little bit

about how design works as an example.

Christian: Yeah.

I you're talking there about building
relationships, which is something that

I'm a big believer in, that the better
relationships you have at work with your

cross-functional partners, the more likely
you are to first of all work in a place

where everyone gets along with everyone
else, but also because you're able to

start conversations with them from a
different sort of personal relationship

a better personal relationship.

I also tend to see that they're a
bit more willing to go the extra mile

for you 'cause you are a bit more
willing to go the extra mile for them.

So I think I, told this story before.

I used to work for a company in the
UK and I had this engineer who I

went and I showed him this animation.

I don't, today, I don't
even know what it was.

And then he spent the weekend building
it and came on Monday, super excited.

I spent the weekend building this.

I just wanted to do it because, and
his arguments were, I did it because.

You are so easy to work with in the
past and you already gave in and you

traded off so that we could move faster.

That I felt the need to
get back a little bit.

And I think that was the first
time when I realized, oh wait, this

is like any other relationship.

It's you do something for me.

I do something for you.

And it's not meant to be transactional,
but subconsciously you're more likely

to want to give something to someone
if they've given you something before.

Jehad: E Exactly.

at the end of the day building
product and designing product

is you're in the human business.

You're building with humans
and you're designing for

Christian: yeah.

even when I worked in, B2B and you've
worked in B2B for a long time, and you

can probably relate to this, there's that
saying of, yeah, well it is B2B software,

but at the end of the day, it's still a
human using the software at the other end.

Jehad: Exactly.

Exactly.

Christian: So let's talk about B2B.

Let's talk about the, VMware , Toast.

For anyone who hasn't heard about VMware
and Toast the big companies you've worked

for, when you've, you've been for a while
and you have important roles, what are

these companies, what were they doing?

Just so we can all have
the same foundation.

When we're talking about the next
things we're gonna be talking about,

everyone understands the context
of where you've been working.

Jehad: Yeah so, VMware is in the so
it's an enterprise software company

that is now a part of Broadcom.

And it, it's basically the origins
of the cloud business or what we

call today, the cloud business.

And it's how customers run their
infrastructure for the most

part today on private cloud.

But also VMware has many different
products that manage how applications

get deployed, how infrastructure
gets deployed and so on, so forth.

Which is even though it's B2B
technically and toast is B2B, Toast

is in a pretty different business.

And our B2B is more focused on from
small businesses to enterprise.

Uh, So toast is what we call a vertical
SaaS company which is basically

looking at a certain industry and
solving all the problems top to bottom.

For us that's restaurants and
local retailers, local commerce.

And if you're in the US or even if
internationally you're in Dublin or

London or now Australia or Canada you
probably ate at the restaurant that

has Toast or you paid and you saw the
Toast receipt that comes from Toast.

We do everything from the point of sale
system to online ordering, to even the

back of house functions that a restaurant
needs, from payroll to marketing,

to inventory management and so on.

So it's solving all the problems
that a restaurant operator or

a local retailer needs to solve
to run a successful business.

Our mission is to help restaurants
and the restaurant community thrive.

Christian: As I'm sure everyone
gets, these are complex businesses in

with, there's just so much complexity
behind, let's not talk about VMware.

Let's just talk about restaurants.

Like you said, that vertical inside of.

We're talking, reporting,
accounting, we're talking uh, you

know, what's the interface that the
user sees, if there's any at all,

or maybe the user is the waiter.

What, there's just so much there.

And one of the things I want to talk
to you about today, having worked in

so many complex ecosystems, is, and
to be fair, this doesn't only happen

in complex ecosystems, but how do you
ensure that the team that you have and

everyone is working on a corner of their
app, not only communicate with each

other, but as a result of that, don't
really ship the organization structure?

I think a lot of companies tend to
ship their org structure, and I have

worked in organizations where it was
very clear you go to the website and

you see where a designer has handed
off to another designer or a team has

handed off to another team, I assume
you have a lot of experience with

that why is that such a hard trap
to avoid to ship the org structure?

Jehad: Yeah.

If you think about how
software gets built.

We were just talking about
how relationships happen

and it's a human business.

If you think about how software gets built
at scale, the way most startups start

is that you start with a single product
for the most part, and a very small

team where the communication channels
are, you know, you, you literally sit in

the same room and build the same thing.

And because for the most part, as a
startup, you're trying to survive you have

laser focus on the things you need to do
for you to solve the customer problem.

As you scale and you become a larger
company you have different forces that

push you in different directions where
one, keeping that focus is difficult.

But two, the org structure that grows as
the company grows deeply influences what

you're shipping because at the end of
the day, again, it's a human business.

And each org has its goals.

And these course orgs connect in
certain ways, and there are people who

work in certain ways or the different
ways and certain orgs and so on.

And org structure is both the most
influential thing on how you build

software, but it's also the hardest
thing to change because imagine if every

time you discover the problem with the
org, you did a reorg, and every week

you're moving people around to be able to
say, okay, like now it's a perfect org.

Yes, you probably are getting
closer to the, to a better org

structure, but you're also driving
everybody that is working crazy.

Imagine your manager changing every
three days because we discovered

the learning about actually the
software needs to pull in this way.

The other challenge is there
is no perfect org structure.

It's only trade-offs, and those offs are
about what you're trying to ship today,

what are your goals tomorrow, and then
what are the long-term goals overall.

So there is no perfect or structure
that's gonna be perfect for

every single piece of the product
ecosystem that you're building.

Once you understand that, then the
next step is, okay, how do you optimize

the org structure you're building
for the most important set of 2,

3, 5 goals that you wanna achieve?

And how can you be thoughtful about these
goals so they're not very temporary goals.

They're not for the next two weeks
or for the next two months, therefore

the next 12 to 18 months at least.

And then once you do that, then the
question is, okay, for the things you

did not optimize for, how are you making
those trade offs more thoughtfully?

So you're aware of the way
this org structure was designed

to optimize other things.

So you're able to say, okay,
I'm building a product that is

part of the onboarding journey.

This org structure was actually
optimized for driving more

usage within the product.

So I understand that there is a trade off
here with how onboarding is structured

within this org, and I'm gonna build
around that trade off to ensure that

that trade off doesn't end up resulting
in the worst customer experience.

That's Actually really hard to do.

It's not super hard to do initially,
but actually keeping that thought

in mind and optimizing every
single week is really difficult.

And two things that designers have a
superpower here that they can influence.

One is service design is such a
powerful force in bridging the gap

between org structure and customer
journey and customer expectations.

Most organizations don't have
enough service designers.

And my prediction is that the more
we build AI first experiences, the

more critical service design becomes.

Because for the most part, we're building
pieces that are gonna come together.

And without that view of what are
customers actually trying to achieve

it's gonna be really hard to do this.

And the second piece is how do you
influence org structures to optimize for

customer outcomes that you wanna achieve?

And that's, really hard,
depending on where design lives.

In an org, But designers often have a lot
more influence than they think they do.

So influencing those outcomes or
influencing how we wanna build the

structure in a way that results
in the right outcomes becomes

extremely extremely important.

And then the third piece that designers
can do, or the design teams can do is how

do you bridge these gaps more thoughtfully
by focusing on translating things like the

right design principles, design systems,
things like, connective tissue teams the

teams that look across the journey, for
example, how we're supporting customers

across the board, how we're doing
onboarding customers across the board.

How are we upselling
customers across the board?

Design teams can have a ton of influence
in these shared experiences as well.

Christian: I'm trying to think about
this from both perspective of a, a

designer, an individual contributor, and
someone who's a bit higher up in design

leadership and perhaps has a bit more
pull to influence when org structures

or reorganization happen in a company.

And I'm thinking if you sit at
the individual contributor level.

You have your little box in which
you're working with the KPIs given by

your design, not design lead by your
product lead or who whatev, however the

structure of the businesses is made.

Every day you have to cater to
that KPI that you're working on.

And the KPIs in a growth team, for
example, can be different than the

KPIs in the new beds team, which can
be different in the KPIs or whatever.

And I think that's where a lot of this
tension comes from at that individual

contributor level where you sit and think
it would be great if I would quote unquote

hand over users to someone else who would
take them from the same spot and would

continue the same experience, but they're
working with a different KPI than I am.

So at the end of the day,
I can't control that.

I can't control what
KPI they're working on.

All I know is that I've been given
this number that I need to move.

And if you have, you're lucky.

Many companies, you're probably
not even given a number to move.

You're just being told.

Make it better without
that meaning anything.

Anyway, that's a tangent, but I'm just
trying to get at it from a perspective

of an individual contributor sitting
in one of his companies thinking

this experience is not cohesive.

And I can see why, because the, we are
working on different goals and then

you say there are things that you can
do, so on a daily basis, what are some

of those things that I can do as an
individual contributor in any sort of

company, small, medium, large, whatever,
to close that gap a little bit more.

Jehad: a few practical things you can do
regardless of level one is sitting down

and thoughtfully thinking about what are
the principles driving this experience.

And when I say principles, or maybe
tenets is a better word, but like clear

tenets that are related, this experiences
that have some hard edges to them.

For example, if you're in a growth team
and you're thinking about what are the

tenets of this experience, one tenet
can be we wanna retain this customer

for the next 30 days, or we want this
customer to use more of our products

over the next 60 days Or for example, the
tenet could be, we wanna ensure that the

more of our products you use, the more
likely that you are retained post 60 days.

The reason that's a specific tenet
is because one, that means you're

optimizing for multi-product use cases.

So if someone comes in and says,
actually the most important

thing is my product gets adopted.

Actually it's, that's not
the tenet we're going for.

We're going for platform level adoption,
not specific product level adoption.

it has a hard edge there.

Another kind of hard edge to it is
that you're focused on 60 days as

a metric for your area of impact.

So like, it has some hard edges and tenets
are pretty hard to come up with because

most tenets that you see at times that
are a bit aspirational and fun, but not

really, don't have hard, for example,
we wanna give customers an amazing

experience in, in their first 30 days.

That's not a tenet.

Because if you think about at
least for me, I think about the

versus what like versus what Well.

nobody's gonna say, we wanna
give customers a terrible

experience over the next 30 days.

So like, why is this a tenet?

What is it actually trying to change?

What is it actually going against?

And if you make those tenets clear
early on in the process and you keep

updating them, it actually forces
really deep conversations with teams

that are less about org structure,
even if that's true, but more about

what are we actually trying to do here?

For example, if someone comes and
says, actually, we wanna optimize

for a single product use case,
don't worry about the platform.

As Long as they adopt one product,
we feel like we can return them

better and then we can give them, to
onboard and more products later on.

Okay, that's a great debate.

And now we have a chance of saying
here's the data that we're seeing.

Does this make sense, not make sense?

If we're optimizing for a single product,
is it this product or that product?

We optimize it for the platform we
would actually need to onboard them

differently so they're more attached to
the platform versus a single product.

Like it creates some of those
great discussions about what are

we actually trying to optimize for
before any screen has been designed

or any experience has been designed.

So being thoughtful
about the tenets is one.

Second.

One, if there are KPIs, being
thoughtful about KPIs and making

them clear to other teams you're
interacting with are extremely powerful.

Because just knowing what you're
trying to optimize for may help

me actually as the designer on
the other end of this experience.

may kind of help me think through
the trade offs I need to make.

And the third one I think of that
would really help is start at least

if you're designing a ui, obviously,
you might be designing different

modalities, but just to take a UI as
an example, always start one screen

before the screen you're designing.

So if you're designing a reporting
dashboard, how do customers get

to this reporting dashboard?

If you're designing the login page,
how do customers get to the login page?

A lot of times when people say,
customers start here, or customers

start at our login page my pushback
is actually customers start at.

Or they start actually on your
marketing website or they start from

an email, a sales person sends them
prior screen to your screen could

be a phone call or a support ticket,
or a marketing email, or it doesn't

have to be even in your product.

and just including the screen
before, and the screen after

it just gives a view of one for
teams around you to think about it,

and two, for you to be aware of what
are you actually optimizing for, in

the context of an ecosystem versus
the four walls of your experience.

If that makes sense.

Christian: It makes complete sense.

It's a very good uh, tactical
trick right there, or a tip.

You were talking about these tenets and
I think you gave an example, but I'm

wondering if you could give a couple more
examples of what a good tenet looks like.

One of these that can start a conversation
or that can help us at least think

a little bit more about what is it
really that we're trying to do here?

Give us a couple more examples.

Jehad: Yeah.

So let's take a couple examples.

So let's talk about some of
the AI experiences all of us

are kind of designing now.

One tenet could be every action a
customer takes with this AI first

experience needs to be auditable.

What does that do?

That says, okay, each
action needs to be tracked.

An audit trail needs to exist, an
out trail needs to be visible to

customers, and that each one of those
actions is actually out there with

an easy way for customers to audit,
if you say versus what versus actions

are temporary Within that experience.

Or versus saying we're gonna optimize
for ease of taking the action, but

looking back and ability for us to
actually look through what happened

is secondary or can happen later on.

This kind of puts integrity at the
kind of the center of the experience.

The tenet that might not have
been as useful, even though

it has a similar spirit, is to
say, we build with integrity.

Or like integrity is
important to our experience.

It's really hard to argue for someone
to say, actually, I don't think we

should not build with integrity.

Versus if you say all experiences
are, all actions are auditable.

That's a very specific take
on what integrity means.

And actually you could argue against it.

You could say, actually, I don't
think they should be auditable.

I think we should just make sure we
double check before a customer takes

an action As long as we DoubleCheck.

Audit is secondary.

Integrity is in the ensuring that an
action is taken based on the customer's

request versus that it's auditable.

You can debate this and you
can discuss it, but it allows

for that debate to happen.

It also allows for the debate of
what integrity means to be discussed.

Is this actually a tenet or not?

Is this actually that important or not?

Another example think about is to say,
we're building this AI experience and

a tenet of this experience is a human
has to confirm before any action,

no action can be taken with ai, by
the way that's a very strong tenet

that could be risky for the future.

So you have to think about it like,
are you really not gonna allow

agents to work in the background?

Are you really gonna say that, even if
a user says, I just do this every time,

that they have to confirm it every time.

The flip side of that is you're
saying that there's a human in the,

you're codifying what a human in
the loop means for your experience.

That's actually a tenet.

You and I can debate for few hours,
because it has so many implications.

It's actually pretty important
to how we design the experience.

The confirmations always need to happen.

Can agents work in the
background, et cetera.

And you can, by the way, evolve
that tenet in the future.

So you can start with that tenet.

And then a year later, when you
have a ton of confidence in your

agents, it evolves into all actions
taken by AI needs to be auditable.

So you're no longer, you kind of retire.

The tenet of every action
needs to be taken by human.

And you say, okay, all
actions need to be auditable.

But you can see how these two
tenets, for example, they can follow

each other, but they also codify
some key pieces of the experience.

I think the problem shows up when you have
tenets that sound great, especially to

the design community, but don't actually
force any sort of important conversation.

For example AI experiences need to
look good, or AI experiences should be

great, or AI experiences should have
high integrity, or customers should

be aware of the actions being taken.

What does aware mean?

Nobody's gonna be able to argue
that they shouldn't be aware.

So the having those hard
edges makes a huge difference.

Enforcing that debate and then
settling that debate on, okay,

what are we actually designing for?

Christian: So let me play that back.

It sounds like one of the main principles
here is that tenets need to be I dunno

if the right word is measurable, but
you can't just ask what does that mean?

Like you said, it has to be great
experience, okay, we all agree we

want to ship a great experience ' cause
it's great for me is different

than what is great for you.

So what does that mean versus if you
say you purchase something, right?

Maybe the tenet is, we wanna always
make sure that people understand

the actions they've taken.

So if you purchase something,
you have to understand that

you've purchased something.

So maybe that's a tenet.

This reminds me of that framework
of setting goals, which is smart.

I'm probably gonna butcher them, but
it's SI don't know, M is measurable.

A is actionable, one of these, right?

I think it's, it's sort of the same, isn't

Jehad: Yeah,

yeah, Exactly.

And I think the beauty if you set
up the right tenets early on is that

you can always come back to them.

One way to think about them if done right
is I think of it like it's the if you're

in the US it's like the US constitution.

There's a set of laws that
require a body to ratify.

You can't just wake up in the
morning and say, you know what?

That tenet, forget about it.

The bar should be once the tenet,
the bar for proposing a tenet

early on, the press should be low.

Like we actually wanna get the
best minds on what are the five

or six tenets that we have.

Once those are codified, once
we've discussed them and debated

them and so on, then the bar to
change them should be very high.

It should be that everybody needs to
get back in the room and re- debate

for us to evolve a tenet, because if
tenets are changing every day, then

they're not tenets, they're ideas.

But also you don't want them to be
codified in a way that can never

be changed, but the bar should be
pretty high to changing them because

the whole DNA of your experience is
based on those four or five tenets.

Christian: I think this is, it makes
me wonder, listening to you, if this

is not something that should be at the
core of how we design, like you should

always know what you're aiming for.

We as a team should always
know what we're aiming for.

It should never be a matter of, this is
a word that's being used quite often is

I want the experience to be delightful.

I add some more delight here.

We can all agree that more delight
would be nice, but what does that mean?

So again, I'm wondering whether it
is an argument to be made that you

don't even need to call them tenets.

This is just how we design.

We need to understand
measurably, is that a word?

That is definitely not a word we
need to be able to measure why

it sounded like a word to me.

Hey, non-native English speaker here.

So I'll take it.

You've been mentioning this a couple
of times already, versus what you've

been mentioning the word trade offs
a couple of times, and I think trade

off is something that you become very
aware of as you grow in your career

that there's no such thing as, I think
when you're a bit younger, probably in

your career and in life in general, you
tend to be a bit more naive and think

that you can have your cake and eat too,
when in reality, more often than not,

there are things you need to trade off.

You can have the cake, but you're
probably gonna put some weight on.

So even there, there's a trade off.

So tell us about what versus
what is and how you're using it.

Jehad: Yeah, I think it, the way I
think about the versus what on tenets

in particular is always a kind of a
measure of how hard edged the tenet

that you came up with or the even
the thought or idea you came up with.

And is it actually evoking
the right level of debate?

Is it actually evoking the right level
of thoughtfulness that's actually

gonna help you three months from
now, or six months from now when

you're iterating on this experience?

For example, let's take delightful.

We wanna make the experience delightful.

There is no verse in my mind.

There is no versus what to
that because the versus what

is a bit silly or illogical.

We wanna make the experience delightful.

What is the versus what is, we wanna make
the experience not delightful or crappy.

Nobody's gonna argue that, by the
way, even if they don't care about

delight, they're not gonna step
forward and say, oh, I don't care.

Like delightful doesn't matter.

Delight customers, doesn't matter.

The flip side of that then, just as
an example for a growth experience,

is we want every, we on average,
for every customer that onboards to

invite at least one more customer.

Okay.

You've translated delight into, okay.

It's a being, like being an advocate
or a raving fan of our product.

And I could, I could say versus
what actually recommending a

customer is such a high bar.

I don't wanna go there.

We want every customer that
onboards or whatever, 50%

whatever, is to stick around.

We want our adoption to be x.

That's actually not necessarily
delight, that are a lot of not very

delightful products that have high
adoption or high retention because

they solve a deep customer problem.

So if you want, for example, the beauty
of the product to be something that you

deeply care about, then you can say, we
wanna, like a tenet, just as an example.

We don't ship a product until we're,
the whole triad is proud of it.

that's a tough tenet because, people
have different bars of execution, but

it's still a level of hard edge that
gives you some ability to your point, to

measure some ability to be able to say
there's an argument to be made against it.

The best way, by the way to think about
this is you should be able, before

you propose a tenet, you should be
able to make the argument against it.

You might not believe in that argument.

you know, you, you might have a, an
argument against that argument, but if

you're unable to come up with an, with a
logical reasonable argument against the

tenet you propose, then it's probably
not a tenet that's worth proposing.

Obviously the argument you're
gonna come up against it.

You already don't believe in
for if you believe in the tenet.

But it should be a logical argument.

It should be an argument that if you hear,
you wouldn't say that this is nonsense.

Instead you should be okay, I
hear you, but here's why I would

argue for the tenet I'm proposing.

But if you can't come up with
a logical argument against

it, it's probably not hard.

Edge enough.

Christian: This reminds me of debate,
clubs, whatever they're called, where.

You just draw something and you have to
debate for or against it, whether you

believe it in it or not, in personally
you still have to go and do that.

I guess it's, it's kind of the same
you need to come up the opposite.

you decide on these tenets at a company
level, is that something we, as a company

we want to make sure we have these four
tenets and everything we design and we

build and ship has to pass that bar?

Or is it a bit more granular where
every team gets to decide their own?

And I, And I guess probably by
asking the question, I know the

answer, but Yeah, just hear your

Jehad: I think it's, I think it's both
harder to come up with them at the broader

you are, the harder the tenet is because
you're grooming under it a ton of stuff.

It's much easier to come up with
tenet on a specific experience because

it has limits of how far it goes.

One example of a broader tenet from
my friend Bob Baxley who's a great

design leader is for his team was
documentation is an error state.

If a customer needs to go to
documentation, it's an error state.

So every single time a customer
looks at up documentation we've

not done a good job on design.

That's a such a hard edge tenet
because obviously people are

gonna look up documentation.

It's not like it's gonna be zero,
it's very different than saying the

product should stand on its own.

It gives you a very specific way to
look for what is the failure state.

The argument against it is to say,
actually, I can come up with a pretty

logical argument against it, which is
actually documentation is a helpful tool.

Not every customer navigates
products the same way.

Some customers actually find
looking at documentation to

be reassuring, by the way.

Not necessarily that I agree with
that argument, but that's a pretty

logical argument to walk through.

All products have documentation then why
are we coming off the documentation to

begin with if we're saying it's an error.

SA like there are a bunch of logical
arguments to make against it, but

it's such a hard edge tenet that's
pretty powerful to set forth.

Christian: As you were talking,
I was thinking well, I could

make both of those arguments.

And I think really what it comes down
to in the end what is the type of

experience we all in the team agree on?

So perhaps there's nothing wrong with
having documentation, let's just use

the same example, but we as a company
or we as a team want to build a product

in such a way that's not needed.

Not because it's wrong, but because
we are opinionated about how we build

products and we want to do that.

I remember when MailChimp was really
popular in the past came out with their

very opinionated um, tone of voice.

It was very playful.

It was arrogant at times, or maybe
arrogant is the wrong word, but

it was very cheeky, definitely.

and some people hated it.

Some people hated MailChimp
because it was talking to you from

up here and you were down here.

So it was a bit weird.

But there's not a right or wrong that is
just the way people at MailChimp decided

that they wanted to build product.

So I guess it's just it does, it's
not about being right or wrong.

It's about how you wanna
build product, isn't it?

Jehad: It's, It's about being opinionated
about how you wanna build product,

like having a very specific point of
view about how you wanna build product.

And being able to hold that view for
long enough that it's worth codifying.

Christian: When you lead a project, I
mean, I don't know if you still lead

individual contributor work today, but
uh, when you used to or when your team

is doing what is the typical process
of coming up with this versus what

or how to get the conversation going?

Is that something that's
happening super early on?

Are you encouraging designers to
bring that up at a kickoff or is that

part of their own design process?

Or maybe that's, there's no,
maybe it's not codified at all.

It just happens when it happens.

How do you do that?

Jehad: It's actually a constant
challenge to keep true to this.

It's really hard to come up with tenets.

A lot of time projects move faster than
you wanna be thoughtful about sitting

down and codifying this all the time.

But for the projects where it
matters a lot the sooner you're able

to come up with them, the better.

Often post a learning cycle.

So once you've had a chance to learn
about the problem space, or you've done

the research to understand it, or you
have at least some market research to

understand what the problem is, then
having a conversation early on about

those tenets helps triangulate what
angle you wanna take into solving the

problem remaining open after the first
or second prototype to those tenets.

Slightly changing.

If you're fundamentally changing them,
you're pretty much re- kicking off, but

to slightly change them, to framing them
in the way that they make the most sense.

And then for the lifetime of
the project, how do you hold

yourself accountable to them by.

One can constantly reminding yourself
and others of them, but also two of how

do you actually hold up your designs
to those tenets repeatedly in design

reviews and in conversations and critiques
and, and so on, in a way where those

tenets guide you throughout the process.

This is actually pretty
hard to do consistently.

So some projects may feel too
short or too small to require it.

Some projects may feel like
there's a, a tense sense of

urgency to get them moving faster.

Where this requires a slowdown, it is
a slowdown to speed up, but sometimes

not everybody has that luxury.

I would focus on this as a tool that
could help you, especially in areas

where you feel like as a designer, you
don't have a pretty clear view from your

partners and what needs to be built.

So it's your way of putting forth a
proposal on what happened, and then

guiding the conversation versus a
religious way of doing things where if you

don't have tenets, I'm not touching Figma.

Because then they become a
distraction from the original

goal of why these are important.

Christian: Like you said, maybe it's a
tool to bring the team around something

that we all can agree on and then we start
working based off of that rather than

I believe that it should be like this.

Then I present something
forward and I realize actually

nobody else agrees with this.

Yeah.

Okay.

So you have quite a few opinions
on AI and how it's gonna change the

design industry and probably the
product in general engineering as well.

So I wanna talk about that.

But there is one question that's been on
my mind about AI for a bit of a while now.

As I talk to people, they usually
say the same thing, which is,

innovation has always happened and
we've always adapted and that is true.

However, if you look at the past, at least
my interpretation of it, which could be

wrong, is that as past revolutions have
happened, they usually happen in one area,

the typewriter, Photoshop, Figma, Canva.

They're usually in one focused area.

I call it focused innovation.

If you wanted to get on with the program,
you picked up that specific tool, right?

And then you were onboarded to it, and you
could ride that wave into the next period.

And I'm talking to designers today
and they all feel paralyzed because

not because they don't want to
upskill or keep up with the time.

So because they don't know where to focus.

'cause AI is not focused.

Innovation.

AI is revolutionizing multiple
areas at the same time.

Should they use AI for deeper research?

Should they use it to get closer to code?

Should they overlap with way more with
their PM and write PRDs and all of that?

Should they upskill in motion design?

There are so many paths you could take
with all of this innovation that's

happening everywhere left and right that
no wonder everyone is a bit paralyzed

as to to which path should I go?

Is it all of them?

And if so, if so, how
is that even possible?

So I guess where do you decide
where to invest your time?

Jehad: Yeah, I think there are areas
where AI is just gonna naturally change

how we work, it sounds paralyzing
right now, but I think it'll be

an easy transition to some extent.

For example, one, one simple example
is most of us probably now do a

double take with ChatGPT or some
other product when we are writing

a very important email or a paper.

So if you're writing a memo that's
super important, you're probably doing

a double take with ChatGPT on a single
paragraph that you really wanna land

or a on on, making sure you don't have
any like glaring grammatical issue.

Or maybe you write in a certain voice
and tone, but you'd love to be read in

a certain voice and tone and you write
and change the voice and tone and so on.

That's such a natural way
of using an AI product.

I don't think you have to push
many people to say you have to

use ChatGPT to check your writing.

'Cause it just gonna naturally happen.

And the more we do it, the
more we use it and so on.

There are areas where AI is gonna be
a fundamental change to how we work.

So for example starting with a prototype
versus the PRD . We use an internal term

sometimes that we say demo before a memo.

In internally as, as as
we look at prototyping.

If you think about like demo before
a memo is such a weird change

to fundamentally how you work.

'cause previously you write a PRD,
you design the Figma based on it,

you review it, then you write it into
product, then you start working on

the animations or the how the product
interact or interaction design.

This actually fundamentally
changes your process.

Those are harder to adapt
to and require a push.

And then there is a larger change that
will happen, especially in smaller

places where, if I can vibe code a
product how is the designer gonna be

involved, or the other way, by the
way, how is engineer gonna be involved?

I can vibe code my way into the MVP,
then maybe that's all I need, which

is gonna fundamentally change how we
work collectively, not just as a single

designer, as a single discipline.

If you think about kind of those
categories, and there are probably

tons more, but if you think about
those categories, the things

that you can use immediately, you
should optimize to default to AI.

I don't think any of us in the next
three years gonna ever write a memo

or a paper or an article or a blog
post or whatever without some part

of it being edited or coded in by AI.

That's gonna happen naturally.

But also if you wanna adopt faster,
you should default to AI on.

For the things we wanna go, fundamentally
change the process of a discipline,

design for example, you should
think about it from the perspective

of it's giving you more agency.

The fact that you can start with a
prototype gives you a ton of agency to

show ideas to your partners and debate
those ideas in ways where maybe a Figma

couldn't or like a traditional design
end to and couldn't, or a memo couldn't.

So you now have a tool that can show
you, that can show the world your

thoughts in like an hour versus weeks.

That's so powerful.

How deep you wanna do it.

Do you wanna do it just to show
people you're thinking versus you

change the process how you design.

Okay, like now it's a deeper discussion
about how do you wanna change the

function of design in your team.

And then the third piece is if
you think fundamentally, like I

can build a product on my own you
wanna be at least aware of it.

You wanna be at least aware of that,
how that changes, because part of

it will see into how you design
product, then you should adapt to it.

And I think the bar is gonna
continue to rise very quickly over

the coming three years for how much
AI is a core part of your process.

You never wanna be underwater on that bar.

You wanna always be one step ahead . I
liken AI more to the internet versus, the

typewriter or Figma or something else.

But it's happening 10 x faster.

So everybody's coming online
overnight is, is how you'd imagine it.

And if you're the guy not using
the internet, then you're at a

disadvantage to everybody else.

Christian: I've heard this analogy
before and I'm wondering whether it

fits here as well, which is when the
king or the queen, hundreds of years

ago was uh, thinking of conquering a
different territory, or this, sorry,

not conquering, discovering something
that hasn't been discovered before.

There were two types of
uh, permutations, really.

There was, first I sent someone who's
an explorer, and what do explorers do

and what are their characteristics are.

I'm inquisitive.

I find things.

I try here, I try there.

Failure is not that big of a deal.

I I just pack our bags
and go there, all of that.

Once they have found a place, and it seems
like the right place, okay, there's a

river, there's a, this, there's a, that.

The explorer is being phased out and
someone like a settler or something

like that, whatever the name was,
comes in and they do not explore.

They're there to make the mission happen.

Now, I'm wondering whether it's
something similar where right now,

because it's so early on, we're still
the explorers in the story we don't

know where the career is gonna go.

We dunno how it's gonna change.

We know it will.

So maybe right now we're at that
exploratory stage, which means maybe you

don't want to go deep into any of these,
but what you wanna do is sort of be at

the surface and understand all of them.

And then in 2, 3, 4, 5 years,
whenever that's gonna be more

clear how the industry will change.

Then you have the fundamentals for
all of these different innovations.

And then you can go deeper if you want to.

I'm wondering whether that's
a flawed thinking or, I just

thought about it on the spot.

So I, I don't think it's

Jehad: I actually really
like that analogy.

I think our, each of our individual
attitudes towards AI will have a

huge part of determining our success
in a future where, of AI first.

So one of the things I share with my
team and I share with folks when I

talk about this, I think being an AI
optimist versus an AI skeptic makes

a huge difference to, are you gonna
be successful in an AI first world?

Because if you're an AI skeptic and
you're looking at the ways AI is not

performing today, if you're looking
at the ways AI is not beating the bar

today and so on, you're putting a wall
ahead of yourself at each experiment.

It's basically like an explorer saying,
ah, I don't think we should go east

because it's gonna be cold, and you've
just lost a chance at discovering a

whole set of places that could deeply
enrich the culture you're trying to

build versus being an AI optimist.

One way to think about it is this
is the dumbest AI we'll ever have.

From here on it's cheaper, faster, better.

Is it gonna do all the things we wanna do?

I don't, I don't know, but I'm optimistic
about the use cases I wanna solve with AI.

And if it doesn't work today, I'm
optimistic it's gonna work tomorrow and

I'm gonna keep trying for it to work.

If you have that mentality approaching AI,
then you're constantly trying to adapt.

You're constantly trying to work
through how it works for you.

You're constantly trying to use
it to give you more agency versus

constantly trying to come up with the
reasons of why it's not gonna work.

I think just that shift alone could
give you a boost in being the AI first

designer who's turning AI into a useful
tool for them versus the AI skeptic

who's kind of, uh, needs everybody else
to prove it before they, they jump in.

Christian: Yeah, and by the time everyone
else proves it, you've missed the

Jehad: You're already one step behind.

Christian: Yeah.

I think humans are notoriously bad
at seeing the future and it reminds

me of uh, times when the four first,
second, third iPhone came out or let's

just go back to the first iPhone and
one of the most intelligent people

in the industry Steve Balmer on the
night he gets announced, he laughs at

it 'cause he doesn't have a keyboard.

And you could, you can't tell
that Steve Ballmer wasn't a,

a smart, intelligent person.

Right.

But we in general, we are a bit terrible
at seeing where things are gonna go.

But looking back today, we can see we
have this iPhone or the generally phones

and they do things that if I would have
said that they do it 20 years ago, there's

no way you would have said that I will
have a lidar scanner on my phone or that

I'll be able to call through satellites
or all these or that they'll have camera

performance that sort of mimics low
end professional cameras like you, you

would have thought I was joking, right?

And yet that reality is here.

So I think when I think of AI and I talk
to both optimists and skeptics, I think

of it from that perspective is there's
something 20 years from now that I'm

not even thinking about that's possible.

I don't know what it is and I'm
not in charge of creating it.

But I, I, I'm optimist in the sense
that we have seen this in the past

so many times have happened not
just with the iPhone, but with the

internet, with the bike, with the car.

Like when the first car came around,
people said that horses were better

because you didn't have to fuel them.

There were all of these arguments, right?

Electric cars, oh, their electric cars are
horrible 'cause they only last 50 miles.

Or we have some that
last a thousand today.

So, So this is, all of these
were just terrible at knowing

where things are going.

So I'm trying to be optimistic because
I know that's, historically things

are gonna work themselves out somehow.

Jehad: Yeah.

And, And by the way we are by
nature as designers, have to be

optimistic because most of what we
deal with are problems to solve.

So like being optimistic is forgot the
saying, but it's something along the lines

of pessimists predict what's gonna happen.

Optimists make the future.

if you're skeptic about everything,
you're probably right in the short term.

A lot of things that you see in front
of you, you can be skeptic about.

Optimists who don't see that skepticism
are the ones that create the future.

And our job, to your earlier point when
we started, is to create that future.

Being an optimist about the possibilities
technology creates for us and AI is, is

a piece of that, changes our ability to
turn that into more agency, more tools,

more ability versus a burden overwhelming,
not gonna happen, doesn't work.

And if you're able to make that shift
while remaining a realist, then it's

a boost for where you can be with AI.

Christian: You wrote about how user
experience in this post AI world or

in this AI world is both fundamentally
the same as it was before, but at

the same time widely different.

Talk about that.

How can it be both?

What do you mean by that?

Jehad: Yeah.

I think if you, if you think
about like the fundamental

truths of a user experience.

Looking at the customer journey,
understanding the customer and the behind

the screen, being able to truly design.

Design is the rendering of intent.

Being truly to understand the
intent of a human behind using

your experience and so on.

Those are fundamental things
that are not gonna fully change.

What's gonna fundamentally change
is how you respond to them.

For example, in a world of agents,
a lot of what we designed for

disappears in the background.

So if an agent is doing this for me
in the background, and agents are

orchestrating between each other to get
an experience done, and human in the loop

becomes less and less of an important
issue, then what are the jobs to be done

and how do, how do we get them done?

What do customers care about
becomes super important.

But how you render that intent the render
piece changes fundamentally because

you're not really rendering much anymore.

But you're still designing
the guts of the system.

So the fundamentals of what building good
user experience are probably historical.

Even if you think about the way, ancient
civilizations build their cities.

They're their experience design problems.

You have this following set of problems.

You don't wanna be attacked.

You wanna have water come in
from the nearby river, et cetera.

Like, Here are the constraints,
and you're designing a city.

The fundamentals of that has not changed.

But obviously we don't design
cities this way anymore.

We have much deeper technologies to
allow us to design cities in ways

where these are no longer constraints.

So I think another thing to think about
is some things in design become more

important over time and some things
become less important and that balance

moves around as new technologies come up.

For example if you've designed.

Products that went into
CDs a long time ago.

the stability of your solution and
the testing of your solution was

one of the most important things
in design that you could have done.

Your ability to talk to dozens and
hundreds of customers was super

important because guess what?

The minute it goes into a CD to be
distributed, your next cycle is 12 months.

When we move to SaaS, actually the testing
with customers didn't go away, didn't stop

being important at all, but it became less
of a burden, less of a high bar to pass.

And actually testing early with customers
became such a, such an important

piece because you're trying to figure
out problems and iterate on them.

Experimentation became one of the most
important pieces of design because you

can experiment, you can live experiment
with subsegments of customers and AB

tests and all these things that didn't
exist with CDs uh, with packaged software.

With AI, the journey
becomes super important.

What problems do customers wanna solve?

Service design becomes even
more important than before.

But for example, UI and visual design
may start becoming really targeted.

You're designing a certain
set of UI experiences.

If you think about the UI
ChatGPT, it's very limited.

Today, at least.

While testing and experimentation
becomes hugely important the ability

to iterate on multiple different
versions becomes really important.

The ability to instruct an LLM
to be able to give you the best

answer becomes really important.

Design content, design problem.

So if you think about design of a
spectrum of skills, those skills go

up and down in importance of what
a designer needs to deploy as we

move through history of software.

So fundamentally those skills are the
same, but the skills you're gonna apply

to AI first experiences are probably
gonna be wildly different than the

ones you apply to packaged software.

Christian: What's that saying?

Nothing in nature, nothing
trans nothing disappears.

It just transforms or something like that.

So

Jehad: Exactly.

Exactly.

Christian: So we were talking about
skeptics a bit earlier, and I know

you, you were also writing in the past
about the two types of experiences you

can have with AI, at least right now.

One of them is assistant like, and
the other one is more transformative.

And I think what oftentimes when I
talk to people who are a bit more

skeptic, they're skeptics about
the assistant like experience.

It's oh, okay.

Right now it's struggling to solve
my problem in this chat window.

therefore it'll never work.

But it's very rare you present an
a transformative type of experience

that is fundamentally backed or works
on of the back of AI that people

are a bit more skeptical about.

Because I think there's a lot of
skepticism these days about the

whole chat thing we've seen in the
past and even today, and it probably

continue, that is not always accurate.

It hallucinates sometimes you ask for
B it gives you F . So I think there are

these two types of experiences and I'm
wondering if you have a product right now

you're working on and every company is.

Asking itself, how do we implement AI?

The easy answer is we just put a chat.

We slap a chat on it, and then that,
then we are, now we're an AI company.

I think the real answer and where
probably a lot of the innovation will

happen is behind the scenes in these
transformative experiences where

things are just being taken care of.

You don't need to worry about it
What are your thoughts about it?

'cause again, I know you wrote
about this specific topic.

Jehad: Yeah, it's actually
interesting if you think about chat.

I'm not so down on chat.

I think actually chat and voice are
gonna be the interfaces of the future.

And the reason I think that is
actually ui if you just think

fundamentally about humans, UI is
one of the most unnatural things.

If we did not evolve as
humans dealing with UIs.

But having a conversation is
actually fundamental to us as humans.

We've had conversations before technology.

We've had conversations
for thousands of years.

We've learned how to write thousands
of years ago, our ability to

communicate and improving on that
communication has been fundamental

to our growth as human population.

Chat is one modality of that.

The other one is, you
know, this conversation.

We're having voice back and
forth and we're discussing ideas

and sharing thoughts and so on.

uh, Video is another modality of that.

So like, there are a bunch of modalities
of how you communicate, but communicating

to get something done is actually more
fundamental to us than UI is today.

if you wanna get something
done, you call someone up.

If you wanna discuss
something, you call someone up.

If you wanna get, if you were
working with a bunch of people.

You are using slack or voice to
discuss ideas and make decisions.

You get on a meeting and you have
a discussion about something,

then you make a decision.

Once you made that decision,
you write it down so you're

able to get back to it later.

When you write it down and someone
discovers that, they slack you

and say, Hey I, I would like to
understand more about the decision.

How did it happen?

All of, if you think about all
these conversations or all of these

things, the way that happened,
we spend more time communicating

than clicking around on a UI.

And if you translate that into,
okay, let's imagine again the AI

optimists and imagine AI is gonna get
better, which has been true so far.

It's gonna hallucinate less, it's gonna
do more work in the background, it's gonna

be able to understand more and so on.

Then what is the most natural
way you can communicate with

some level of intelligence?

Voice is not there on AI fully.

It'll get there.

So chat is, is just the most
natural way right now with

the limitations that we have.

But the more it actually works, the more
it'll be even more natural to use chat.

Imagine if I'm able, if I'm working in a
restaurant and I'm able to say you know

my sales are under a certain level or
not, meaning the following forecast that

I, I've set and it's already one o'clock
and my shift to schedule in a certain

way, then tell me then just a different
shift for me and give a notification to

Christian who's the manager on call.

Or better yet, change
the shift on your own.

If once we get to a level of AI that
matters, that what I just said is

actually how operators today work
with each other in the restaurant.

I call you up and you say,
Hey, sales are not meaning,

can you please do this for me?

Et cetera.

And the more natural it is, the more
I think more humans when will use it.

Which is I think why chat GBD
has been usually successful.

I think chatbots get a bad rap because
of the way chatbots work previously where

you have to be a robot to talk to them.

If you say the wrong word at the
wrong time, it just completely,

you know, a nightmare which is
becoming more and more untrue.

So I actually think chat is, are
gonna be a pretty natural interface

and it's already a natural interface
today for so many things that we do.

Whether it's texting or slacking or all
these other things, is just the end result

of that chat is often a human who we
know and knows this and understands this

and can do a better job of answering us.

The more that behind the screen thing AI
becomes better, I think chat will be even

more, a more natural interface chat voice.

Christian: I think that the more I
think about it the more I see that

it's probably not either or I see some
of these working together because I'm

thinking of specific voice experiences
that I wouldn't want to be solely voice.

So let's say I order an Uber and it
might say, okay, your Uber's booked.

Cool.

What's the number plate?

What car is it?

I wanna see a picture of the driver
so then when I get in the car, I

can see if he's the same driver.

So I think these two should work
together rather than and, maybe it's

80%, 20% whatever, towards one towards
the other, and in another type of

experience is the other way around.

But I, I do think that maybe one of the
reasons why these voice only devices

that you have at home haven't necessarily
taken off as much is because they are

really good at a specific type of query.

Hey, want you to play this playlist.

It's perfect the instruction was very
clear and I know I don't need feedback,

I just need you to do the thing.

But if I wanna buy something on Amazon or
anywhere else, I would like to see it with

my own eyes and compare the options versus
you select it based on who knows what

black box algorithm and I don't trust you.

So I think it's not either or.

I think all of these will work together.

Yeah.

Jehad: And I, one way to think
about it is to think about all the

scenarios in which, imagine if you and
I are, are going out to a restaurant

and uh, you're ordering the Uber.

What you're likely communicate
to me is, I got it.

It's gonna be here in five minutes.

And by the way, the last four of
the license plate is 1, 2, 3, 4.

And then maybe I wanna glance
on your screen and see like a

snapshot of all the info quickly.

So maybe I do want that UI.

if I'm shopping I'm not the best
at shopping, but let's say I hired

a professional shopper for me.

I probably don't want them to always make
all the decisions, especially early on.

I might trust them later on once
they know my style, what I'm willing

to wear and not willing to wear.

But initially probably I want
them to buy a bunch of stuff

they can return and show me.

if you think about the real
world, like real world scenarios,

take out Amazon and so on.

I wanna buy them a bunch of stuff.

I wanna try them on, and
then I wanna make decisions.

If you think about that with the, with
AI, it's probably gonna be, Hey, I

made those bunch of recommendations
on your phone or in your laptop.

You can turn on your camera and see
yourself wearing these different clothes

that you can then make decisions.

If you think about that interaction,
it's both it's your describing your

style, you're talking like to a
personal shopper you need UI to be able

to see it as if you were wearing it.

Then you make a few decisions.

I like this one, I don't like this one.

And then the more you do that, the
more likely you're gonna need less

confirmation and you build more trust
again, especially as AI gets better.

The curve of two modalities will
start to shrink the more agents

we have running in the background.

But it'll never go away.

There'll never be like, we're just
docking randomly at different places

without ever looking at anything.

Christian: And I think context and
history play a part here as well because

if you have an agent that you use
to book flights the first few times.

It'll probably recommend you flies,
that you would not choose yourself

until it learns what you really
want and what you really like.

Okay.

I prefer direct.

I don't wanna fly at 6:00 AM 'cause
I live far from the airport and

then I'll have to wake up at two.

I don't like these two, three
airlines because they don't

have the same safety record as
everyone else, whatever it may be.

I prefer this airport whatever in the
beginning, just like if you hire an actual

assistant, a human assistant, right?

In the beginning it might not be,
but as that person or that AI learns

your preferences and has the context
that you need or that it needs,

probably gonna be very accurate.

It's something I'm doing these days
with with Claude, ChatGPT is that

I have in the main prompt is I need
you to challenge me and I need you

to ask questions when you're not
entirely sure what I'm asking you.

So sometimes I'm asking a question and
just ask two, three follow up questions

to which I answer, and therefore the
output, the final output is way better

than if I would ask the question.

Here's the answer, because there's a
gap between your understanding of what I

want and my understanding of what I want.

Jehad: Yeah, I like that a lot.

Christian: So we've made it, we
got to the end of the podcast.

I wish this could be much longer, but I
know you have a hard so yeah is great.

Hey, look, season four is coming
soon, so we'll talk about that.

But I do have two more questions
I'd like to ask you at the end.

I'll ask everyone.

First one is, where do you look
for inspiration in your day to day?

Jehad: So two different
answers to that question.

One is at least I feel I'm very
lucky to work with some of the most

inspiring, some of the best designers,
products managers, engineers and

many other folks in the company.

I find a lot of inspirations
from conversation.

I love brainstorming with folks.

we have jam channels in toasts
where we just jam on ideas.

I really get a ton of
inspiration , from other folks.

The other place I get a lot of inspiration
is I love looking at new startups

coming up in in different fields.

I look at uh, launch YC and other
sources every day as a way of

getting a sense of what are problems
people are solving across the board.

I get a ton of inspiration from that.

Christian: I really wish we
would've gotten the time to

talk about those jam channels.

'cause I'm such a big jamming fan
and I preach to everyone about it.

So See it is actually.

I just realized I said season four.

This is season four, season five,

yeah.

All right, awesome.

And what's something that you believe
AI will not be good at and therefore

designers could or should double down on

? Jehad: I'm an AI optimist, so I think
I believe with the fullness of time, AI

will be good a lot of things it's hard
to decide what it's not gonna be good at

or perfect at, but I think what designers
can double down on is, regardless

of how much technology we've had
historically, there is always space for

super creative, mission oriented people.

we've called them different things
throughout history, but there is

always space for builders at heart
who really wanna translate tools and

problems into solutions and outcomes.

And as long as that, that's your mindset
where you're not really attached to

the tool of today, where you're not
really attached to the one way of doing

things, but you're attached to the I
have problems and tools, and I'm gonna

turn those into solutions and outcomes
you're gonna be massively successful.

Post that.

So double down on how you understand
problems and how you use the

newest tools and, and your tribes.

Christian: Which I guess is
what you said earlier as well,

which is nothing disappears.

Everything transforms the.

Tools.

You still need to learn how to
pick up the newest tools you still

need to learn to solve problems.

So it's the you've closed the
loop very beautifully there.

Jehad: Yeah.

Thank you.

Christian: Jehad.

where can people find you?

Is there anything else
you wanna leave us with?

Jehad: I do my best to write as often
as I can on my name is jehad.com.

So it's, my name is jehad.com

and uh, on Twitter or other places
or X now or other places if I can.

Christian: That's awesome.

We'll put all of these in the show
notes anyway, so our listeners

can easily find again, thank you
so much for being on Design Meets

Business I had such a fun time.

Jehad: Same.

Thank you so much for having me.