This part – 1 of the article explains situations that arise due to lack of ownership for journey mapping exercises. Who should own them?, why should they be done? Etc.
The part – 2 of the article discusses in depth the Jobs To Be Done vs. User Story Maps – 2
Part-1
While helping clients with Agile transformation, I focus on a few important aspects, which are outlined below:
- Engaging executives, senior management and leaders from the beginning
- Roles and Responsibilities, Events and Ceremonies, The Team, PO and Scrum Master roles
- Helping create happy, high performing, effective teams
- Product mindset and Value delivery – keeping the big picture context and desired outcomes in perspective from beginning to end
It is with respect to this last point #4, I often introduce journey (aka user story) mapping concepts and workshops to the leadership. It is usually received with mixed response, and although, people love the workshop, they need some hand holding to get started onto this. We eventually get the product owners to own this and work with a small group of engineering and design leads to get the high level maps in place, which eventually results into exploring deeper area maps (remember: maps, contain maps, contain maps…) that are owned by individual teams as they try to build a shared understanding for the features or products they are responsible for.
I also saw resistance from Product Owners to drive the creation of journey maps citing that they already created a PRD (Product Requirement Document) and since it’s all clear in their minds, they failed to understand why it is difficult for engineering and design teams to align with their thinking. The engineering team, on the other hand, complained that the product only provides a document or a one-liner explanation for critical items, and they have to interpret the details on their own. The design teams tended to side with engineering in not having a clear understanding of assumptions made by the product team. Moreover, the design team decided to start driving the creation of the JTBD list involving members from engineering and product through discussions.
Let’s distil the issues hidden in the above paragraph:
Firstly, written documents do not create a shared understanding. Writing such documents and making them the basis for alignment is the reason why so many of the products fail to delight the end users and customers, and as such, do not do well in the market. I wrote an article on this: The Problem with Requirement Specification Documents
Secondly, Product Owners not wanting to own creating visual artifacts (JTBD, Journey Mapping, etc.) and being more in the role of a secondary observer/participant is quite puzzling. On inquiring a little, I found that the Product teams had bandwidth issues, were overwhelmed in learning a new concept and lacked belief in new ways of thinking to create a powerful version of their product that would highly differentiate them from their competitor’s offerings. This not only needs coaching to understand the value of such activities, but also a commitment from the product leadership to invest time in them. Thirdly, the product leadership failed to understand why their Product Owners should co-drive the journey maps? I asked a few questions:
They realized that missing POs during such journey mapping activity might not give them the desired outcome they want to see while delivering the product!
Once this was resolved, the product leadership had two asks:
- We really do not understand how to create user story or journey maps; can you help us get started with a hands-on exercise? And,
- We have the same big question again: How is the JTBD (Jobs To Be Done) list different from journey mapping and if they are different, how can we leverage them in journey map creation?
In answer to the first question, I took them through a fun and hands on user story map session. It took around 90 minutes to facilitate this for a big group of 20 people. I have captured this into a 4-minute cartoon video that anyone can find handy.
In answer to the second question: Please read the part 2 of this article Jobs To Be Done vs User Story Maps
Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more
A unique perspective Amit. Just reading through Jobs to be done is tough. I had to go through Clayton, Moesta, Boysen, Strategyn, Alex Klement and other resources to find something actionable. How you mapped this to intent and user story maps provides a good perspective. If you can add “impact mapping” into the mix, I think we can have a good JTBD framework for technology/product management.