Using JTBD in a B2B setting
It's now about 4 years since I started to think that the "As a ..." user story format wasn't the best starting point for building long running products. One of the things that I found and liked was the jobs story format.
When collecting the data I didn't do proper JTBD interviews as such. But I did extract the info from pre-sales calls, product demos, and talking to users. Plus enriching the collected date with the known strategic goals 15below as motivation , i.e. reduce support overhead.
I have adapted it a bit and marked it up for our dev teams here. But here is an example for a password reset function. Main thing is that as a B2B supplier we have four distinct groups that could appear in the stories.
all the words in bold are entities that have a defined meaning in a glossary, so that we try and get common understanding. So in this example, the clients are senior managers and procurement folks who set "the requirements". The users are people at the same org who actually use the platform to perform "the work". a Person is a real human being that is a uses the system. In this particular story we don't have the client's customers. Who are travellers (we do travel software). These are the people who get the output of the work and take part in two way communication. That's to say they are the users of our public sites and services.
One thing I keep meaning to update is "User wants to log in". This should really be the job they want to do in the system, as no user really wants to log in to sites. But it's pretty generic and could be any one of at least 4 distinct workflows. Think that the format needs an extension to show the different paths needing the same behaviour.
I'm not using any specific tools for this. I am concentrating more on the process of getting the information that I need. Once created the job stories get treated like a high-level epic. So they get stored in ProdPad on roadmap items. Then pushed into JIRA as epics before being broken down into the tasks to deliver the functionality. One aspect that has been important to me is seeing the non-functional requirements. Then and making sure that they are considered in the design. I've never felt comfortable with non-functional requirements being hidden away and treated separately.
Once the feature is delivered, I am then storing them in Confluence. This allows me to use the page history function to track the changes in:
A lot of the guides to using the jobs to be done approach are very biased towards and end consumer. As such they favour B2C environments. As you can see in a B2B, or even B2B2C setting!, I have had to make some slight adjustments. It's more about also helping your client build a business case. How much their customers' needs come in depends on the balance in customer experience vs cost in their business model. So when looking at the data collected, there is another step in linking the needs and pain points of the end customer to the business driver in the client's pain points.
However you use this tool, bear in mind that the story format isn't the most important thing. The aim is that you can share context and the goals of your (potential) users. Frameworks are for finding ways for talking about what's valuable.
The situation
I have adapted it a bit and marked it up for our dev teams here. But here is an example for a password reset function. Main thing is that as a B2B supplier we have four distinct groups that could appear in the stories.
- 15below (us as supplier) as an org,
- our clients,
- their users,
- and the client's customers
all the words in bold are entities that have a defined meaning in a glossary, so that we try and get common understanding. So in this example, the clients are senior managers and procurement folks who set "the requirements". The users are people at the same org who actually use the platform to perform "the work". a Person is a real human being that is a uses the system. In this particular story we don't have the client's customers. Who are travellers (we do travel software). These are the people who get the output of the work and take part in two way communication. That's to say they are the users of our public sites and services.
One thing I keep meaning to update is "User wants to log in". This should really be the job they want to do in the system, as no user really wants to log in to sites. But it's pretty generic and could be any one of at least 4 distinct workflows. Think that the format needs an extension to show the different paths needing the same behaviour.
Tools and support
Once the feature is delivered, I am then storing them in Confluence. This allows me to use the page history function to track the changes in:
- capability,
- constraints (non-functional requirements) and
- the user needs.
B2B and B2B2C differences
A lot of the guides to using the jobs to be done approach are very biased towards and end consumer. As such they favour B2C environments. As you can see in a B2B, or even B2B2C setting!, I have had to make some slight adjustments. It's more about also helping your client build a business case. How much their customers' needs come in depends on the balance in customer experience vs cost in their business model. So when looking at the data collected, there is another step in linking the needs and pain points of the end customer to the business driver in the client's pain points.
However you use this tool, bear in mind that the story format isn't the most important thing. The aim is that you can share context and the goals of your (potential) users. Frameworks are for finding ways for talking about what's valuable.
Comments
Post a Comment