Designing Features Using Job Stories

How one team used Job Stories to design a Profile

Product Design’s Waterfall

This article first appeared on — where the intercom team writes about design, customer experience, start-ups, and the business of software.

Personas and User Stories made sense when customers and product teams were far from each other. Traditionally, who the customer was and what they needed fell within the responsibility of marketing, business development or even sales. After this information was gathered it would be synthesized into a portable format and then pitched over the fence to a product development team, who was then responsible for building the product.

The casualties of this waterfall process are the subtleties which are necessary to understand when creating great products: causality, anxieties and motivations. As development teams recognize that they need to be close to customers, it’s also appropriate to consider better ways of leveraging customer empathy to create products.

This philosophy of focusing on causality, anxieties and motivations is called Jobs To Be Done and a granular way to bring this concept into a product is to use Job Stories to design features, UI & UX.

How, exactly, Personas fail

The biggest, and this article’s most pertinent, problem with Personas is this:

Personas are imaginary customers defined by attributes that don’t acknowledge causality.

These attributes, generally in the form of demographics, do not bring a team closer to understanding a customer’s consumption, or non-consumption, of a product. The characteristics of a Persona (someone’s age, sex, race and weekend habits) does not explain why they ate that Snickers bar: having 30 seconds to buy and eat something which will stave off hunger for 30 minutes, does explain why.

Snickers promotes a job to be done.

How, exactly, User Stories fail

“As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.”

User Stories, such as the one above, have three big problems:

  1. They use Personas.
  2. They couple implementation with motivations and outcomes.
  3. They ignore context, situations and anxieties.

Often, a feature or UX will fail. If it was defined by a User Story, then discovering why it failed will be difficult. Discovering why it failed will be difficult because implementation was coupled with motivations and outcomes. Because of the coupling, how can anyone know what was wrong? Was the implementation wrong or were the assumptions about motivations wrong?

Learn more about the challenges of User Stories here.

Enter the Job Story

The job story

First mentioned on and developed here, Job Stories are a different way of thinking about defining features, UI and UX; however, how does a team implement them into their workflow?

Here is one approach:

  1. Start with the high level job.
  2. Identify a smaller job(s) which helps resolve the higher level job.
  3. Observe how people solve the problem now (which job do they currently use).
  4. Come up with a Job Story (stories) that investigates the causality, anxieties and motivations of what they do now.
  5. Create a solution (usually in the form of a feature or UI change) which resolves that Job Story.

To demonstrate how this can work, consider how a team crafted a Profile View’s UX and UI for a product that helps car sales people get loans for people wanting to buy a car…

Designing A Profile View

It was early in the design process. The team was discussing what the Dashboard / Home View would look like and what features should exist there.

At some point Joe, a team member, stands up and draws a simple wireframe on the whiteboard. He pointed to a box and said:

This is the sales person’s profile.

The team listens to his rational for the profile view but are not immediately convinced. They asks a series of “why’s” for each particular part and circumstance for the profile view. Even after all these questions, the team wasn’t coalescing for or against the idea.

At this point the question was asked:

Why should the product have a profile view? Why should it be in one place or another? What information should it display? What situations is it resolving?What job is this profile view doing?

To resolve this, the feature was reframed in a process with Job Stories.

For brevity, this article will focus on just one job story for the Profile View. In reality there were several job stories related to the Profile View; however, including those would also make this article about 5x longer.

1. Start with the high level job.

The high level job for this product is to help a car sales person secure a car loan when someone buys a car from them. Currently, the buyer has to fill out a lot of difficult paperwork along with the car sales person.

2. Identify a smaller job(s) which helps resolve the higher level job.

In order to get the loan application filled out correctly, the sales person and buyer need to enter a lot of information about the car, terms of loan as well as the buyer’s (sensitive) financial information. Because the information is sensitive, the buyer needs to feel she can trust that her personal information is safe with the car sales person.

3. Observe how people solve the problem now (which job do they use).

Currently, when filling out this type of information, the buyer analyzes (usually visually) the sales person and car dealership and deduces if they are reputable and can can be trusted. They also generally fill in their sensitive information in close physical proximity, on a piece of paper, with the sales person. This helps them feel confident that the information is filled out correctly and won’t get passed around to people who shouldn’t be looking at it.

4. Come up with a Job Story (stories) that investigates the causality, anxieties and motivations of what they do now.

  1. When car sales people and their customers interact with each other via the product…
  2. Customers are going to want to feel like they can trust the organization, process and the sales person…
  3. Sales people are going to want to be confident that their process makes their customers feel comfortable…
  4. So that clients will fell safe entering their financial information into a process.

The above frames the situation into a Job Story. It can be fleshed out more by providing more situational context such as where & when it’s being filled out (e.g. at h0me or at the dealership) and anxieties each party will have about having and viewing a profile. More tips on creating Job Stories are here.

5. Create a solution (usually in the form of a feature or UI) which resolves that Job Story.

To resolve the above job, the team then decided on what features the Profile View should have and how it should be presented. Too little information and the Profile View won’t solve the original job, too much information could have negative effects. So, we decided:

  1. When the customer uses the product, the sales person’s profile view would always be visible. (Eases customer’s anxieties about not being physically with the sales person)
  2. The profile would have a picture of the sales person, job title, cars sold and years at the company, (Eases customers’ anxieties about whether the sales person is reputable and can be trusted)
  3. The profile view will enable easy ways for the customer to get in touch with the sales person. Examples are their phone number, email address and a button that says “Ask [sales person] a question”. (Eases customers’ anxieties about filling out the form themselves and getting something wrong)

Here is an example of a solution:

Here is a breakdown of the UI, the job each UI element is doing and what situation(s) it’s resolving.

With the UI complete, we now have a UX in which every element can be traced back to resolving a job: ensuring the customer feels safe when exposing personal information.

Design For Real People, Design For Causality

Designing successful products means observing how real people solve problems now, exploring the context of the situation they are in and then understanding causality, anxieties and motivations.

Abstracted attributes and coupling implementation with motivations & outcomes are distractions for a team. If the team digs deep and learns about a customer’s Job To Be Done, they can then more effectively craft solutions… and using Job Stories to design features, UI & UX is one way to do it.

Further Reading

5 Tips For Writing A Job Story

 — Learning from a new way to define features and products.

Replacing The User Story With The Job Story

 — Too many assumptions are dangerous

down the rabbit hole

 — writings by alan kelement

Written by

Product designer and engineer who loves to create and grow products.

Turning Down TechCrunch

Gittip is a weekly gift exchange. We launched about a year ago, and we currently have about 1,000 weekly active users exchanging about $3,000 per week on the platform.

I’ve been trying to dial it to eleven with Gittip in terms of how open and transparent a company can be. According to our definition of an open company, we share as much as possible, charge as little as possible, and don’t directly pay ourselves (Gittip is funded on Gittip). Our code is open source, we look for open partners, and, increasingly, I’ve been asking people who want to Skype if instead we can have an open call that we live-stream and post to YouTube.

My commitment to this last practice, open calls, was put to the test today when, in the midst of two open calls, I received an email from a journalist at TechCrunch, picking up on a conversation we started last month about doing an interview. TechCrunch is, of course, a leading publication for the start-up scene and the wider tech industry, and a story on TechCrunch is something of a coveted rite of passage for new tech companies. Jareau Wade from Balanced Payments had mentioned my name in response to an inquiry from a contact of his at TechCrunch about “some of Balanced’s more interesting partners” (thanks Jareau!). This TechCrunch journalist and I played email tag for a bit, finally reconnecting today and arranging to have a call tomorrow. Here’s how it went:

Me: How about 11:00 California time tomorrow (Tuesday) or Wednesday?

Are you up for a Google Hangout that we live-stream and post to YouTube? I like to do calls that way in the interest of openness. :-)

TC: Tomorrow at 11:00 PT is fine, and google or skype is fine, but don’t like the idea of it being recorded or posted to youtube.

Me: Hey man, I really appreciate your interest, and obviously I appreciate that TechCrunch is a major industry publication and it’d be great to get a story in there. However, I’m trying to run Gittip as openly as possible, and I’m becoming increasingly attached to the idea of not having private calls if I can help it. I just finished up an open call, in fact, and you will see in the first 60 seconds that I’m wrestling with how to respond to you here:

As I mention there, I haven’t really done any interviews with journalists yet, and I need to get off on the right foot and establish a habit and a pattern of only doing open calls if I can.

If you’re not comfortable with streaming/posting the call, I will totally understand. In the future I’ll be sure to let journalists know up front about my open call policy. :-)

Let me know one way or another …

TC: Yeh, good luck with that.

My ideas on when to agree to private calls and when to insist on openness are still very much in formation. I like to have a face-to-face call with new contributors to Gittip, for example, and there I’m willing to have that first call in private if the person isn’t comfortable doing it openly. With journalists I’m much more comfortable requesting openness. They’re writing for the public record, and it benefits readers and keeps us both honest to have the raw material on record as well.

Update: One emerging theme (here, here, here) is that journalism depends for its value on “the scoop.” Could we have agreed on an embargo of the raw interview video until the piece was published? Perhaps.

How would publishing a raw interview threaten a journalist’s scoop? I think it’s important here to see the distinction between “open” and “recognized.” A raw hour-long YouTube video is going to get no traffic compared to a published article. The interaction is open, but it has no chance of reaching the public consciousness in that form, so the scoop isn’t directly threatened by an open interview. If anything, pre-publishing the raw interview builds anticipation among true fans, who are then more likely to spread the word when the story is published.

What about the risk that another journalist will get the scoop? Imagine TechCrunch interviews me, and then AllThingsD finds the raw video and writes the story first. Is that the real threat that’s being felt? If so, I’m not sure I have a good answer for that. To me, that looks like it exposes journalism as a zero-sum game, and I don’t play zero-sum games, if I can help it. In my worldview, having multiple journalists conducting interviews and having multiple journalists writing stories based on those interviews is an overall win for readers and for humanity.

“But the money!” I hear you cry. To which I reply: Let’s get some win-win journalists funded on Gittip. The anonymous funding model should mean there is no conflict of interest, and journalists are then rewarded by readers for their story-telling and curation skills rather than by advertisers for their traffic-hoarding skills.

Written by

What do Apple, the Chicago Bulls and Oprah have in common?

An unspoken contract between their team members.

The Chicago Bulls of 1995-1996 were perhaps one of the best teams to ever play the game (to this date); the Bulls franchise won 6 NBA titles in the 1990s. They had fifteen players in their roster, but Michael Jordan was their indisputable superstar. After each game, journalists and fans chased after him in the Bulls’ locker room at United Center, his teammates were largely left alone.

That said, they were critical to his, and the team’s, success. It was Scottie Pippen who gave MJ the best assists and Dennis Rodman who got 2x more rebounds than Jordan. And of course Steve Kerr emerged as a 3-point specialist; in fact he owns the best 3-point percentage in NBA history at .454.

The Oprah Winfrey Show had a production team of a few hundred people. They worked tirelessly for 25 years and produced the highest-rated talk show in American TV history. Although they were the “best team in TV”, the world idolized Oprah; after all the show had her name. Without her team though, Oprah would not have been able to invite 28,000 guests and entertain ~350 audience members per show from 1986 till 2011.

Apple is the world’s most valuable brand and its iconic founder, Steve Jobs, is universally perceived as the creative genius behind building the world’s first mainstream home computer, the iPod, the iPhone, the iPad and dozens more products.

But if it had not been for Woz, the Apple I and Apple II may have never been born. After all, Steve didn’t ever code at Apple. When Jobs came back to run Apple in the mid ‘90s, he considered Jony Ive to be his spiritual partner. It was Sir Jonathan who led the industrial design work for the iMac and the iPod products, whicpaved the wave for Apple’s rebirth as a consumer electronics and multimedia company with a market cap of hundreds of billions of dollars. Apple was also capable of hiring and retaining many tens of thousands of loyal employees worldwide, a well oiled machine.

So how can superstars and rookies collaborate harmoniously with each other on a team? Superstars have big egos and limited time to waste. Rookies have little experience and limited vision. But harmonious collaboration is possible, as was the case with the Chicago Bulls, The Oprah Show and has been the case at Apple for 16+ years.

In all sorts of winning teams, there is an “unspoken contract” between the superstars (or senior team members) and the rookies (or junior team members):

a. The junior folks are in it for the learning, the attribution and the opportunity to score huge wins early on in their career.

b. The senior folks are in it for executing their vision, the financial rewards and the power that comes with leading an organization. In some rare instances, superstars are in it for building their legacy and changing the world.

Whenever there is a breach of contract, the team dynamics get messed up; sometimes permanently. In some instances, junior folks have unrealistic expectations and feel that because they are doing all the *real* work, they are entitled to receive all the credit and are guaranteed future promotions. Junior team members normally excel whenever they work hard, have strong intellectual curiosity, take new initiatives and are prepared to learn from their mistakes.

In some other instances, senior folks who are in a weak position (internally) have to take all the credit for themselves and legitimately the junior folks feel disappointed. Surprisingly, yet frequently, some of the senior folks can simply be assholes to those supporting them.

Superstars have to drive the vision, inspire their teammates and most importantly lead by example. Steve Jobs, according to Walter Isaacson’s biography, was the most proud of Apple itself, which Jobs considered his greatest creation, a place where imagination was nurtured, applied, and executed in ways so creative that it became the most valuable company on earth.”

When Oprah Winfrey moved to LA to launch OWN she took 50 of her production staff with, employees who had spent most of their career in Chicago. I am sure that they received a ton of exciting job opportunities closer to home, yet decided to stay loyal and follow their long-time leader.

Toni Kukoc was one of Europe’s best basketball players in the late 80s and early 90s; he led a team that won the prestigious Euroleague title three times in a row. But he decided to become a small fish in a large pond when he transferred to the Chicago Bulls in 1993 in order to play with Air Michael.

Unfortunately for Toni, Jordan retired temporarily in 1993, but then came back in 1995 to lead the Bulls in their second three-peat while Toni was still there. Kukoc was always coming from the bench, but was consistently the team’s third scorer after MJ and Pippen.

Michael Jordan, recognizing Pippen’s work and unselfishness, famously said: “Scottie Pippen, he’s my guy. I love him like a brother. He pushed me to be the best basketball player every day in practice. And I pushed him to be the best Scottie Pippen he could be.” Not a surprise that when the Chicago Bulls decided to retire Scottie Pippen’s No. 33 jersey, they hang it next to Jordan’s legendary No. 23.

Written by

Early Stage VC | Entrepreneur at heart. @bonatsos

Published January 9, 2014

The Future: When Mobile Doesn’t Matter

The future of programming means that the mobile/desktop/wearable distinction is becoming irrelevant

For the last few years, the venture industry has been absolutely infatuated with mobile technology.

It’s easy to see why. Mobile is the fastest growing personal computing platform, with even conservative estimates stating that consumer mobile data will occupy 10% of all internet traffic by 2017. The financial success of mobile-first and mobile-focused startups like Pandora and Uber have also been strong indicators of the demand for mobile applications — so much so that most VCs now will raise an eyebrow if your primary focus for distribution doesn’t target at least one mobile platform.

As a VC I tend to agree with this approach. It’s logical and fair to draw conclusions about mobile’s success based off of these indicators, and given how nascent mobile development is compared to software development as a whole (the iOS app store is still less than a decade old) it makes sense to try to invest in teams positioned to capture as much of this titanic market that’s still very much up for grabs.

But as a developer I’m not so sure. I cringe whenever I hear the phrase “the death of the PC,” and I feel like people who completely write off traditional computing platforms are the same people who’ve never programmed and shipped anything before.

While the indicators for public demand of mobile over desktops/PCs are clear and strong, the dynamics of software development and programming (the resource market that feeds mobile and PC software) tell a very different story:

In the possibly near future, it won’t really matter whether you’re building a mobile app, a desktop app, or even an application designed for wearables because it’s all the same thing.

Almost 83% of the most popular programming languages last year were hardware agnostic.

Hardware and platform abstraction reigns supreme in the world of the developer. In 2013, 83% of the most popular programming languages in the world were hardware agnostic. These languages incorporated some measure of abstraction in order to ensure that the developer didn’t have to worry too much about the system their code was being executed on.

If the world of 2015 is one filled with programmers who were born and raised on high level languages, it’ll be a world where fewer and fewer developers care where their code is being executed: on a desktop, on a laptop, or even on a tablet or mobile device.

This trend is probably going to continue as we move forward in the decade because of dramatic changes in computer science education.

Most new CS majors no longer learn C or assembly first, low-level languages that require an intimate understanding of their code’s underlying architecture. Instead, high level interpreted languages like Python and Java have become the bread and butter of a college student’s introduction into computer science.

Code written in these languages is not read verbatim by the computer. Instead it’s parsed and optimized by a compiler into the underlying machine’s unique machine code or read by an interpreter and similarly translated into a computer’s native logic. For the developer, this means that you don’t need to agonize how much memory is in a machine or even what resolution it might output images at. The hardware effectively doesn’t matter.

The first language you learn as a computer science student is extremely formative. It serves as the lingua franca you use in understanding the concepts you’ll learn throughout your time in school and beyond, and it shapes your development style and preferences when you get out and go into the real world.

If the world of 2015 is one filled with programmers who were born and raised on high level languages, it’ll be a world where fewer and fewer developers care where their code is being executed: on a desktop, on a laptop, or even on a tablet or mobile device.

Abstraction is just one part of the story though. Even if future developers don’t care so much about the metal on which their code is being executed, there remain strong divisions between software written for mobile and wearables and the software written for PCs or the cloud.

These divisions are strongly rooted in the programming languages and frameworks used by developers to create apps. Java, Python, Objective-C, and Scala may all be high level languages that rely on compilers and virtual machines to be run cross-platform. But only two of these are actually natively legible by mobile operating systems. If you grew up learning Python or Scala, you can’t just open up Eclipse and hack out a native Andorid app.

But that may be changing. As mobile devices become an instrumental part of a user’s computing experience, smart operating system vendors are starting to converge their mobile and desktop development platforms. This is hugely advantageous to developers, because it’s onerous to have to learn and wield different languages to develop cross-platform applications.

C# is a language originally designed for desktop and server applications that now serves as the primary vehicle for developing mobile apps for Windows Phone (as well as Windows 8).

A great example of this convergence is C#. C# is Microsoft’s popular object-oriented response to Java, written in the early 00’s in order to compete with Sun Microsystem’s dominance in the server and cross-platform desktop world. In many ways C# is the polished lovechild of C++ and Java — languages popular and dominant at the time of its birth in computer science education and real world development alike.

But despite its server and desktop origins, C# has become one of the most popular mobile development languages in the world. Microsoft shrewdly architected their mobile operating systems to support the .NET Framework, the underlying engine used by C# to be executed on any Windows-based device.

This meant that traditional desktop and server developers who used C# could easily move into the world of mobile development, because they wouldn’t have to learn a new programming language or development framework.

The role of convergence extends beyond the compiler. Microsoft’s dramatic changes to Windows’ user interface is another example of how the PC is converging with mobile and other platforms.

Microsoft’s Metro UI is now used across all of its applications including Windows PCs, Windows Phone mobile devices, and even the new Xbox One gaming console. This is a strategic decision taken by Microsoft to prepare users for a world of complete platform convergence.

When Microsoft chose to rearchitect Windows’ user experience with Windows 8, they implemented a new UI called Metro. Metro does not look like a traditional desktop UI, and its “tiled” experience in many ways feels more like a mobile OS than what you might expect with a Windows PC.

Since the launch of Windows 8, Metro has since become the standard user experience across all of their computing platforms. Even the new Xbox One uses Metro, unifying the experience that any Microsoft user has with a Microsoft-developed operating system.

The implementation of Metro has been a controversial one, but in my opinion it’s a clever strategic decision on Redmond’s part that speaks to this point of convergence we’ve been talking about.

If you have one UI to build apps for, you minimize the amount of design and development work you have to do when developing cross-platform applications. With time and further development, writing both desktop and mobile applications for Windows in the future may be as simple as hitting the “Compile” button in Visual Studio.

Convergence and hardware abstraction may be well positioned to change the software development landscape and make the distinction between writing mobile apps and writing desktop apps irrelevant. But there are still key barriers to overcome in the form of the underlying architecure said progams is written on.

Most compilers and interpreters essential to running desktop code are focused on Intel’s x86 computing architecture. But very few mobile devices use x86, instead opting for the more power-friendly ARM architecture used by vendors such as Qualcomm and Nvidia. ARM and x86 are very different beasts, and applications written for each platform can’t be automatically ported to the other without significant degredations in performance.

Despite this architectural barrier, vendors like Microsoft and Intel are starting to bridge the gap. Both are actively developing smarter compilers that can compile and optimize code written in high level languages for both x86 and ARM. We’re still very early in our efforts to bridge the gap between mobile and desktop computing architectures, but companies like Intel are incentivized to bridge the gap because for them this is a very life or death strugle.

At the end of the day, the importance of “mobile relevance” really comes down to your time horizon. Mobile and desktop will almost certainly remain discrete platforms for the next two to three years, and many applications looking to ship during that period need to be mindful of this difference.

But beyond this time, it seems fair to assume it may not matter whether you’re a mobile app developer or a desktop app developer. With the current trends in hardware abstraction and architectural convergence going the ways they are, these two roles may become the same thing.

The cloud though? That’s another story…

Written by

VC @GGVCapital. Product alum @NetApp, @SAP, @EA. Passionate about kendo, security and infrastructure tech, and gaming. Comically bad at parallel parking.

Updated January 9, 2014

5 Tips For Writing A Job Story

Learning from a new way to define features and products.

A Job Story is a powerful way to facilitate team conversation and discovery when designing products. They are meant to cut right to the job to be done by eliminating distractions. The job story encourages the product’s design process to focus on context, causality and motivations instead of assumptions, subjectiveness, personas and implementations.

As I write more job stories, I’ve been paying attention to characteristics which make some stories better than others. When a story is well done, it helps me and my team cut right to what needs to be discussed and puts us all on the same page — making the product design process dramatically better.
Here are 5 tips which will help when writing Job Stories:

  1. Refine A Situation By Adding Contextual Information
  2. Job Stories Come From Real People Not Personas
  3. Design Modular Job Stories Which Features (Solutions) Can Plug Into
  4. Add Forces To Motivations
  5. Job Stories Don’t Have To Be From A Specific Point Of View

1. Refine A Situation By Adding Contextual Information

When David Wu described to me how a situation can capture a whole set of conditions, it struck a chord with me. When I add more context to a situation, I’ve found that it’s easier to design a working solution which also handles any anxieties which can push a customer away from using a product or feature.
Let’s compare:

  1. When I want something to eat….
  2. When I’m in a rush and want a something to eat….
  3. When I’m in a rush, I’m starving and want something to eat….
  4. When I’m in a rush, starving, need something I can eat with one hand while ‘on the go’, am not sure when the next time I’ll be able to eat, …

The more context we have for the situation, the better I can design a solution. In version #1, a sit down restaurant will work. In version #4, perhaps a slice of pizza or snickers bar will work best.

2. Job Stories Come From Real People Not Personas

Because they are a mashup of assumptions and attributes, personas can have a destructive effect on product design. They can give a false sense of knowing the customer and thus can really leave gaps in design. For example, you can’t ask a persona about their anxieties, why they chose Product A vs Product B, what else was going on when they chose Product A vs Product B, or that when they first opened your app they didn’t know what to do first….

Job Stories can only come from real customer interviews. Before designing a feature or new product, you must talk to real people and uncover all the anxieties and contexts which were in play when they used your or a competitor’s product.
If you are interested in learning about techniques on how to conduct an interview, listen to the The Mattress Interview with Chris Spiek and Bob Moesta. Chris, Bob and Ervin also have a Udemy course on jobs-to-be-done customer interviews.

Another reason why some favor personas is because they don’t know how else to organize all the information they get about or from their customers. How to organize job stories will be addressed in a future article.

3. Design Modular Job Stories Which Features (Solutions) Can Plug Into

When designing job stories, it’s important to not commingle them with solutions. This is another important distinction from user stories which encourage defining implementation.

When commingling personas ( or situations ) and solutions….

Below is from a source describing how to write effective user stories. The author encourages to also create sub stories which ‘add detail’ to help develop the user story. Here is an example:

As a user, I can backup my entire hard drive.

…and after adding detail….

As a power user, I can specify files or folders to backup based on file size, date created and date modified.


As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.

Given the examples above, suppose the power users didn’t care much to specify which files or folders to back up bases on file size, date created….. In this case how do you figure out what went wrong. Is your persona wrong? Is the feature wrong? Is it the wrong feature for the persona?

Breaking out situations ( jobs ) and solutions.

The bottom line here is that when jobs are seen as separate from solutions, you notice that they can be explored differently and at different times. Another benefit of modular stories and solutions is how you can begin to see where jobs overlap and several jobs can end up sharing a common solution.

How job stories relate to solutions and other job stories is a topic onto it’s own. In the mean time, start off with visualizing the relationship between job stories and features like this:

The last image references what I call a Situational Segment. It’s an idea I’ve been thinking about lately and is a topic that needs to be explored on it’s own.

4. Add Forces To Motivations

Another idea from David Wu is to include forces with motivations. In the job story format of Situation — Motivations — Expected Outcomes, the Motivation stage can be augmented by adding pull and push forces. Adding forces to a motivation is much like adding context to a situation. Let’s consider the mayday feature by amazon, as Ross Belmont put it:

When I’m using my tablet and encounter a problem, I want to get help right away so I can finish what I started.

Let’s stick with the motivational part: I want to get help right away and add some forces:


When I’m using my tablet and encounter a problem….


I want to get help right away…

Force: I’m irritated because I was in the middle of something…

Force: I’m nervous I won’t finish what I was just doing…

Force: I get nervous asking for help…

Force: Asking for help might make me look stupid…

Force: I’m shy about showing what I’m working on to someone else…

Expected Outcome:

So I can finish what I started.

When a story adds forces, we can then design solutions which help reduce forces that push customers away from a product or feature and increase the forces that pull them towards a product or feature. In Amazon’s case, they could:

  • Reassure that customers don’t have to wait long to get help. ( I’m nervous I won’t finish what I was just doing )
  • Ensure that customers can choose how much access the customer support rep has to your tablet. ( I’m shy about showing what I’m working on to someone else )
  • Remind customers how common it is to ask for help. (Asking for help might make me look stupid)

5. Job Stories Don’t Have To Be From A Single Point Of View

Lately, I’ve been experimenting with the idea of not restricting stories to the point of view of just one person. Instead, I’ve been writing stories from a third person point of view.


When someone approaches a bank for a home mortgage and fills out an application…


The applicant wants to know if the application is accepted or not…

The banker wants to make sure that the application is filled out correctly…

The bank wants to check if the applicant has acceptable credit history…

Expected Outcome:

So that a home mortgage is quickly given to a low risk person, which the bank feels confident it will profit from.

Again, I’m experimenting with these so I’d love feedback on what people think about this. So far, 3rd person stories do well when a product deals with multiple parties, such as a real time bidding site like eBay.


I’m still working with job stories in my product design and I’m sure the more the concept is put into practice, adjustments will be made and it will continue to be built upon. As these come up, I’ll continue to comment about it.

Further Reading

Designing Features Using Job Stories

 — Personas and User Stories made sense when customers and product teams were far from each other. That’s no longer the case. This is a gues…

Replacing The User Story With The Job Story

 — Too many assumptions are dangerous

Written by

Product designer and engineer who loves to create and grow products.

Demystifying Programmatic Marketing and RTB

There is a lot of buzz in the digital advertising industry about “Programmatic Marketing.” Some people describe it as the intersection of big data and technology. Others primarily think of it in the context of Real-Time Bidding (RTB) on display exchanges. I thought I would take a stab at describing Programmatic Marketing and RTB for people who are interested in these topics, but are not very familiar with them.

What exactly is Programmatic Marketing, and how does it improve ROI?

At a high level, Programmatic Marketing is the practice of implementing an automated set of business rules to efficiently target your most valuable customers and prospects with personalized ads.

Each of the bolded phrases in the statement above speaks to the promise of programmatic marketing from an ROI standpoint.

  • Automated. By automating buying decisions, marketers remove the friction of the sales process (including humans placing buying orders) and reduce their marketing costs.
  • Efficiently target. With programmatic marketing, the goal is to eliminate wasted impressions and clicks. Thus, you only show ads to users who have intent, and who are likely to take the desired action (e.g. “buy”).
  • Personalized ads. Programmatic marketing increases the likelihood of consumer action by showing each user a personalized message. The goal is to present users with a more customized call-to-action based on their recent browsing behavior, for example, or other anonymized data that you know about them.

There are many forms of programmatic marketing. In the display world, programmatic marketing often takes the form of dynamic retargeting on Real-Time Bidding (RTB) exchanges.

Why is RTB important?

RTB is one of the fastest growing parts of digital marketing, and it holds significant promise to increase marketer’s ROI. According to eMarketer, RTB Digital Display ad spend will grow from a $1.9B market in the US in 2012, to a $8.5B market by 2017, a growth rate of 35% CAGR. As a percentage of total digital display ad spending, eMarketer predicts RTB will grow from 13% in 2012 to 29% by 2017.

US RTB market forecast (source: eMarketer)

Although RTB is projected to grow enormously over the next few years, both publishers and media buyers have some concerns with it. For publishers, the concerns are primarily about maintaining pricing control and direct relationships with advertisers, as well as about the quality of ads that are showing up to their users. As a result of these concerns, publishers may only open up a portion of their inventory for Programmatic Marketing and RTB. For example, some publishers experiment primarily with opening up “remnant” (unsold) inventory to RTB. Additional concerns from publishers include data leakage (DSPs are able to see impression requests for users without placing bids, allowing them to refine their own segmentation) and potential channel conflict with direct sales.

On the media buyer side, the concerns are around being able to access more premium inventory, and having exclusive or preferred access to inventory. Marketers may select to work with a Demand-Side Platform (DSP), for example, based on the amount and type of inventory it has access to.

How exactly does RTB work?

The basic operation of RTB is as follows. A publisher will have software from a Supply-Side Platform (SSP) to manage and maximize the value of its ad inventory. A media buyer will have software from a Demand-Side Platform (DSP) to manage its marketing campaigns across a number of different publishers and SSPs.

When a user visits a publisher’s website and requests a web page in her browser, the SSP will attempt to fill the ad inventory created by that user’s request. The SSP will make a request to the RTB exchange on behalf of this user, potentially annotating the request with data on the user or the content being browsed on the publisher’s website. The RTB exchange will then fan out this request to multiple DSPs, each of whom may have a cookie on this user’s browser.

Based on its knowledge about this user (e.g. the user recently searched for flights to Hawaii on a travel website), a DSP will bid on the right to serve an ad to this user. The RTB exchange will then run an auction for the ad impression generated by this user. The winning DSP will serve a creative — potentially a dynamic display ad with personalized content, perhaps including the recently browsed flight details, price, and image of the destination — to the user.

As a final step, the publisher’s web page loads in the user’s browser, including the personalized ad that was served by the DSP. This entire process—from user requesting the web page, to the execution of the ad auction, to the personalized ad inserted into the web page—happens in real-time, on the order of milliseconds.

Framework for Analyzing RTB: Targeting, Creative, Measurement

For digital marketers, the goal for every marketing campaign is to reach the right audience at the right time, deliver a compelling message, and then optimize based on the results.

This goal can be decomposed into the framework of Targeting, Creative, and Measurement:

  • Targeting: “reach the right audience at the right time”
  • Creative: “deliver a compelling message”
  • Measurement: “optimize based on the results”

Let’s examine dynamic search retargeting on RTB display exchanges in the framework of targeting, creative, and measurement. For this analysis, let’s consider a theoretical example that involves a user — Rebecca — and a marketer, Costco Travel. Rebecca is researching vacations in Hawaii, and Costco Travel wants to connect with users who have intent to travel to Hawaii. (Disclaimer: for simplicity, I have created a fictitious example involving and Costco Travel. I don’t know if or Costco Travel participates in RTB dynamic retargeting or not, but just chose these brands in my theoretical example.)


The big shift in Targeting for RTB is that it’s individual user-driven, not segment/content-driven. With traditional digital ads, a media buyer would buy ads based on the content of a publisher’s website, as a proxy to reach a desired audience. For example, in the past, a travel marketer would purchase ad inventory on the travel section of a portal’s website to promote vacation packages to Hawaii.

In the world of RTB, marketers can precisely target individual users whom they believe have demonstrated purchase intent, rather than the coarse-grained approach of targeting an entire audience. Since the RTB exchange runs an auction for each impression, marketers can set business rules to only bid on user segments that are important to them. And marketers will be able to identify those users who are important to them because they (or their DSP partner) have a cookie on the user’s browser, which also has associated first-party or third-party data.

In our example, Costco Travel is offering a special vacation package to Hawaii, and can choose to only serve ads to users who have searched for accommodations in Honolulu on They don’t need to waste their impressions on users who visited the Travel section of, but who aren’t interested in a Hawaiian vacation. Costco Travel’s DSP has the ability to place a retargeting pixel on the website.

Rebecca visits and searches for hotels in Honolulu. During her visit, Rebecca’s browser receives a cookie from Costco Travel’s DSP that includes the data about her search (e.g. destination, desired travel dates, filters used, etc.).

DSP places a cookie on user’s browser

Suppose Rebecca doesn’t book her travel during this session. Instead, she decides that she wants to do more research later, and instead switches gears and visits a news website to catch up on the day’s news. The news website works with an SSP, and the ad inventory that is created by Rebecca’s visit is eligible for RTB bidding.

When Rebecca shows up in the RTB auction, the DSP that represents Costco Travel will bid higher for the right to show her an ad than a random web user, because Rebecca is “in-market” for a Hawaiian vacation. And the DSP will bid lower — or perhaps not even bid at all — for the random web user who has not shown any intent to travel to Hawaii. Thus, Costco Travel is able to direct its marketing budget towards only those users who are in-market for a Hawaiian vacation, and therefore avoid wasting impressions on users who have no desire to travel to Hawaii.


In addition to only targeting users who have expressed recent intent, RTB retargeting involves delivering personalized ads to user. In this case, the DSP that represents Costco Travel has fairly precise data about Rebecca’s actions on For example, it may know the destination, number of nights, price ranges, and filters that Rebecca used in her search, which gives them a sense of what vacation packages and pricing would probably be attractive to her.

DSP knows the destination, price range, and other data from the user visit

With this information, the DSP representing Costco Travel can assemble a personalized ad creative that will be most effective for Rebecca. Since they know what price range is likely to be effective for her, and the star-rating of the accommodation she has browsed, the DSP presents a customized ad just for her.

Personalized ad with pricing, destination information


RTB retargeting uses the same measurement approaches that direct response (DR) marketers employ in all other situations— it looks at click-throughs (CTR) and conversion rates. Since RTB retargeting may also involve serving a personalized ad to a user multiple times before that user converts, some marketers use view-through attribution as one method of analyzing the ad’s performance.

With view-through attribution, the marketer will establish a window of time — the “attribution window” — during which the user is in the midst of a purchase cycle. For a large vacation, the attribution window used may be a week or two. For a car purchase, the attribution window may be a couple of months.

The “view-through” part of attribution refers to the idea that an ad should receive at least some credit for driving the conversion just for being seen, even if there was no user interaction with the ad. Proponents of view-through argue that data shows that increased frequency of ad exposure correlates with higher conversion rates from users. Detractors of view-through argue that without any user interaction with the ad, you can’t prove that a user actually saw it. The truth is probably somewhere in the middle.

Given RTB retargeting’s extensive use by Direct Response advertisers, the ability to measure conversion performance (including site visitation) is of critical importance. Measuring conversion performance, however, is one of the challenges for RTB retargeting on mobile.

RTB Re-imagined for Mobile and Native Advertising

RTB retargeting is primarily being pursued with traditional display advertising, and is still relatively early with mobile advertising. I have written previously about how mobile ROI is difficult today due to consumer shopping behavior on smartphones and the fragmentation of Internet usage across devices. The fact that users tend not to convert directly from smartphones makes RTB retargeting a challenging proposition on mobile. The way that RTB retargeting will initially develop on mobile will be via driving users to perform in-app conversions, on apps that they have already downloaded to their smartphone. However, in order to tap into the full RTB retargeting opportunity, the industry will have to solve the problem of targeting and measurement across devices.

Similarly, RTB retargeting is also in the beginning stages with respect to “native” advertising. One of the hallmarks of native advertising is that the ads blend seamlessly into the consumer experience, and often strongly resemble content. The ads used in RTB retargeting with traditional display are often little more than a call-to-action to buy, with product information, pricing, and a product image. These ads probably look more like ads than content. In the context of native advertising, RTB retargeting ads may therefore not be able to blend in as easily to the consumer experience. Thus, RTB retargeting ads may need to be re-imagined for native ad platforms.

Programmatic Marketing and RTB are important concepts for digital advertising, given their projected growth rates and the improvements they create for marketer ROI. For media buyers, RTB retargeting — one of the most prevalent forms of Programmatic Marketing — involves precisely targeting users who have active purchase intent, eliminating wasted impressions and clicks. The particular set of users who have intent consist of users who have recently browsed products on your website (“site retargeting”), or who have recently searched for products on your own or a third-party website (“search retargeting”). A Demand-Side Platform (DSP) will bid on desired users that have intent, and a real-time auction is run for the right to show an ad to those users. If the DSP wins, it will deliver a personalized ad to a user, and the marketer will evaluate the impact of the campaign by measuring click-through and conversion performance. There are some interesting nuances for RTB with mobile and native ad platforms. These are early and exciting days for programmatic and RTB within the mobile ecosystem. I’m looking forward to all of the innovation that’s yet to come.

Written by

Entrepreneur. Product management @ Twitter.

Replacing The User Story With The Job Story

I’ve written about the problem with user stories before. At the time, I found it better to just have the team talk over proposed changes to the product. This worked great when the team had gelled and the product is very mature; however, now I’m working with a new team and building a product from scratch. In this case, because our canvas is blank, we are having trouble getting on the same page when it comes to customer motivations, events and expectations. But today, things have turned around. I’ve come across a great way to use the jobs to be done philosophy to help define features.
I call them Job Stories.

Where It Comes From

The idea comes from the really smart guys at intercom. Here is what is they say:

We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome:

When _____ , I want to _____ , so I can _____ .

For example: When an important new customer signs up, I want to be notified, so I can start a conversation with them.

It’s not refereed to as a Job Story in the article, but I’ll call it that so I can easily reference it in the future.
The article doesn’t spend a whole lot of time with the concept, so I’ll talk about why I like it and why it’s better than User Stories.

The Problem (Again) With User Stories

Summed up, the problem with user stories is that it’s too many assumptions and doesn’t acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there’s no room to ask ‘why’ — you’re essentially locked into a particular sequence with no context.

Here’s how I see the format:

Assumptions and disconnect between there persona and action

The first problem is that we start with a Persona, which is a very bad idea, and then plop in an action which we think should be taken in order to achieve the expected outcome. As I’ve marked in the above image, there’s really a disconnect between the action and persona.
Here, let’s look at some existing User Stories:

An example of how to write User Stories

In the above chart, when someone reads moderator or estimator is that really adding anything? If anything it’s adding ambiguity to the flow. You and I are going to attach our own interpretation of what a moderator is or why they are in these particular contexts.

Here, try this. Chop off the whole As a / an segment and see if you’re really losing anything. Compare these two:

As a moderator I want to create a new game by entering a name and an optional description


I want to create a new game by entering a name and an optional description

Did the sky fall?

The Job Story : All About Context and Causality

A Job Story format

Check out the image above. Now we’re cookin’!

All of the information above is critical and very informative because we’re focusing on causality. Each job story should provide as much context as possible and focus on motivation….instead of just implementation.

Let’s rewrite some examples from the user story chart above as a Job Story and add motivation and context to each one.

User Story:

As a moderator, I want to create a new game by entering a name and an optional description, so that I can start inviting estimators.

Job Story:

When I’m ready to have estimators bid on my game, I want to create a game in a format estimators can understand, so that the estimators can find my game and know what they are about to bid on.

User Story:

As an estimator, I want see the item we’re estimating, so that I know what I’m giving an estimate for.

Job Story:

When I find an item I want to set an estimate for, I want to be able to see it, so that I can confirm that the item I’m estimating is actually the correct one.

User Story:

As a moderator, I want to select an item to be estimated or re-estimated, the team sees the item and can estimate it.

Job Story:

When an item does not have an estimate or has an estimate I’m not happy with, I want to be able to restart the estimation process and notify everyone, so that the team knows a particular item needs to be estimated upon.

Define Motivations, Don’t Define Implementation

Job Stories are great because it makes you think about motivation and context and de-emphasizes adding any particular implementation. Often, because people are so focused on the who and how, they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.

Further Reading

5 Tips For Writing A Job Story

 — Learning from a new way to define features and products.

Using Job Stories To Design Features

 — How one team used Job Stories to design a Profile

Written by

Product designer and engineer who loves to create and grow products.

Updated December 12, 2013

Published in

Go to Jobs To Be Done

Jobs To Be Done

Exploring new ways to create products and define markets.

View story at