When we talk about practicing Agile, hour-to-hour, day-to-day, week-to-week, what we really mean is developing software in general, that's the principal activity of these teams. Let's take a closer look at what we might specifically mean by applying the tools of design or design thinking to the process of developing software. We have this take on continuous design with the double diamond which you may have seen before and these various hypothesis areas. What we're trying to do here is go out, discover what's on our users A list. Test whether our proposition is or isn't in fact better enough than the current alternatives doing this particular job, gratifying this particular habit to then make it investable to go out and build software and deliver highly usable interfaces to these users. How do we do that specifically? Well, if you've been around Agile for a while, you probably heard of the Agile user story and you will see people write these in different ways and that's fine. I prefer the format that you see here. As a persona I want to do something so that I can derive some specific benefit. What that does for us with regard to this framing we have around how we're going to approach continuous design is that on the one hand, it helps zero in on a specific persona. Who are we exactly talking about? What shoes do they wear? Then in practice, do they donate already know how to do this certain thing. It helps us answer a lot of the little but important questions that come up as we're trying to develop a really good focus product. Then it also gives us this clause here, which tells us, why do they want to do this? What underlying proposition, what job to be done to this thread back to and then very specifically, it gives us a point of view on how we test whether a user has accomplished their goal or not. Which is extremely important to pairing that point of view of empathy with creative but also testable solutions. That's a lot of what design is ultimately about. Back when somebody learned about the seamstress or seamster I guess if it's a male sewer. They found out that it's very hard to cut fabric day in and day out and do it precisely. They came up with a sewing scissor. The basic principle foundations, pillars of, if you will, of design or empathy and creativity. We need to make sure that's really directed though. Let's take a look at another example. When I was young and hip, like my students here at Darden, my wife and I we lived in the city and then we got older. We moved to the countryside and we found that we had some mice in the basement. What did we do? Well, I decided I would use design thinking and I learned about these mice from both primary research and secondary sources. I learned some things that are gross. How they get into the house and how to identify those spots because of the greasy residues they leave. Mice urinate as they go. They don't have any bladder control. They prefer the edges of walls. They're very speedy a lot of the time. A regular Tom and Jerry mousetrap like you just saw won't actually catch them. Another myth about mice is that in fact, they tend to prefer peanut butter over cheese as a bait. I applied my design thinking tools and I came up with more focused, testable creative solutions to getting rid of the mice with a minimum of bloodshed and disaster. What I did was I checked and repaired first of all, all the spots where they could be getting into the house. I thought I could use a UV light to track where they had been urinating and never turn on a UV light in a hotel room because it will show you any bodily fluids in the room and it can be quite disturbing. I made sure that I placed the traps on the edges of the walls where I knew the mice were going because of this use of the UV lamp. I found a better mousetrap, but only articulates 90 degrees, so it's a little faster and I use peanut butter instead of cheese. That's what we mean very generally and a little farcically about taking your design tools, understanding your subject, and then applying relevant creativity to them. One of the things that I think is hardest about creating personas and jobs to be done, which are really the anchor point of that, right problem hypothesis, is that you really got to have the desire to know about them and make them more than a set of bullet points. One of the first things that I asked my students about their personas is what kind of shoes would they wear? Because that isn't something that's necessarily going to be pertinent specifically to their software design. But having that vivid, specific, humanized persona, in fact, really does help in practice. So all the little dozens of dozens of questions that you'll have about what you should build for this user and how you might promote it. What I would consider doing is for whatever you're working on right now, just pause and list at least three personas. You don't certainly have to do this, but I like to use this Marry the mom, Susan, the stay-at-home mom, Douglas, the stay-at-home dad, Nathan, the nanny. Think about them and make sure this is critical that you could think of at least three real people that you know or you've met that are this persona. My advice is take a second and give that a try and see how it goes for you. Then what does these personas look like when we pencil them out? Well, in the examples, you'll see that number 1, there's always a screener. What this is is a factual question that tells us whether or not a specific person on the street is or isn't our persona. For example, the screener for an HVAC technician, somebody who fixes heating, ventilation, air conditioning systems might be. How many HVACs did you fix last week? If it's less than two, then maybe they're not really an HVAC technician there a general contractor or something like that. They're not this specific persona we're looking at. Once we have that screener, we often look at, think, see, feel, do. What does our persona think about our area of interests? What is their view of how things are versus how they like them to be? What did they see? How do they get their opinions about these things and perspectives? How does it make them feel? What is the underlying emotional resonance of these activities for them? Then factually, what do they do? How many HVAC do they repair, how much time do they spend on the road? All the facts and figures about what's really specifically the activity cadence with these people. From there, we pair these personas with jobs to be done. The idea is that these are underlying needs, habits, problems, desires, whatever specific word feels most appropriate to your particular item. But these exists independent of our particular proposition. For example, these are the questions that we're asking. What existing job, what existing neater behavior are we fulfilling? Then if this really exists, we should be able to find certain specific alternatives that they're using today. If you can't, that's probably a sign that the job to be done is too specific or too leading and you might need to refactor it. We'll look at some examples. What's nice about this is that ultimately what this gives us is a very testable point of view on how these things fit together. Because what we're asking is we have these certain value propositions, things we're going to do with our product. Are those really better enough at doing these jobs to be done versus the alternatives that we're going to get action on the part of our user customer? Whether that's reading our website, using our enterprise software or downloading and signing up for our app or our service. This leads us to a right problem hypothesis that would look something like this. There's a certain persona. They exist. We've identified them. We can find them. They have these certain jobs to be done where they're using certain alternatives and we have this value proposition that we're going to test, but we believe is better enough than those alternatives at doing this. The most important thing, probably the easiest first-order thing to ask about your right problem hypothesis or hypotheses in general is, what evidence would I see that would falsify this hypothesis? It's one of the hardest things to do. I think in practice in a well-run Agile team is asked at what point do we say this was a bad idea and we discard it and move on to something more promising. It's easy to say those things, but in practice it's hard to be decisive that way. It just takes practice and confidence that it really will help you. Here you can see an example for this example company Enable Quiz about this right problem hypothesis. I just find that this is a good centerpiece to organize your evolving point of view on what you've learned how you empathize essentially with your persona, their jobs to be done, and how you're going to see if the propositions in fact are testable. How you'll thread those forward to user stories, the things you're going to be looking at with your team, hour-to-hour, day-to-day, week-to-week.
