Scaling the JTBD Framework With Your Team

Vineet Kumar at UXDX Community: Bengaluru. Video: https://youtu.be/C5SwF6ULzgc

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and what Postman is building

[00:00:00] Hey guys, I hope you're all having an excellent time at UXDX and learning lots of new things to take home to your product teams. Today I'm going to be taking you through a framework that's been critical to us building a product used by 13 million developers, and some of the lessons we have learned while scaling it within the organization.

[00:00:23] For a quick introduction, I'm Vineet, and I work as the director of UX at Postman. I love designing digital products because of their reach and the direct impact they have on so many people's lives. In my role, hiring is my biggest headache at the moment, but I spend a significant amount of my time looking at how we can make software development more accessible to people. When I'm not working, I'm probably trying out some indie game off of Steam while trying to stave off one of my three cats.

[00:00:58] For those of you who aren't familiar with Postman, we're building the world's most complete API platform. Today the API lifecycle is fragmented. API producers and consumers spend most of their time switching between code repositories, design tools, documentation and infrastructure dashboards. We want to bring it all into one place, so your entire product team has the same understanding of your APIs.

[00:01:29] To give you a brief idea of how this talk is going to go: I'm going to start with a quick introduction to the Jobs to be Done framework, before moving on to how Postman has evolved in the past couple of years and some of the problems we have encountered while scaling Postman from a team of 10 to more than 300 employees. We'll then take a look at how we scaled our processes using the Jobs to be Done framework to tackle those problems, and then we'll round it off with tips on how you can apply the Jobs to be Done framework in your day-to-day work, and some common pitfalls to avoid.

Jobs to be Done and job stories

[00:02:11] The Jobs to be Done framework is best understood through this simple motto: make better users, not products. As a product company, it's important to realize that users give you money to complete a job, not specifically to buy a product. You want to focus your efforts on helping users complete that job, through whatever combination of tools is required.

[00:02:38] Jobs are represented by job stories, and the skeletal structure of a job story looks something like this. It's a statement that tries to capture the situation, the motivation and the expected outcome of a user trying to complete a particular job. As an example, this is a job very relevant to what Postman helps developers achieve: "When I am debugging an API endpoint, I want to point my team to a specific API response, so I can highlight an anomalous behavior of the endpoint."

[00:03:14] One important thing to note is that the job story doesn't mention Postman or any of its products anywhere. It states the situation and the motivation of the user without assuming that they will use your product to achieve it. This can be crucial to understanding the competitive landscape around your product. I'll keep coming back to this example over the course of this talk, to illustrate the role this framework has had in changing how we think of products at Postman.

[00:03:47] Now, if you think about it, the format of a job story might look very familiar if you have ever worked with user stories. However, they don't have much in common other than having "story" in the name. User stories are very dependent on personas, and typically ignore context, situations and anxieties. Have you ever wondered if you're making too many assumptions when you're writing a user story? A lot of times it almost feels like you're retrofitting what you want to build into the reason for building it. Job stories try to eradicate assumptions and guesswork, and instead focus on the things that we do know about the user and what they are trying to achieve.

[00:04:34] In the Jobs to be Done framework, personas play a supporting role in your user research rather than taking center stage. Take the example of someone trying to have a quick meal. If we were to try and understand why Peter chose Snickers for a quick meal, the fact that it takes 30 seconds to stave off 30 minutes of hunger is way more critical to our understanding of the decision than the entire persona of the user, with irrelevant details such as how old they are or what kind of lifestyle they lead. Sure, we can make correlations between the details of the persona and the data around their purchasing patterns, but that alone doesn't tell the complete picture. The entire Jobs to be Done approach boils down to acknowledging that the circumstances are way more important than customer characteristics, product attributes, new technologies or trends, and ensuring that your product development process benefits from that.

Growing from 10 to 300 people

[00:05:39] When I joined Postman in 2015, we were a team of 10 working out of a little apartment in Bangalore. At the time you were either part of the app team or the web team. Fast forward five years to today, and we have almost 300 employees working across several different departments. As the product has evolved, the company has also had to build specialized teams to look at different parts of the product.

[00:06:08] During this phase we mapped the entire growth of the organization based on Conway's law. Very simply put, Conway's law states that organizations design systems which mirror their own communication structures. The inverse of this statement implies that if you want to build an efficient product, you need to start by building efficient communication structures within your organization. And the first step to building efficient communication structures was to have a shared context, or a source of truth, for what you're building.

[00:06:45] One of the big problems we ran into was ensuring that every function of the organization has the exact same idea about your users. A lack of shared context gave rise to different motivations between teams. The classic example would be, let's say, the sign-in screen, where product wants to increase conversions, UX wants to look at accessibility, and brand wants to convey its values. Working in these silos sometimes gave rise to a lot of unnecessary conflicts. We wanted to get to a point where product managers understand emotional context, designers can articulate the value proposition, and developers can empathize with user motivation.

[00:07:32] Every team prides itself on being one that iterates on user feedback, and Postman is no different. We have an open issue tracker on GitHub with more than a thousand issues open, some of them feature requests. We use this and other community forums to hear from our users on what they'd like to get done with Postman. The problem is, when you're talking to millions of users, it's very easy to fall into the trap of listening to the loudest voice in the room. When users voice their opinions on our forums, more often than not they're stating the symptom of their problems, and we want to solve the problem, not the symptom of the problem.

[00:08:18] So we were having all these great conversations with our users and our peers in the industry on what's the hardest part of building and maintaining APIs. But all this qualitative feedback was spread over Zoom recordings, forums and issue trackers, and there was never really a good way of mapping how all this feedback flows back into the product.

Job stories as a point of reference

[00:08:45] That's where the Jobs to be Done framework comes in. We're going to use the simple example I highlighted earlier, of a user sharing a response, to look at how thinking in terms of jobs helped tackle some of these problems.

[00:09:01] First and foremost, we use job stories as a point of reference. Our product managers frame jobs, or tie feedback they've received about the product and pain points they've noticed back to the jobs that users are trying to achieve. This gets written down in specifications, so it acts as a source of truth for what a feature is trying to achieve. All product development at Postman starts with the job, and any documentation that designers or engineers work on also references the exact same jobs, so everyone's pretty much on the same page all the time.

[00:09:40] Its use as a reference doesn't end there either. Job stories have value in all stages of the product life cycle. Even when your product or feature is out in production, you can validate stories based on feedback and testing, and build confidence for any future iteration you might want to do on it.

[00:10:03] Coming back to our example of a user trying to share a specific part of an API response: this job story enabled our product managers and designers to focus on how Postman can help share API responses. While prototyping, we looked for solutions which focused on ease of sharing, and we tested our final prototype on the same. It got us asking the same question over and over again throughout the entire product lifecycle, and not being sidetracked into optimizing for other problems.

Job stories as a knowledge repository

[00:10:37] The second way we use the Jobs to be Done framework is as a knowledge repository about our users. The best way to do this is using a spreadsheet tool such as Airtable to cross-reference our job stories with things like personas that our research team is working on. Feature requests that have come up on GitHub or any other forum also come into the same place, and the actual teams that are working on the feature also get tagged.

[00:11:08] Product managers at Postman use the spreadsheet as a way to search through a set of jobs for those that validate or back their claim for a specification. UX researchers map the same jobs to personas that they're fleshing out, and form correlations and strategies based on the jobs rather than the details of a persona. These validations also act as reinforcements for UX designers to build experiences based on the priority or scores for those jobs.

[00:11:42] Again, coming back to our example: someone at Postman browsing through this job in our knowledge base immediately has access to all the issues related to this job, and all the personas that this workflow is relevant for. For example: "When I'm debugging an API endpoint, I want to point others to a specific API response so that I can highlight any anomalous behavior." A persona that this job is very relevant for is security engineers. When they review your product, they want to identify certain APIs that are slightly too open, which you might want to take a look at for further security enhancements.

[00:12:22] Since this is a living, breathing database, we add more context to it over time, and the entire knowledge base becomes a way for you to explore different personas and features in Postman. From this record I can just click into security engineer, the persona, and then look at all the different jobs that the security engineer persona is related to. On the other hand, I can also click into a particular feature or related issue and see all the other correlations with jobs applicable to that particular item. We use this for new employee onboarding, brainstorming sessions, correlating feature requests, and mapping them to features and solutions.

Job stories as a mediator

[00:13:10] The third way we use job stories at Postman is as a mediator in discussions. We've all had those features and initiatives that drag on for too long and are pretty much stuck in discussions between product, design and engineering. In such cases, we have found that jobs act as a way to facilitate team conversations and steer efforts towards a common goal.

[00:13:39] If a designer asks whether a particular bit of information needs to be available on screen, and they're not particularly inclined to include it since it feels disjointed from the rest of the experience, you can now refer to the job and see if that information is actually relevant in helping users achieve it. If a product manager wants to remove some copy that's taking up too much prominence in a workflow, you can now refer to the job to clarify that the copy is absolutely essential in conveying what the user should do to complete the job. If a developer wants to know if they can skip a particular feature that requires significant engineering effort, the job story can now tell how important that feature is in helping users achieve the job.

[00:14:24] The best example of this in practice at Postman is how our sharing features have evolved over time. We started out by building extensive sharing and invite flows within the product, but after dwelling on the job, we realized that something as simple as letting every part of Postman have a link was enough for users to point to responses. They could then use their own messaging platforms, like Slack, to ping people with the part of the response they wanted them to look at. As a result, Postman took some strong decisions to go web first, and now pretty much everything in the product is accessible through a URL. This increased the overall shareability of data around your APIs, and also the adoption of a lot of features.

How to start using job stories

[00:15:14] Now, if any of these scenarios relate to something that you face at work, you probably want to try out using job stories for the next product you work on. You can do that with three simple steps. You want to start small: introduce Jobs to be Done into your own personal design process. When you're comfortable with that and you're seeing value, try referring to it in conversations, so you can involve your team. Complete the loop by building your database of jobs as you learn more about your users.

[00:15:51] A couple of tips for introducing it into your own process. Start your next feature by writing down some job stories. Keep them in a place where you can add more later, preferably a spreadsheet tool. Circle back on them every now and then. Whenever you have a lingering question or a design decision to be made, ask yourself if it's really helping users achieve the jobs that you wrote down. At Postman we do it for individual features, but also for larger initiatives. Every hunch is articulated by writing down job stories.

[00:16:30] Once you're sold on the idea, involving your team is so much simpler. At Postman we have weekly demo days where we pitch specifications and what we've been working on, and almost all our presentations have a walkthrough of the jobs the specifications help users achieve. This gets a conversation going, and product and engineering folks start trying to compare the jobs you're referring to with the assumptions in their heads. Later on in the life cycle, you can always refer back to these jobs to justify any decisions you might have made. This reinforces the value of the job story, both to yourself and to others in your team.

[00:17:15] And to tie it all together, look at how your existing processes can enrich this library of jobs. At Postman we score jobs. We give them magnitudes based on how much confidence we have in them and how many users they end up affecting. When designers now encounter this job, they can automatically validate what they're building without having to dig through all the research you did to get this confidence.

Pitfalls and summary

[00:17:46] Some of the things you want to avoid on the way, and trust us, we learned it the hard way. Don't get stuck on the semantics. You've got the gist of it: you want to write down the motivations that users have and what they use to achieve those motivations. The more you dwell on the specific format and the presentation, the more tedious writing and maintaining job stories becomes, and you'll find that it isn't being adopted as easily as you thought.

[00:18:21] Jobs is a mindset, and the Jobs to be Done framework just allows you to give it a structure. If you want to keep your users front and center of your work, you need to be constantly thinking about their circumstances and motivations. If you can incorporate it into your formal product process, that's amazing, nothing better than that. But there's a lot of value to be gained even without that.

[00:18:52] So to summarize: if you focus on making your users better at achieving their job, you will automatically build better products. Do that by building a shared context, in the form of job stories, for everyone in your organization. Maintaining that context isn't your job alone. Once everyone sees value in the process, they will automatically start enriching it themselves and start relying on it as a source of truth. Start today; don't wait for it to become a process. Use the Jobs to be Done framework in your own personal design process and communicate its value through your work.

[00:19:37] And that's a wrap, guys. I'm by no means a subject expert on the matter, and everything I've spoken about today is things we've learned from personal experience. You don't need to take my word for it, though, so I've also compiled a list of resources in case you want to read more about the Jobs to be Done framework before diving deeper. We were first introduced to Jobs to be Done through Intercom, and they have some amazing work and resources around their adoption of the framework, so do go check it out.

[00:20:12] Thanks so much for listening, guys. I do hope you find something in here that you can take back into your practice. I'm not very active on social media, unfortunately, but feel free to reach out on Twitter or LinkedIn if you want to continue this conversation. See you guys.