An interesting idea from Nathan Kinch on framing product requirements around Jobs To Be Done rather than User Stories. Using Clayton Christensen’s framework of Jobs to Be Done the use of personas is replaced with jobs. Rather than “As a (persona), I want to (task), so that I can (outcome)” the requirement is framed as, “When (job), I want to (task), so I can (outcome)”. After defining the JTBD requirements framework Kinch outlines how a product would be developed using this framework and provides some helpful tactics for presenting the business case.
I’m always interested in articles that have tangible tactics I can use; laddering is the process of interviewing customers to find out what product features are important to them while driving to the users’ emotional benefits. The theory is that people buy with emotions and beliefs and rationalize the features and functional benefits. There are four levels to the ladder: Features > Functional Benefits > Higher Order benefits > Emotional Benefits. A word of caution, do not use the word “why” when asking laddering questions. It is known to put people on the defensive. This method can also be used as a tool to develop marketing material and articulate the value proposition for customers.
Using situational examples of where testing can go off the rails this article provides good advice to get things moving and back on the fact-finding track. First big tip, make sure your candidate never feels like they are being judged. When there’s a bunch of experts in the room that designed, and are building, the product, make sure they know you really want to learn from them. Only have two people in the room with the interviewee, one note taker and one interviewer. Make sure you test the prototype in several different scenarios including outside the office and offline. Use this pretesting time to practice the interview and tighten up your questions. Paper wireframes will never run out of battery power so have them handy just in case.
Hunter Walk on product management
A conversation with Hunter Walk, former product manager at Second Life and YouTube. One of my big takeaways from this conversation is that as a PM you’re ‘in service’ to the product and its customers for a given time period. Like every professional coach there will come a time when you leave the product and pass it on to someone else. The goal is to pass it on in a better position than you found it. Another key is to understand when it’s time to move on and what staging in a companies growth is right for you. I also appreciated Hunters comments around how PMs don’t need to come from a technical background, and if they all did there might be an issue with the engineers the company is hiring. Also some insightful comments on how a company’s KPIs change as the product matures.