JTBD Radio

Chris: Aright, welcome to the latest edition of Jobs to be Done
Radio, I’m Chris Spiek. As
always, I’m joined by Ervin Fowlkes and Bob Moesta. Hey guys.

Bob: Hey Chris, how are you.

Ervin: Hey Chris.

Chris: Today, we have another special guest, Alan Klement is joining
us. He is an
engineer, software developer, author, if I have that right, big
writer, and came up with the concept of the Jobs Story, which has
taken the Jobs to be Done world by storm, and is being used by a lot
of people. Alan, great to have you.

Alan: Great to be here, thank you.

Chris: So, why don’t we dive in a little bit. Give us a little bit of
background, tell us about
yourself, and lead us into what you do and how you came to discover
Jobs, and learn about it, and what you were using before.

Alan: Great, absolutely. First off, let me just say that I am really
thankful to you guys at Jobs-
to-be-Done.org, and Clay Christensen, and everyone else in the
community is really pushing the concept of Jobs-to-be-Done and
popularizing it, because it’s really changed how I see
entrepreneurship and product design, and marketing even.

A real quick thanks, these guys keep going with it. I’d love to talk
to you any way I can.

Bob: Thanks.

Chris: Yes, we’re definitely excited to have your help, so Ervin was
just telling us before we
clicked record here that you’re going to be doing some writing for us
on the Jobs-to-be-Done.org blog, and I wanted to make sure that I
mentioned that, because I know that everybody who listens to this
podcast, most people also read the blog.

I think that just knowing that is going to give people something to
look forward to. We’re actively reaching out to look forward to people
that are good writers and good communicators to add more fresh content
for the blog for people to read, and you’re definitely one of them.
So, that’s an exciting thing to look forward to.

Bob: The thing is to think about how to collaborate on it. You don’t have
to just write it by
yourself, but if there’s things that you want to work on together, we
can do that as well. We can coordinate to do that.

Ervin: The only qualifications out there to be a writer for Jobs-to-
be-Done.org blog is just,
step up and say “Hey, I love the theory. I love what you guys are
doing, and I just really want to participate in the community.” We
really believe in open source innovation, and anyone in a company can
make the choice to move their products forward, and we want to make
sure we’re there to help that along inertia.

Chris: I got to set the bar a little higher, sorry Ervin. I think the
other qualification is that you
definitely need to demonstrate a fairly deep understanding of the
framework.

The one thing that always makes our skin crawl is there are still
groups of people out there saying, “The job of the TV is to entertain,
and the job of the pen is to write,” and if you’re at that level that
you need to do a little studying, and you need to do a little work
before you start writing and spreading out the gospel, so to speak.

Bob: Tools and techniques. Tools and techniques to help you get to that
next level. That’s a
big thing. We’re in the midst of doing it quite a bit, and it’s one of
those things we still have a hard time sharing output that we do, but
it’s the frameworks.

To be honest, we’re almost, it’s hard to see. We don’t sense the water
like a fish. The thing is, we do these frameworks, it’s all of a
sudden, we need help, like what Alan did. Oh yes, the story. Doing
things like the story, but never just formalize it. It’s awesome to
have people like Alan out there who are helping us.

Chris: Great. So,

Alan: Sorry.

Chris: Go ahead.

Alan: I’m sorry, I sort of hijacked the question there. I wanted to say I
appreciate, because it
really has changed everything about how I approach that.

Chris: Awesome.

Alan: All right. Yes, so a quick about me is. I’ve been an engineer/hacker
most of my life,
and ever since probably twelve years old, I’ve been pumping out real
programs for fun. I’ve always been some kind of entrepreneur in some
way.

I remember when I was really young, I was always trying to start
little businesses, just make a little money on the side, and even
today, I’m working with other engineers and other people, other
business people here in New York City to develop products.

I really use Jobs-to-be-Done, that philosophy, in every aspect, from
market research, product discovery, customer development, and even
product design, which is kind of what thinking has brough me here to
this conversation with you guys. It was a lot of information out
there.

I remember David, last week on the show talked about how, “Yes, Clay
Christensen said some really great stuff, but he kind of glossed over
some of these other things. I agree.

I think there’s one part in one of the Phoenix videos, Phoenix
University videos, and Christensen says, “Oh, once you understand the
job, then improving the product is relatively easy.” I’m like oh, I
don’t know if it’s relatively easy. I think there’s a lot more there.

Chris: Yes. The interesting part is the dimension on which you have
to improve becomes
clear, right? I think, and for me to paraphrase or try to reword Clay
is absurd, but I think when you’ve been in the muck around, we have
something here that, a lot of times we talk to people.

We built a product, people are buying it, we’re not sure why they’re
buying it, and we’re not sure what the next step to take is. You end
up with this perspective of, we can make it smaller, we can make it
bigger, we can make it lighter, we can make it heavier.

That’s the milkshake story. Do I make it thicker, thinner, sweeter,
more sour? What do I do with it? When you understand the job, it’s
like, alright. Make it thicker, make the straw thicker. I have a
direction at least. So, all the technology that goes into it still
needs to happen, but at least you have direction, right?

Alan: Absolutely. I think that’s definitely obviously what he was alluding
to. However, I do
think that we’re still talking about it on a higher level, but I think
that you can, this happened to me, when I talk about Jobs-to-be-Done,
on blogging or Twitter, what have you.

I’ve had people contact me directly, and say, well how do I use this
with my team? How do I translate this Jobs-to-be-Done philosophy to
two designers, three engineers, and a product manager. How do I get
those all to understand the same way, and how do we all talk about our
product with the context of Jobs to be Done.

Chris: Yes.

Bob: What do you say?

Alan: Good question. What I say is, honestly what I say is, I’m actually
experimenting with
myself quite a bit. As I look at it some more. I’ll let you know.
Here’s what I can tell you right now, and this actually would help if
I talk about a recent situation where I used the jobs to be done in a
kind of, snuck it in on this last team I was working for.

I wrote an article about this on Inside Intercom. Those are great
guys, too, by the way. I wrote an article about designing features
with Jobs stories, and actually took a real story, a real situation
with a team I was working with about a month ago.

What happened was we were designing this feature, or actually it was
this product, and Joe, he gets up and he starts doing some wire
frames, and he does a few wire frames on the board, and he point to
one of them.

He’s like, “Okay, this is the profile view for our brokers,” and I
thought, “Okay,” and everyone around the table just nodded their head.
I was looking around the room, and eyes weren’t lighting up. They were
just nodding their heads, going along, and that’s when I said, “Okay,
what’s the job of this profile view? What are some of the situations
that are in the feature, that this product is resolving?” I

talked a bit more with them about it, “What are some of the anxieties
people are having that this is resolving?” Is there any kind of
planning that we can draw of what people are doing before or during
this that’s going to help us design this? Just when I start using the
language, I never actually said “Jobs-be-Done” to them.

I was just using some of the language of timelines, situations,
anxieties, jobs, and I saw them actually using the same language
without even me telling them, “Hey, guys, start calling them jobs,”
they just start using it naturally. That’s one thing that I always
suggest to people, to product teams. Start with the language.

People can really grab on to language, because it’s like, “What’s the
job here of the product?” They’re like, “Oh yes, what is the job of
the product?” in situations. I think that’s a very helpful first step.

Chris: Did that have an impact on the products? I’m imagining you’re
sitting in the room,
you’re looking at the profile view and you’re like, “It’s not gelling
with me.” You introduce this language. Was there an impact to the way
you guys started developing from that point on?

Alan: Yes, there was. I would say that once they started really grabbing
on to the idea of
designing for situations, and thinking of the situations, and also
once we started kind of identifying anxieties as problems, but also as
how were solving those anxieties with our product.

Once they got that, then I was free to write these kinds of, what I
call job stories, for the team, for historical purposes. We weren’t
using them day to day. It was more of a historical document, so to
make sure everyone’s on the same page, and in case that someone
forgets, or they’re like, “Oh yes, why was that there?” “Oh yes,
because after interviewing customers, we found these situations, we
found these anxieties,” and that’s why we’ve included these here to
relieve those anxieties, and help them navigate the situation.

Bob: One of the questions I get all the time is, “How is it different
fromt personas, or use
cases?” and, how does it differ for you guys in this case?

Alan: That’s great. I actually highlight- first I heard of jobs to be done
was, it was Ryan
Singer, who’s a great guy. I was following his work and his talking,
and he was on this show, is that correct?

Chris: Yes, Ryan’s a great guy.

Ervin: Yes.

Alan: Yes, he was. At least he was on the show. He mentioned personas, and
I was like,
“Personas. That’s driving me crazy.” That’s how I uncovered more of
the Jobs to be Done. You’re right, personas are, I think Christensen
said it perfectly, the collection of attributes, and these attributes
do not explain causality.

I don’t actually Des Inside Intercom, had great explanations. If I
don’t get up every morning because of my age, sex, and what I do on
the weekends. That doesn’t pull me down the street and make me buy a
coffee, doesn’t make me buy a slice of pizza, doesn’t drag me into a
Gap store and buy a sweater. I thought why?

I’m not being dragged around my life through these characteristics of
myself, I’m just navigating through situations constantly. Endless
situations which is the condition of living. We navigate from
situation to situation. Some are small, and some are big. That’s what
the big difference is of personas versus thinking in terms of jobs is
that jobs all about the situations that you face every day.

Personas are just my what I do on the weekends, the name of my dog,
and I like to shop on my mobile phone. That doesn’t explain why I went
to the corner and bought a slice of pizza. It doesn’t explain the
situation that drove me there.

Chris: I was talking to Clay right before the holiday, and he brought
up a fabulous point that
relates to this. He goes, “I’ve been married for about 50 years.” He
goes, “What jobs to be done has done for me as a husband is, if I
focus on the job that my wife wants done, like the honey to-do list
and those kinds of things, and I try to listen to what she’s trying to
get done, the thing is that I don’t have to understand her. I just
have to respond.”

He says it’s made his marriage so much easier, because, “knowing that
I just need to understand the job she’s trying to get done.” He goes,
“It’s made it so much easier. That’s the essence of jobs to be done is
about.”

Ervin: He stops struggling to understand the…

Chris: Like, how is she thinking? How do I anticipate what she’s
doing, and literally like, how
do I come home, find out in the moment what’s going on, what’s the job
she really needs to get done, and respond to that. Instead of trying
to anticipate everything, it’s the fact of being in the moment. Very
powerful analogy for me.

To get back to your profile view, the thing that’s been running in my
head since you said that is that if you know how to introduce it to a
team, it can be a pretty nuanced change. It sounded like you took one
meeting and said, “All right, we’re thinking about this one napkin
sketch of a profile view. We’re thinking about it this way. Let me
just ask you, the group a couple questions to re-orient them. It
doesn’t have to be, because we’ve seen this introduced a couple
different ways. You’ve got nuanced view that you’ve talked about, and
then we’ve got the other view of… ”

All right, we’re throwing away the research we’ve done. We’re talking
to all new consumers, we’re going to totally revamp our consumer
insights approach. I think it’s important to point out, it doesn’t
have to be like that. Within one meeting, we start to say, okay. W

e’re going to go pour some development resources into designing this
page. Let’s think for a second, kind of what anxieties might be
affecting the user? What’s the progress they’re trying to make when
they’re using this page? Even just through those simple questions, you
can make a change.

I know you probably can’t share a ton about it, but what did you, did
you end up adding features, taking features away, what was the net out
of those conversations? If you can share anything.

Alan: Totally right. Of course I can talk about it. Here was the situation
that we were in,
which was we were trying to figure out what, why should we even have
this profile view for our customers and how is that being helpful to
them. And so we were trying to figure out what actually specifically
should be in this profile view? Should we have a picture?

What buttons should we have? What content should we have? Should we
have their email address, their phone number, is there something else
were missing. Long story short, what we realized is the job of the
professional view is to mimic a situation that was already existing
outside this product, to expand a bit more.

The product was to help mortgage brokers and clients fill out some
paperwork and get things moving. Typically right now, how people solve
it is someone want to file some money they go in to a bank and they
meet with a mortgage broker and fill out all this sensitive paperwork,
and there’s actually a lot going on there.

The person borrowing the money is giving out a lot of personal
information. They’re not going to walk into some sleazy bank, or talk
some guy with his hair greased back and he’s grinning really big,
because he’s giving away personal info. They’re going to want to go
somewhere.

Bank of America, I’ve heard of them before. They walk in, look around,
“Oh there’s lots of people here. There’s social proof here, this is
good. I can talk to this mortgage broker, he’s like me, he’s my age. I
don’t mind giving him my personal info. They like okay, that’s we
identified the anxieties and the micro situations that were existing
today, outside of our product.

Then, we were, “How can we mimic that with our product, and that’s
when we realized, what we need to do, we should have a picture of the
person there, that kind of reinforces the connection with the mortgage
broker you’ve worked with before. We could also probably start doing
some things like adding some social proof in there, like this mortgage
broker has [lended] out 500 loans to people and he’s been at this comp
for six years.

Instead of having an email address, we could have, “Email me now.”
That’s easing all these anxieties of what was happening in the real
world outside our product.

Chris: That’s a great example. That’s a great. Instead of being a
profile for the person who’s
writing the profile, it’s for the person who’s reading the profile.

Alan: Exactly

Chris: Ervin and I had a very, sorry. Go ahead, Alan.

Alan: Which is right, which is how we discovered what the job of the
profile view was. It’s not
so much for the broker, it’s for the customer viewing this. Now, we
need to tailor that to the situation.

Ervin: Excellent, it seems you isolated one of our core beliefs that
every job has three
components. There’s the functional, the social, and the emotional
side. It seems that you kind of walked in from the functional side of,
“Okay, there’s a profile page, it gives information.

Then you understood roundabout, “Wait, there’s an emotional tie to
this.” There’s that piece of, “Help me get through this, because I
don’t know I can trust this guy. right now the way I do it is I walk
in, sit across from this person, he has a nice suit on, all this type
of stuff. Who says I should trust this person?”

Then you emulate that, then I’m sure, enrich it by creating this
profile that’s like, “Here’s all the affects that u can read n consume
on our own that tells you why this is the person you should choose.

Chris: I think that’s right, that’s very good. Alan, one of the things
that came up was, when
Ervin first came on board, he was one of the ones to help redesign the
website for the rewire group, and he had a contacts button.

Ervin: You going to tell that story?

Chris: I’m going to tell that story. You’re going to have to emulate
it.

Alan: I like it already. I’m already interested.

Chris: Which is, he’s like, okay, here’s the contact us button, and it
floats and does these
things, then he has a form to fill out. What’s your name? It says
“required”, and I’m like, “Okay”. Let’s stop and think about the
person clicking the button. He’s like, what do you mean? This is how
everybody does it. We went through the whole thing. This was a two
hour conversation.

Ervin: We went on for two hours about the one contact us button at the
‘Contact Us’ buttons to
the point that I don’t even think about it when I create it. But Bob
said, let’s take a minute and think about the context about the kinds
of person when they come to fill out this form.

Not so much who they are, because everyone says, “You’re a web
visitor. You want to contact us. That’s what I want you to do.” We
flipped it and said, “What’s the anxiety behind contacting us? They’ve
heard these voices on the podcast, they’ve seen us somewhere, now
they’ve reach out to contact us about something, and all we’re giving
them is a big orange button and five fields that say “required”.

You can’t speak to us unless you give us every piece of information
that we want from you right now. I’ve been debating on whether to post
audio of that, because it’s two hours of Bob letting me have it about,
“No, just because the industry has always done that.”

The net out was, basically the most painful words, and dangerous words
you can hear in development is, “That’s the way we’ve always done it.”
That day, I learned that is dangerous. I was just willing to march to
this beat of, “This is how we’ve always done it.” Now you have to look
at it a different way. It was great.

Bob: It now says, “Drop us a line.”

Chris: Can I add some humor. How did we end with “Drop us a line?”

Bob: It reduces the amount of anxiety around, “Hey, just drop us a line.”
We don’t get many
web inquiries for the business side, right? It’s mostly people who
would be, they want to comment on the podcast. It’s more an informal
way to reach out to us, because otherwise you can find all our
information, and our emails and all that other stuff.

To me, it’s reducing the anxiety by saying, hey drop us a line. It’s
making it less formal by going to that space. To me, it’s where we’re
trying to invite people as opposed to, “Tell us.”

Because at some point, it’s like, “What do I want to ask them? What do
I want to say.” How do we make this less and less anxiety? It’s one of
those things where we assume we know what a contact us page is about,
but the reality is, let’s just slow down and figure out, “Are there
multiple ways that people want to contact us?”

Chris: I don’t want to turn this into another two how conversation,
but I do think there might be
a project here, just around contact forms. From different product
businesses and services, and this is kind of like what you were
already working on, Alan.

It’s like, what are the anxieties that face people, and what
situations are they in. Is it like the last resort? “I can’t find what
I’m looking for, so I have to contact these people. Is it the first
thing they should be doing? I think there could be an entire interview
process, or workaround, just because. We might only be halfway there
with “Drop us a line.”

Bob: I think that’s right, but I think there’s multiple ways you can
actually say “Drop us a line
is the informal one.” Contact Us” might have to be there because it’s
the formal way. If somebody has to put in a formal complaint, “Contact
Us” or “Report a complaint”. What are the things that are there?

Chris: I think we’re just scratching the surface.

Bob: I agree, so it’s almost like how many times. I think of non-
consumption here. Where
people wanted contact, but can’t. It’s like okay, get to the contact
page, and, “What am I going to say?”

Chris: Not can’t because of technical problems, but they want to
contact but they don’t. I don’t
know what to say. So how do we help them along the way with that? So I
think that everything on the web is ready to go to the next level,
because I believe a lot of it’s become so automated.

To your point, Alan, it’s about the Profile page. “Well, this is how
you do a profile page. This is how you do a contact us page.” This is
how you do it, and it’s like, okay. If you think about it at the next
level, you literally can disrupt.

This is what Clay talks about in terms of being able to disrupt. Once
you know these insights, you can change little, small things that have
a huge impact on how people actually interact. That’s what jobs is
about.

Ervin: Even though the conversation at the moment wasn’t the most
comfortable conversation,
but growth never is, right? It’s always about, you got to break your
habit. I’m always a big fan of the habit. I had a habit of, “This is
how I create a contact us page.”

I didn’t even think about it. Load the plugin, get these fields in,
send it. You good to go. It’s like, “Wait a minute. I had to think
about this part? This is the smallest thing.” There is nothing
important about this at all, until I’m like, “Wait a minute. This is
the most important thing.”

Bob: The first 15minutes of the conversation was something along the lines
of, “I’m the
web guy, I know what’s going on. I’ve done this a lot more than you
have. You’re not. Just, go away.” I was like, “Okay, I need to get the
point across.” It was, did we record it?

Ervin: We did.

Bob: Oh gosh, we have to figure out how to..

Ervin: I’m debating on where to post it. I don’t look great in that.

Bob: But it’s a learning moment. It’s a learning moment. I don’t know,
it’s your choice. I’ll
leave it up to you.

Ervin: Okay. How may I add to the end of this. We’ll see.

Bob: Back to Alan. Sorry, Alan. We digress.

Alan: No, it was very interesting. On the top of my head, based on some of
the things you
guys said, I would say, okay. Instead of having a contact us page,
rephrase. Ask us a question.

You could have some preset questions or past build-up questions, or
maybe on the page itself, you could say, Here’s the last five
questions, and the answer we gave. So it’s like, “Oh, other people
have asked similar questions.”

Chris: Right, exactly.

Alan: And you gave really great answers, so when I contact them, they’re
going to answer me
with a really great question.

Chris: Exactly. You’ve reduced that anxiety, you create pull by
saying, “Hey, they’re going to
get me a good answer. There’s lots of ways to do it, but just having
that push-pull,

Bob: Oh, we lost Alan.

Chris: That’s okay, we can. We were rolling too.

Bob: Bam.

Chris: Alan’s like, “Forget these guys.” All right, I’m back on 4G.
You got some editing to do,
it’s crazy.

Bob: I can’t believe you recorded that. That’s pretty good.

Ervin: Oh yes.

Bob: Can I have that recording?

Ervin: Yes.

Bob: I just want it for my records.

Ervin: I don’t know if I’m going to post it because you swear a lot in
it. I don’t know how I’m
going to portray this to the public, because you’re like, “No, it’s
fucking wrong!” What are you doing? If you want to edit it and edit
out that stuff.

Chris: You can beep it. Just go in and beep it.

(Ringing)

Alan: Hey guys, how are we doing?

Chris: Good. That’s how you know when we’re done. I’m going to go
back.

Alan: You got so excited, you were waving around your arms. [inaudible
00:27:15]

Bob: If we had a camera in here, we’re all flailing and talking.

Chris: Stuff flying around everywhere. Alright, let’s resume. Ervin’s
comment was that I swear
a lot, so he’s going to have to bleep it if he’s going to post it, so
we’ll see if I can get him to do it.

Ervin: Don’t hold your breath.

Chris: So what’s the other thing between use cases? How is this
different than use cases? I
don’t think we talked about that yet.

Alan: Could you say that one more time? I’m on my phone right now, and I
can’t hear so great.

Chris: So, how is this different from use cases?

Alan: Oh, yes. Use cases. I would say user stories and use cases. I think a
real challenge
there that those bring to a team is that those are coupling
implementation with all of those things we’re just talking on.

The coupling, the implementation, motivation, and they’re also usually
relying on a persona to just have this maelstrom of data, and I think
it really actually will cause more problems for the team, because if
we have a user story like, “As a power user, I want to be able to
select which files don’t get backed up, so I don’t have clutter on my
backup drive.

I’m like, “Okay. Suppose that part of the product, and you build that
future out, that capability, and you suppose no one uses it, or people
do use it, and you don’t understand why. The problem is that if it
does fail, or if it is successful, how can you really be sure what it
was that was being successful? Were they using the feature for
something else? Did we have the right motivations for it? If it
failed, was it because we had motivations wrong, or just because we
had implementation wrong?

Bob: Got it. I find that it’s very functional. It doesn’t address the
tradeoffs that are required,
and it breaks things down into, “We need to have this, and this, and
this.” and it just leads to feature creep. We got to have everything.
It doesn’t help you understand how to make the tradeoffs to what
should be in and what should be out.

Chris: So how, I’m fascinated by the teamwork aspect to what you’ve
been writing about. We
got the story of the introduction. How you got them started. Have you
tried any techniques to, or have you had to do anything to keep, have
the language persist, meeting after meeting, week after week, so that
it sticks around, and that people know to refer back to jobs language,
or has that come naturally to the teams?

Alan: In this last case with the last team, they just started, after that
first meeting, they started
using that. When I started recording a lot of this information in this
format, people were finding it very useful. Then when we were creating
a specific feature, how were doing if we use [inaudible 00:30:46],
scrum, or you have your little cards, or whatever.

I would just link all these kinds of job stories with the specific
feature that was being built at that time. There was always
correlations, so the engineers or designers, if they’re looking at the
profile view or they’re going through this list of features if they’re
using some kind of card on the board, for example. There’s always this
link back to the job story, or the multiple job stories.

They would use that, and reference that, and that was really helpful.
Then, they moved towards. They never used user stories, and that was
helpful too to mention. If your using user stories at the same time.
The job stories or the jobs will be augmenting that.

However, in this case, we weren’t using user stories, but I would
suggest that what would happen is that you would start realizing, “Oh
okay, we’ll just focus on the implementation part, and then we’ll just
always refer back to this job story about if this implementation is
disconnected or not.

“Then, if the implementation doesn’t work, then we can throw that out
and try a different one, but still keep the same job stories.” It’s
helpful too because jobs is more information. It’s like laser pointed,
focused information on what’s going on, and it’s always helpful.

Bob: Yes.

Chris: It sounds like you had a group of engineers that would go to
someplace to understand
the technical requirements of the feature that they were working on,
and they were already used to going and finding a user story to give
them intent and perspective and things like that, and you were
augmenting that.

It’s almost like they were already used to going and finding out the
back story, like they had trained is the wrong word, but they had the
habit of, I need to understand the technical side, and I need to
understand the intent. Now there was a different kind of flavor of
that, in the form of a job story. Is that right?

Alan: Right. They were probably relying on if you had this kind of, it’s
such a big topic we’re
now getting into. It now really depends on if you’re working with a
small, cross-functional team where the engineers can turn their head
on the authors next door and knock on the product manager’s job, and
be like, “Oh hey, remember those customers you were interviewing? What
was it, that they were saying again?

Chris: Yes.

Alan: Or if your organization is like, there’s a product management
department the next
building over, and they just chuck over these user stories to the
engineering and design team to implement. It depends on how that is.
In this particular case, the engineers were, they were asking for user
stories, but I would give it in a situational job story context, and
that was the information they were relying on, and that was helpful to
them.

Also, I made it easier for everyone to talk about the feature and
implementation and if it was making sense or not. Does that answer
your question?

Chris: It does, it does. For me, I always talk about personas as the
reverse, it’s like the wrong
math. It’s like people will take all the attributes and then cluster
them with using math to kind of say, “Here’s this persona. They’re
this old, they do this, they have this kind of income, and they
aggregate.

I call them like, a person is like a soulless person. I don’t know how
they make decisions, I don’t know how they make choices. To me, the
job is the thing about bringing in that decision set of, “What are
they willing to trade off?”

Ultimately, to me, this is all about trying to get at trying to make
better trade off decisions to get to the minimum viable product that
can do what it’s supposed to do and be simple. To me, it’s really
about those things, and personas complicate it. I don’t know how they
make decisions.

It’s like, I was talking to Clay, personas are like a picture and a
job is like a movie. It’s really about the dynamics of how people are
choosing through those situations. It’s not about who I am, it’s about
the movie of how I do something, or what I want to do.

Ervin: Alan, you talked about…

Alan: I find it very interesting that you mention movie, because I’ve been
thinking about, this
is actually something that I’m playing with right now. I’m coming up
with this, you see where jobs overlap with each other and you see
where jobs in designing futures and talking to customers were kind of
bunched together like, “Oh, these five jobs all can relate to each
other, and these five jobs over here clump together. I’ve started
thinking of the idea of actors.

Chris: Yes.

Alan: Which is not a persona, like as I said, a persona is like a soulless
person whereas an
actor, it’s not really your focus on the actor is or anything or what
the actor does, and as they navigate through these situations. That’s
how I’ve been thinking about it together. Even actors can have
different roles but I’m still experimenting with it but there’s some
promise there I think.

Bob: The other thing is you start to see multiple jobs, you start to see
does one job drive
consumption of the other job and are there dynamics between the jobs.
If it’s about making it easy, “make it easy for me” and now it’s like,
I want do more, but I don’t want do more until I make it easy.

You start to look at jobs and understand the dynamic between the job
and start to see what’s the roll out of the product line
architecture. What should I be working on, what’s the next set of
features, because I can see where I have to go in.

If I do this thing, I can see where the next set of jobs is going to
be. The next job requests they’re going to be working on to me is u
have a set of jobs, now it’s the dynamics between the jobs. It’s very
powerful.

Chris: The other thing is, we tend to use our actual interview
participants as our actors, I think.
We have real life people, and we start to look at features and stuff
like that. It’s like, “Okay, we’re talking about Christine, who we
just interviewed a couple of months ago. We know her story front to
back. How would she interact with this?” You say it’s like, adding the
soul back into the persona.

We know enough about her story were we can kind of not predict her
behavior, but interpolate her behavior based on what we know, and you
can really look at your product or feature with that perspective, and
it’s real helpful.

Erving: So Chris, can you give an example then, of the other way. We’ve
done this before and I
like the way we do it. It’s the idea of, you have an idea for
something that could be, but you have to speak to it through that
person. How’s it done now? I’ll say wrong. It’s the idea of.

Chris: I think the leap is longer. The experience I have with personas
is like, we’ve got the
guitar playing, 24 year old new young professional that lives in a
studio. He’s an urban new young professional that likes Starbucks and
parties at night with his friends. Because of that, this two door
sports car is going to be perfect for him.

It’s too big, I have demographic, psychographic data points around it,
but I can’t actually look at the story of that new young
professional’s past consumption and say, this is how he makes decision
based on this product purchase n whether what the value code and
what’s important whatnot.

I can only look at him as a snapshot in time and say the young guy is
different from the old guy for these reasons but it doesn’t give me
the granularity or depth to make tradeoffs or decisions.

Bob: To me, it’s again the math gone awry. They correlate, but they don’t
cause. I can sit here
and talk about correlation of younger people tend to buy smaller cars
and all these different things.

When I use math, and the sophisticated math, it comes back and says
that’s what it should be in the reality is that we don’t understand he
causal links and that to me is the main diff between jobs n more the
other types of research which is they can correlate be we want to find
causality, and causality is surprisingly simple.

It’s not 50 variables. It’s usually five or six, and it’s really in a
time span of a very set time frame that lets you can figure out the
fact is, they aren’t all the same. One situation doesn’t have the same
five variables as another situation. It’s those things we need to be
able to figure out, and we need to find the difference.

Ervin: Let me throw out to Alan then. We’re talking about causality so
Alan, and u two jump
in as well. When you get this software, it seems causality is less
important. Is that right. I heard that. Come on. I want a press button
to print.

Bob: Wrong

Ervin: Surprise, surprise. So you all tell me, how does causality play
out in the software world
to you?

Alan: If I understand the question that you’re asking, about how causality
is played out in the
software world, is that correct?

Ervin: If you’re developing a piece of software, why care about
causality? Why is it important?

Alan: Well yes. Jeez that’s, discovering causality that’s all I really
focus on thinking about ,
especially when you’re early on in the discovery process, I’m always
trying to, I’m looking at how people solve situations now and u kind
of work backwards, and discover the causality that brought them to the
situation, and you understand.

Okay, that’s why they got into that situation, then u start to
understand how to design for that. It’s actually very similar to what
Christenson was talking about with the marriage thing . About “Oh
okay, I’m really going to listen and try to understand the causality”.

Chris: It’s easy to abandon into software. That’s the interesting
thing. The profile page is there
so the user can get the telephone number and n email address of the
broker. As long as we program it and get the features up there, it’s
going to serve the purpose. The contact form is there so somebody can
send us a question and we can reply.

I think, I’m getting back to Ervin’s question. It’s easy for us to
just make assumptions. To say alright, and just check that box and
move on to the next thing. I don’t want to speak for the whole
software community, maybe I’m speaking for myself in some instances.

Bob: I think there’s some correlation between the software community and
the food business
in the way that prototypes are just way too easy and too small. I can
literally make one little tweak, and it doesn’t cost me much and I can
do things, so I don’t need to have the rigor to understand experience
because it’s just so easy, I’ll just prototype another one.

I can add another color, I can add another feature, I can add another
ingredient to this, I can add a little more ingredient to that and
what happens is that lack of rigor is where there’s so much waste, and
people don’t understand the magnitude of waste in programming, and
because of that lack of that understanding.

Chris: I think the contrast is important there. When you take that
contrast with the automotive
industry and I think we take a lot of the user experience of a car for
granted, but when you think of the development cycle, it’s like 72
months of making sure everything is perfect, because we can’t just
crank out cars day after day. We can’t do continuous deployment.

We need to think and plan, and actually dive into these things before
we start prototyping. That’s what makes, it’s what makes software
dangerous. Let’s just crank out the version and see if it works and
test it. No, let’s actually put some thought into the intent, and into
the job we’re trying to help the user get done.

Bob: Cool.

Alan: Right, right. Yes, so I get it now. I would say that with causality
and understanding
that with your product, it’s going along with what you were just
saying. It’s not just helping you design or create some feature of
this product. It’s also helping you and keeping you focused, and helps
you edit this feature.

For example, I saw this one tweet from this product manager. He says,
“If you ever are curious about a disagreement that a product team has
had, open up the settings dialogue box of your product. That’s where
all the disagreements are on how this product should work.

Bob: That’s great. Wow.

Alan: I totally agree. You’re right. You are, there’s a lot of temptations
because software is
soft, it’s very malleable, you can work with it. It’s easy to update,
it’s easy to move add things, take things out, and move them around.
Wait a minute, is adding this extra button really going back to our
original cause, or it is outside of that original causality that we
had to find for the feature?

Chris: Yes, so one of the things that we’re toying around with right
now in our consulting
practice is the deliverable has become the life size, four foot by
four foot canvases that have all the details of each job on them, so
it’s like, one per job, and they’re big enough where you can hang in
the war room.

One of the things we’re trying to combat is where you come to that
argument of, is it “X” or is it “Y”, all right, let’s just make it
user configurable and put it in the settings. What we’re really after
is like, how do you look at these life sized posters and say, this is
the job that we’re trying to get done.

Will this feature that we’re ultimately going to end up degrading to a
setting, and passing it off to the user, which is the wrong thing to
do, is this feature answering this job? We have more about/less about
on the board. More about this, less about that. Where does this
feature lie? Where does this setting lie?

If we look at what the job is more about, is this feature actually
addressing that, and helping the user get this done, or is it not? I
think it gets back to what you said. Is the product manager and
engineer kind of sitting next to each other, or are they in different
buildings?

I think that’s one of the problems to solve, but what I think what’s
important is that do you have something in front of you that actually
promotes that kind of conversation, and says, “We have good data about
how these people are making decisions.” We can actually have a really
constructive conversation around it and say, “I’m not putting it in
the settings.”

We can actually say, “No, this feature is not good for this product,
and its out,” or vice versa.

Bob: I think it’s about clarity, priority, and trade off. Those have to be
the focus of it. What
are we talking about? What’s the priority of it? If I’m going to make
the trade off, then what’s the magnitude of trade off I’m going to
make between these two. I don’t think those are the discussions people
are having.

When they’re in a product team, it’s more about, is it there or not?
It’s about the features. It’s not about the priority. It’s not about
clarity, and it’s not about that trade off. To me, that’s the
information, the fuel that jobs brings to the tableto allow you to
have those new discussions.

Ervin: Excellent. One last thing, where cutting close on time. Alan,
we talked about having the
team engineers that kind of worked together. I remember from reading
from your blog. Have you had experience when it’s a new team? Where
you’re like, these guys have just come together for the first time to
build something, and you have to introduce jobs that way?

Alan: I think one more time, it’s hard to hear. Maybe further away from
the microphone.

Chris: Yes, I’m closer, so I’ll reiterate it. Do you have a story
about a new group of engineers
and designers that has come together, that you’ve had to introduce the
job language to? So maybe a group that hasn’t worked together before
that’s you’ve had to ground in jobs?

Alan: Let’s see. I would say not yet, other than where I’ve already done
the past, which is
when people get together, I don’t ever, because no one really knows
it. Everyone here is, everyone knows agiles from combine, what have
you.

If you throw at them, “Okay, we’re going to be talking in terms of
jobs now, and here’s all the job stories, then it’s like ‘oh’. People
will get, I would imagine, they would get pretty overwhelmed. Short
answer, no, and I would be even a little hesitant of just diving
headlong into it.

That’s why right now I’m just supplementing it, and seeing if they
roll with it. If they do, then that’s when we migrate away from the
typical model.

Chris: Yes. I would say that’s what I was doing when I did my
startups. I never told people we
we’re doing jobs, they just did it. We’re going to go do these
customer interviews, and they’re like, “Why are we talking about when
people had a first thought of something?” Because we need to
understand. I never told anybody, the staff. You just did it.

To me, I think that’s what the lesson is. Maybe, as a community, we
need to be able to talk about jobs, but at the same time, it just
needs to be integrated seamlessly into the work. I think that’s the-
we don’t need to introduce new lingo.

Bob: I think we’ve experience so many times that if we talk about it
through the lens of the
forces diagram, the anxiety that a new method creates in the user is
almost insurmountable.

It’s like, all right, we’re going to spend the next two hours in this
meeting talking about Jobs-to-be-Done. What’s the pedigree? How old is
it? Has it ever been used by anybody? Is this something that he came
up with last night? Why do I need to pay attention?

Actually, if you’ve heard about the way we conduct the switch
workshops, we’ve actually incorporated it. We don’t talk about the
fact that we have this twenty year old thing. We literally come out
and say, “Somebody come up here, and tell us about a product that you
bought. You spend the first half day just exploring it.

Then, on the back end, you say, ‘okay’. If you think this is important
enough for you to spend time on, let us fill you in on the back story.
If you do it the other way, it creates so much anxiety that it never
works. You’ve really captured that, it sounds like, in the way that
you’re working, which is brilliant, in my opinion.

Chris: Awesome. Thank you so much for being on.

Bob: Thanks for coming on. Where can people find- I know you’ve got your
Jobs-to-be-Done
checking in on Medium. You’re on Twitter on the hashtag. Where should
people follow you can keep up with what you’re doing?

Alan: Yes, I think Twitter and checking me out on Medium is probably the
best way. That’s
it. And I do have this old Blogger account, but I really actually like
what Medium is doing. I’ve moved my ring to that.

If you see some of the older stuff, if you Google me, you’ll probably
come across my blogger account. However, I’m focusing more on Medium
right now, and Twitter, that’s it.

Chris: What’s your Twitter handle?

Alan: It’s just my name. AlanKlement, one word.

Chris: Klement. Awesome. Thanks for coming on. We hope to talk to you
soon!

Ervin: Thanks, Alan.

Alan: Yes, it was a lot of fun.

Chris: Awesome. That’s the clapper. Fantastic. Great job. Des is our
next guest. We’re
talking to him this afternoon. We’re going to record that. It will
probably go out a week or two after this episode that we just
recorded, but we’re a huge fan of his as well.

Alan: Yes. It’s great. Actually, wow. I’m really excited. I had a lot of
fun talking to you
guys. Are you guys ever in Chicago? I wish you were in… I’m in New
York. Come to New York.

Bob: Are you part of the meet-up group with David and those guys?

Alan: Yes, I am. Actually, real quick. We did last week, the last meeting
we did an interview,
and they interviewed me about buying a sofa, and there were about a
dozen people there, and they were like, glued to their chairs. They
were hanging on to every word. It was an hour long interview, and they
were like, ‘That was amazing.’

Chris: What is that audio?

Alan: Oh no, we didn’t and everyone was like, “No! We didn’t record it.”
It was like this hour,
more than hour interview we did. It was great. We’re in New York, and
do attend the meet-up. I think it’s next week.

Bob: What we’re finding is people who actually have been interviewed,
actually get this even
more. How much of the actual buying process did you, was explicit, and
when you got interviewed, were you like, “Holy crap, I did that, oh,
my gosh, I did that,” and you start to realize you don’t even know
sometimes the job until afterwards.

Alan: Yes, actually, I think ,yes. I would say that the most interesting
part of that interview
was for me was starting at this [inaudible 00:52:56] was we actually
had bought… This was for buying a sofa.

I had actually bought two other sofas before. One we paid for and but
then, immediately cancelled it. One we bought it and cancelled it four
or five days later. I thought that was like consumption or value
consumption, or unhappy with, but David was arguing, no actually, I
think that was part of the decision making process before.

Bob: In cars. In cars we find it’s that way too. People go into a dealer,
and they’re like, “Oh,
it’s going to be easy.” They go in, and it’s really hard. Unless they
have the hard experience, they can’t value what they really need.

Alan: Yes.

Bob: If that’s the case, how do you make it harder, so they can actually
make decisions
faster? It’s still counterintuitive in some by processes, but it’s
still very powerful.

Alan: Actually, you know what. That’s very interesting that you said that.
The first sofa.
Really quick, the first sofa. You can bring into your house for two
weeks, and then we’ll take it away. And so we’re like, “Oh, okay.
We’ll just buy that.” Of course, we cancel it three days later.

The same things for the second one. It was like, you can borrow it and
cancel up to five days. The ones we actually bought had zero return
policy. They’re like once you buy it right now in the store, that’s
it. When it comes in to your house, you inspect it, and you can either
reject it or keep it, and that’s it.

Bob: My question is, did you just get tired? Did you just wear yourself
out to get the couch?

Alan: No, I think what happened was, this went on for a while, and we’re
looking to get a
good sofa. What happened was, you can’t understand before. I think
that lack of flexibility, in this case, you’re right. It’s counter-
intuitive in that, yes, return policy doesn’t make that any easier.

However, in this case, it focused us into really ask yourself hard
questions.

Ervin: Basically, I think the return policy with the sofa you
actually bought was called a
Ulysses contract. It’s the idea of making not making a decision, or
not following through so painful, that you actually force someone to
do what you have to get done.

If anyone gave you the out, you’d want to take the out, because they
never made it solid. Once it became concrete with you, this is going
to be your couch. If you’re going to pull the trigger here, this is
it. There’s no turning back.

That’s why I don’t believe in Freemium. You know Freemium? Freemium
can actually get yourself into the same thing that.