User Story:
"As a product design manager, I want to make sure any JTBD I assign to my researchers and designers has true alignment so they deliver on time as expected."
Context:
After many years of overseeing other researchers and designers, I never anticipated how challenging it would be to create consistent alignment on all the Jobs To Be Done (JTBD) and how long it should take to complete.
Alignment is crucial for rapid iteration and mitigating scope creep.
I'll share some effective strategies I've been recently exploring to improve how I delegate JTBDs more effectively.
My product design leader journey
Initially, when delegating a research or design JTBD, I believed that verbally agreeing over a Zoom call was sufficient to achieve true alignment, as most team members would nod in agreement. We are all on the same team, so everything seemed to "make sense."
Internal innovation:
Recently, as part of an internal innovation exercise at SmarterDx, I've been leading 30-minute mini design thinking workshops to help our researchers, PMs, and design members understand how I leverage Google's Design Sprint methodology.
Discovery:
What I've discovered is that we all have different tactics and definitions of the research and design thinking process which affects the JTBD acceptance criteria. After some reflection, it doesn't really surprise me because there is no one product design approach that is the holy grail.
"In layman's terms, product team members have different definitions of user stories, acceptance criteria, and research methods."
Unlike engineering tickets, which strive to have binary acceptance criteria, early research and design tasks are not so straightforward.
Re-stating the problem:
Given that research and design JTBDs would have a generalized acceptance criteria and/or hypothesis-driven boolean approach, among others, it is more common than not for the JTBD assignee to assume alignment means A while you (JTBD owner) think it is B. If the format of the meeting lacks an agenda, this will definitely happen and will still probably happen even if an agenda exists.
Solution:
When working with your research and design members to refine and delegate JTBDs, instead of verbally communicating what the acceptance criteria (AC) should be, you should spend at least 15 minutes leading by example.
"If delegating a JTBD in which you approve the AC, always assume that you need to show a 0 - 1 example of what a successful AC should be."
When delegating research JTBDs that take place on a Figjam, you as a product design leader need to show that 0-1 example so your team can progress from 1-2 and beyond. We all have different design thinking paths targeting the same goal, but collaboration is blocked when method conflict appears.
Method conflict:
"Method conflict is when each stakeholder uses their own method definition in a design workshop or collaboration meeting, which results in time being wasted on clarifying the method instead of solving the actual problem."
Analysis and Insights
Key Learnings:
Verbal alignment will always lead to disappointment and result in a future meeting where someone says, "I thought we agreed to..." The time spent re-aligning will always be way more than simply showing how it should be done and then writing it down in the ticket. It is also important to ensure everyone agrees with some type of input, such as a happy face or comment to ensure they are actively listening.
For growing teams, assume every research and design JTBD is 0-1, which means you, as the design leader, need to show first and 'do the work' so your team can move from 1-2.
Data-Driven Accountability:
If misalignment still happens, you and your team will be able to go back to your example (data) and visually compare your 0-1 example with their 1-2 example. You will have a very actionable artifact to reference and reflect.
Recommendations for Design Leaders
Best Practices:
- Involve your team in hands-on workshops to ensure alignment.
- Workshop the 0-1 example with them and talk out loud as you complete the example.
- Ensure each member of the meeting provides some type of input to agree on JTBD
- Track and document all alignments and tasks to prevent misunderstandings.
Tools and Resources:
I use Product Discovery for all my ideas, when they are ready to be worked on I send them to my Jira Design board to track and then add all Figjam files to the actual ticket.
Conclusion
Looking Forward:
When delegating a JTBD, I will be focused on dedicating 10-20 minutes to show what I envision 0-1 looks like for acceptance criteria. The meeting format of such an approach will lean toward workshops versus a general discussion.
Let’s discuss in the comments below.
What challenges have you faced
