Let’s face it: online meetings can be awkward, especially when you don’t know anyone in the video call. You might still be waking up with your first cup of coffee while someone else is bouncing with energy in a later time zone.
How We Align Product Development with Jobs To Be Done at MURAL
Tying customers needs to product features is a challenge for most product and development teams. At MURAL, we try to solve this issue using jobs to be done.
In the past couple of months there has been plenty of discussions about what JTBD is. This led to a surge of different approaches on how to apply jobs to be done to build new features and products. At MURAL, we’ve experimented with the different methods and arrived at an approach that directly ties JTBD to product development.
In a nutshell, we use personas, scenarios and a job map to anchor customer needs. This provides the global context for all possible customer opportunities. Then, we generate job stories for each local project or feature.
The process is not perfectly linear, but we tend to follow these steps consistently. By anchoring customer jobs to be done both globally and locally, we are confident that what we develop is related to a real identified need.
Here’s how we do it.
STEP 1: Create a job map
One of the most important stages of our planning process is to review and find missing gaps in our persona scenario. For each persona we map out all of the identified scenarios. (See Alan Cooper’s book: About Face for more on both personas and scenarios).
We found that we could actually combine scenarios with job maps and desired outcomes in a single artifact. A job map is a specific technique developed by Tony Ulwick over the last 25 years. It shows the overall process for getting a job done from the customer’s perspective.
The scenarios provide the basis for the flow in the job map, and give us detail around what would the ideal flow be. We then map desired outcomes to each step. Desired outcomes are short statements that indicate the customer’s success criteria for each job they are doing.
Desired outcomes have a normalized format. Consider the examples below:
- Increase the chance that everyone participates in the collaboration
- Reduce the chance that someone gets lost
- Maximize my ability to integrate outcomes into existing documents
We believe that having all these combined gives us a valuable perspective. It also forces us to think about the different problems we can solve and improvements we can make. The job map stands our main product strategy document and guides all decision making at a global level.
Desired outcomes mapped to the Job Map and Scenario
STEP 2: Decide what to build based on JTBD opportunities
The job map helps us decide what to build each quarter. We find opportunities in the job map by looking for unmet customer needs. These opportunities are prioritize and discussed, and eventually guide our decision on what to build.
Product teams at MURAL work in a quarterly cadence. We treat each quarter as a separate project. First, we spend 1 to 2 weeks deciding what we’re going to do that quarter. Then, we execute during the remaining weeks of the quarter.
To help decide what we’re going to work on during the quarter, we also follow a simple planning checklist that we’ve built during the last couple of years. We use this checklist to make sure we don’t miss anything important when planning. In our experience, it’s really important to gather input from not only customers, but internal stakeholders inside our company.
When you put it all together, here’s what it looks like:
Excerpt from planning checklist
We end the planning phase with a backlog of issues, stories, and opportunities we want to work on that will impact positively the product and company goals. Here’s a glimpse of how this artifact looked like Q4 2017:
Current snapshot of Q4 in a mural
We review this mural each week with the product team, not only to track progress and manage interdependencies between platforms, but also to make sure that what we are building is aligned with the goals we defined.
STEP 3: Research the Job
One of the opportunities we decided to pursue this quarter was a task manager integration. We decided to do an integration with GitHub. This integration was aligned with one of our goals: > N Weekly active users who connected an integration. This goal was defined based on of our missing gaps in our Main Scenario. Based on our research, we knew that our users wanted to increase the number of available channels to share the results of an activity and Minimize the time it takes to integrate with Team’s backlog/task manager after a design thinking or agile activity. Also, one our largest customers was using GitHub already.
Whenever we approach a new issue, we go through a design checklist. This checklist is the result of many iterations. It was created in a bottom up fashion. Once a designers start to work on a new issue, they use this document to diverge, discuss, and converge reducing risk along the way. We’ll share the details of the design checklist in another post.
Excerpt from our design checklist
The design phase might take more or less time depending on the complexity and risk of the issue at hand. We normally go through the following phases: research, design, build and test. These phases are repeated as necessary during the design process.
During research, we do secondary and primary research. We dive into our data (we use Metabase with a Redshift instance and Segment), we check research we’ve done in the past, and talk to customer support, success and other stakeholders. The central task during this phase is to interview users. For the GitHub Integration issue, we interviewed 5 people, who gave us valuable insights.
A mural with interview findings
STEP 4: Create Job Stories
From our research we get raw information that we process into Job stories. We’ve found this format really helpful as a way to frame the problems we want to address and how we’ll solve them. We discuss, refine and prioritise these Job stories until we get to the ones we think are most important to solve based on the impact on our users’ goals.
Example Job Stories:
- When I’m looking at GH issues, I want to be able to go back to the original mural for more context so I can understand the problem I’m solving.
- When I’m doing a design workshop in MURAL and we’ve came up with certain action items, I want to easily send them to the issue tracker my team uses, so I can keep working without changing my workflow.
Jobs stories have the advantage of being portable. They include context from the job map without having to refer to the entire map. This gives designers focus on their specific design challenge with the confidence that it directly ties into the overall user experience.
A designer works on these Job Stories. Developers are involved and they give him/her valuable information about the feasibility of the different approaches. The designer diverges and comes up with many draft potential solutions to the issue. The rest of the team provides feedback via MURAL, Slack, or GitHub.
GitHub integration mural
To design this integration, we brainstormed different flows to make as simple as possible to connect MURAL with GitHub. We used MURAL for iOS to do some quick flows and discussed different alternatives with the product team.
Flows in a mural
Once we pick a route, we start to converge. During this process, the designer works with internal and external stakeholders to refine a chosen solution. This normally happens inside a mural.
Discussing design in a mural
or in GitHub…
Devs are involved in key discussions
By following the Design Checklist, we’re able to identify different edge cases. Here’s where we notice how useful this tool is for us.
Edge cases and potential solutions in a mural
Another important part of our design phase is to make sure that the solution is easy to use and understand. To do this, we run multiple usability tests and use different tools make sure that what we will build is clear for our users.
STEP 5: Develop Feature
Once we finish the design phase of an issue, it’s then ready to be developed. There are many cases in which we first implement a reduced version of the feature just to answer a specific question or see how it works. Developers split the issue into many smaller issues to reduce risk. After they’re done working on it, the Product Manager and designer validate that we built what we expected.
Once approved, we do a phased rollout. We first enable the feature just for us, then to a couple of selected workspaces to gather feedback and iterate. Once we’re confident, we release it to every workspace, and announce it. This is a simplification of our development process, as a lot happens before and after we release something new. We’ll write about how we actually build things, learn and iterate in the near future.
JTBD gives us a consistent, normalized approach to understanding what our customers are trying to accomplish. The common language then allows us to tie user needs directly to development efforts.
The effect is that the team is clear on why and what they are working on. Designers can zoom out to see the big picture in the job map or zoom in to see a specific job story. Developers have the comfort that there’s a clear rationale behind product decisions. They can review research and tie job stories into their efforts tracked in GitHub.
In the end, the entire design and development organization is much better aligned. And best of all, we know that our efforts are aligned to what customers really want and value.
Head of Product at MURAL. A lifelong learner, passionate about strategy, productivity and simplicity.
February, 02 2018