Podcast: Play in new window | Download

Sean [00:00:18] Hi, welcome to the Product Momentum Podcast, a podcast about how to use technology to solve challenging technology problems for your organization.

Sean [00:00:28] Hey, Paul, I’m super excited for this podcast.

Paul [00:00:31] I am, too. Why are you excited?

Sean [00:00:32] Because you can’t put innovation in a room.

Paul [00:00:34] The biggest takeaway is that the way that we think about building products tends to be less about the hypotheses of the people we’re building for and more about checklists and making sure that things get shipped and not necessarily who we’re shipping to.

Sean [00:00:48] Yeah. This guy’s a great storyteller, and he’s working for a company that obviously we’re all very close to in our industry, Jira, at Atlassian. Get ready. Gather around the campfire.

Paul [00:00:59] Let’s get after it.

Paul [00:01:03] Well hello and welcome to the pod. Today we are excited to be joined by Mark Cruth. He’s an Enterprise Solutions Architect with Atlassian. He’s worked with organizations around the world to help improve the connection between the work being done and the goals being pursued with the help of Jira Align. An Agile advocate since 2009, Mark has made it his mission to inject the values and principles of Agile into everything he does. His deep knowledge in Agile product development and team dynamics stems from his diverse experience supporting transformation and value delivery as an Agile coach, scrum master, and product owner across several different industries. Mark, thanks so much for joining us. We really appreciate your insight and we’re excited to dig into your take on how things work in Agile teams.

Mark [00:01:44] Thanks, man. I’m excited to be here. I always like talking about, how do we make products better? And I know, like, our focus today is gonna be a little around storytelling. So we’re gonna tell some stories today, it’ll be awesome.

Paul [00:01:55] Just to jump right in on your tag there. I think we talk about user stories all the time and talking about telling the story of the user in the ways that we articulate feature values and the things that we build, the products we ship. But storytelling is not a verb you hear often in teams. So what’s the difference between these user stories that we work in everyday and storytelling?

Mark [00:02:17] That’s a really good question. And the way I kind of like to think about it is that they’re both on the same plane of existence. It’s just one is like you’re starting to kind of walk and crawl with just a story, like a user story that we know it. But when you’re actually doing storytelling, that’s when you’re starting to get agility. That’s when you’re moving. That’s when you’re actually sprinting down the line. And the reason being is that a story, it tries to get to the thing that really matters and it’s the empathetic, kind of meaningful piece behind the why we’re doing something. You know, as a blank, I want to do blank so that blank. It tries to tell a mini-story. You know, you’ve got a character who is going to be doing something and there’s a reason why they’re going to do it. It’s great. It actually helps build meaning and it’s no longer that requirement that we just had. I can read between the lines now. The difference between the user story and the storytelling is that what you’re doing now is you’re actually starting to explode that. You’re starting to actually talk about this persona, this character you have, and the journeys they go through. A lot of times, you’ll have a mix up of stories, “oh, it’s this kind of user, it’s kind of user.” You may not have a very purposeful, driven, what’s the best way of about that? Like a focus on a particular user. Instead, you’re kind of all over the place.

Mark [00:03:29] Where here in storytelling, we actually need to identify, who’s the character in this case? What’s the experience they’re going through? They’re gonna go through a series of journeys where they’re going to experience problems. How are we solving that? So that’s kind of the way I like to think about user stories and storytelling is that they’re the same nut, but one’s just much more of an engaging, bigger nut to crack.

Paul [00:03:49] So I want to come back to that, but I want to dive deep for a second before we get too much further.

Mark [00:03:53] Yeah, let’s do it.

Paul [00:03:55] You’ve used the term anti-patterns to explode some concepts in some of the slides and talks that I’ve seen and heard. And this concept is important to understand because we start to develop blind spots in our practices. We start to take things for granted. We start to think this is the way it’s always been so this is the way it has to be. What are some anti-patterns that you’ve seen in teams that you’ve worked with that need a second look or might be worth a product manager taking a look at if they exist in their teams and how they can help?

Mark [00:04:26] Well, there’s a couple of things I typically will look for. You know, I think the first one is that all our user stories are focused on the same user. They’re all focused on one, because ultimately, in the end, I think about product development as, a product is a box and at each side of that box we have a different user story, a different perspective from different users going through the journey of using the product. And so if everything’s about the one user, we’re very heavy on one lens. And so for me, I want to ask my product manager, “is that really the only user? Are there any other perspectives we need to take on this?” And so that’s usually one that I’m looking out for as I’m working with a team and even coaching a product owner as they’re going through their process. Another big one I found is, I like to think about as stale personas. A persona that we wrote, you know, a year ago, and, you know, “it’s a really good one. We hired a professional agency to do it for us. It was great. You know, it had a great presentation.” It worked for probably the first couple weeks, maybe couple of months, and then all of a sudden, guess what? The persona started shifting but our persona didn’t. So we kept building for the Ted the Techie, you know, and he just kept having the same requirements. But that’s not reality. And so for me, as a product manager, as a product owner, you have to constantly be reevaluating who your personas are, who that user is. So that’s a big thing I’ve seen that’s really stuck out the industry.

Sean [00:05:43] Yeah. And you got to tell a story to that persona.

Mark [00:05:45] Right? Exactly. And their story is constantly changing because every time you go through and you give them new functionality, you’ve actually modified their story. You modified their narrative now. Now they’re doing something different. You’ve given maybe a different part of the product. Maybe they have a slightly different problem now. And so it’s like, how do you start illuminating that? It’s almost like, you know when we think about like hypothesis-driven development kind of thing where we’re actually taking an idea, we’re testing it, we’re getting feedback and then modifying our approach next time. Same thing happens with things like our personas. We have to be thinking about, “Hey, I made a modification to the behaviors of this user, how does that get reflected back into my persona so that when I think about them the next time, I’m trying to beat the right thing?”

Sean [00:06:27] So products tell a story, features tell a story. Ultimately, I think teams have to tell a story, too, and it’s the context within which we’re all trying to do this product development thing is really important. And we’re struggling with a little bit of that recently, at least I feel like we are… Teaching our teams how to tell their story about why they approached this problem from this perspective and why they’re running this experiment or why these hypotheses are important. And the storytelling thing, I think the timing couldn’t be better.

Mark [00:06:57] And it’s interesting because the whole idea of everybody has a story, whether it be an individual to a team, to a product. And it’s really, oh, what is it? Dan Pink has a book. I think it’s called The Art of Selling. Something to that title, I think, but he talks about it like all our interactions are around how we talk to people, how we sell them on ideas. And honestly, storytelling is part of that and we even, he talks about in that book where as we go through and we have an interaction… We’re having an interaction right now. And it’s how I bring across my ideas. I could just say, “Hey, guess what guys? Storytelling is great. You should do it.” All right. Doesn’t mean you’re going to believe me. That’s it. But if I can tell you, it’s like, “Hey, you know, I’ve actually gone through a couple of different conferences and I actually met somebody who came up to me and actually talked to me about a product that they actually use storytelling for and it had this, this and this that happened when they did it,” you’re much more willing to believe and actually accept that as potential truth because of the fact that you can see the story arc starting to play out.

Mark [00:07:53] They actually talk in storytelling, and one of the most fascinating things that I found going kind of deep into the research here is that when we tell a really powerful story, we can actually convince the listener that that story is actually happening to them. And it has to do with the chemicals in our brains how it works. We have things like oxytocin, which is considered the empathy drug. That thing’s starting to kick. We have dopamine, which is wanting us to listen more. We’ve got oh, I forgot what it is.

Paul [00:08:19] Cortisol? Adrenaline?

Mark [00:08:21] Cortisol, there you go. That’s, I was like, “oh well, there’s one more!” Cortisol, which is our attention-driven drug. And when those things are launching and I’m really engaged in the story, I’m paying attention, when I’m really liking what I’m hearing, so I’m engaged; that dopamine is kicking, and then the one-two punch with the oxytocin saying, “Hey, put yourself in these shoes,” it convinces us that this is something that is happening to us and so it becomes our truth. That’s where a really good story, and that’s why when you hear a good story and you’re like, “that’s that’s really good,” why it sticks with you is because your brain is remembering as though it’s a real-life event. So I kind of went off to a tangent there, but the area I kind of look at when it comes to a team is that like a team is really going, they’re going to have their own story, and it’s how they talk about themselves with their organization, with those folks in products that they’re talking to about who we are and what we do that is going to help them understand how they’re going to build great products. Because if we have a story around who we are and what we do… I think of a team that I worked with that was a document management team, you know, back-end system. Why are people going to care about us? Well, what’s your story? Why do people care about you? Guess what? You are the backbone that brings information to the forefront for your people. If you can tell that story, you just built a lot of meaning into the work you do.

Paul [00:09:34] So I actually want to go a little deeper than this. Can you share an example, you don’t have to name names, but I’m really curious, what does a feature or product start to look like when you have this story-infused team start to play out? Most of the folks listening to this show are digital product managers, they’re on perhaps a scrum team with a backlog and they’re trying to get requirements gathered to ship a feature. And when they’re looking at the platforms that they’re developing in and the UX that they’re building experiences around, they could be in an app that lets you transfer money from your savings to your checking account. They might be renting a car. They might be managing documents. What does a product or a feature start to look like that’s infused with story versus one that’s not? Maybe preferably from an experience that you’ve observed, what does it start to look like in the real world?

Mark [00:10:25] So I worked with a financial organization at one point in my career where we were building an investment product. Probably if you looked at my LinkedIn you’d probably figure it out, but I’m not going to tell you what it is here. But we’re basically building out a brand new product and what we ended up doing was, working with our product owner and our product manager, we used our backlog to kind of help tell the story about how the product was going to evolve. First, you know, our users had to enter into the product and be brought to an experience where they could see their financial assets. All right. How are we showing that? And essentially, we start story mapping that out, shoot, we’re feature mapping that out, you know, we’re going through the top layer and actually talking about, regardless of the work, what are they doing? And so at the very beginning of this, we built out a backlog that was on the backbone of this kind of initial feature, then ultimately some story maps. So feature maps then some story maps came out of it, and then from there, what we’d use is, we actually tagged work with personas to talk about who was coming into the tool at certain points and what their goals were, and then ultimately the flow that that user was going through.

Mark [00:11:26] So, you know, the feature was focused on some of the functionality, but we’d tag things with, essentially, what part of the journey is this on? So if you think of like value stream mapping, in value stream mapping, we go through and we talk about what are the things we do. And then from there, we come back out and say, “how is the systems we’d use support that? We kind of did that with the work. We said, “well, they’re going to go through the process and they’re going to log in and now they’re going to go, and then they’re going to assess their financial situation.” And so, although we had features that might be around, “hey, integrate my different bank accounts,” it was part of the assess my financial success portion of the journey. And so that way for us, we could talk about, where are we investing in the journey? Are we over-investing in certain parts of the journey, are we trying to get them from A to Z in the quickest way possible? But it allowed us to kind of see the lens not just as a backlog, but as essentially a narrative. So if I looked through my backlog, you can see, OK, this is what we’re going through. This is the different steps they’re going to go hit. Those were some of the things that I found that work really well when we applied this idea.

Mark [00:12:29] And to even add onto that again, the aspect of the persona was huge. So to be able to actually have a series of personas, different types of investors who would go in and essentially focus in and say, “Hey, what does Frances Frugal look at?” You know, that kind of thing. You know, it was like, “OK, she’s going to care about something a lot differently, so her value stream, her life cycle, or her story is going to be a little bit different than, you know, someone else that might be going to the product.” So that was actually an early thing in my career that hit me hard in terms of like, wow, this can actually have an impact in terms of the team to understand how the story plays out in the product, and we actually could build a better product that way.

Paul [00:13:08] I love that because it stands diametrically opposed to the ‘if we build it, they will come’ line of thinking. And if you look at so many startups and founders and executives, they’ve got the end-all, be-all take on what features to prioritize and how to build it. And the insight that you gain from telling the story and feature mapping and walking through the empathy of putting yourself in somebody else’s shoes… The two styles of process couldn’t be further from each other. One begins with the end in mind and one starts with a spirit of understanding and trying to figure out the truth.

Mark [00:13:45] It’s a really good way of putting that, you know, with an idea of like one begins with the end in mind. And to me, I kind of look at that, too, and you wonder how many of these startups that could have flourished and be the next, you know, the current Google or, you know, the current Venmo or one of these major products if they knew how to tell that story early on in the process, you know. I think that’s why to me, it’s, even as an entrepreneur, as a product manager, being able to tell that story and take you along goes back to the art of selling with Dan Pink. Being able to walk you through why this is a great idea because you’re right, I could build a really great thing, but it doesn’t mean people will come to it. I have to tell you the story about why you need this thing.

Sean [00:14:27] That’s interesting. So we’ve been experimenting lately with telling stories in a little different way. So historically, we’ve always done these status reports, which I hate. I’ve seen you done some writing about that as well, and some speaking about status reporting. And I think there’s huge potential and I see this trend occurring where if you are a little more thoughtful about the story you’re telling, you could actually maybe record your demos and present them in that way and maybe have a more powerful impact on the entire team and on your stakeholders. What do you think of that?

Mark [00:14:59] I think that’s a huge part. I think this goes back into, particularly when you have multiple teams working together because a lot of products require multiple teams to actually create a meaningful experience. This is why it’s so impactful to me to actually have these multiple teams come together and actually do things like demos together, integrate your work together and actually show that because there’s so many times I go in and I go sit in a team demo, you know, they did a great demo. They showed me what they did, they got some feedback, but I got lost in the forest and I couldn’t step back to see the trees in that kind of case. And the most powerful times I’ve seen aha moments come from product managers and from executives and others is when all of a sudden I’ve brought this team’s work and this team’s work and this team’s work and now I actually can walk through a customer journey. I can walk through a narrative. It’s not just, “Hey, here’s this functionality and oh, here’s this,” it’s, “Hey, I’m Mark, I’m walking through, I’m logging in, this is what I have in mind, oh, I want to try to do this.” “Oh cool, I’ve done that.” “Alright, probably at this point I’d want to do this thing now.” And showing that through a demo, the light bulbs go off. You’re like, “well, would they actually do that?” Or, “oh, they would actually probably do this, too.” And all of a sudden, you start stemming out all these new, potentially better, approaches to do your work. And that goes back into that idea where, you know, as much as teams do a great job, we have to think at more of that systems-level thinking. We have to think as a team of teams and how this product is developing, not just as what this team is doing.

Paul [00:16:23] We’ve started to take a regular approach to, instead of demos, having a more rigorous two-way dialog, almost like a testing blitz, where it’s not just the developer or product owner demonstrating what they built, but having a group session trying to bang away at this feature that’s been shipped and saying, “this looks a little bit different than I was expecting” or, “I found this typo over here and I wanted to take a look at that and there was a drop-down menu that could maybe be turned into something else,” and I think having a more dynamic, two-way dialog approach to the demo has added a lot of value. It’s impractical to do all the time, but I think for teams looking for a way to reengage that story-level, hypothesis-driven approach, I think it’s an interesting way to take a crack at demos.

Mark [00:17:06] One of the things I kind of go back to, so part of my background comes from user testing, usability, and one of the things I found that I’ve been able to integrate throughout my career from that is, one of the biggest emphasis items that you put in when you’re doing using user testing is around things like prototyping and user experience testing where you take them through a journey through the prototypes. One of the biggest travesties we have out there in product is, even with teams where they’re like, “cool, we’re going to do something the sprint and we’ll put it out there,” we still hold the cards close to our vest. We still say, “OK, I’ll show it to you when we’re done.” We should be rapidly prototyping and having potential users. And if we don’t have potential users, who’s the next closest person? Come in and actually, even as simple as a paper prototype, being able to go through and do that and we found, what we would actually do in like our sprints, we would go through and we would start out a sprint. We’d have these ideas we’re going to work through. We as a team would go out there, get some feedback on the first day or so, we’d be building some things in the background that we knew we’d need, but we’d get some validations from either end-users or we’d get it from our product leadership, the closest folks we could get. And we’d come back and we build it in and then they would have gone through essentially an initial demo where they are doing it, they’re at the keyboard, they’re giving us some feedback, and at the end, they’re doing the same thing with the product.

Mark [00:18:21] Now, these are with some smaller apps that we were able to do this with. But basically, they experienced the demo twice and they were at the driver’s seat. And it had to do with, they got to help define the experience, tell us some things that we didn’t know, and then they got to go back and validate the experience and say, “yeah, yeah, ok I see you listened to me, which is great, and then now I can see how this works.” And that was something that I think is missed so often is this idea of feeling comfortable with like rough prototyping and feeling comfortable being able to start your narrative that way, because ultimately it doesn’t matter the fidelity of the prototype. It matters the story you’re trying to tell to help inform what the next stage will be when you’re doing the work.

Paul [00:18:59] I think one of the things that’s often struck me when we have user research opportunities to participate in is the pool of users who come and then return as the feature is being rolled out will say, “oh, I wanted that map in that corner and now it’s there and now I can just click this and get to the feature that I wanted,” and you start to build advocacy that way. You start to build a user base that’s on the journey with you because they feel like they’re being heard.

Mark [00:19:24] You’re building out a new storyline on it, too, right? Going back to it all…

Paul [00:19:28] Very meta.

Mark [00:19:29] …They now have a story about how, “man, this product, they’re really responsive. They understand.” And guess what, they’re going to tell somebody about it. They’re going to tell somebody.

Sean [00:19:37] Yeah, that’s the goal of every product right there to get to that stage in the relationship, for sure.

Mark [00:19:42] And, you know, one of the interesting things we’ve even tried in the past, too, is, early on, if you’re struggling, guerrilla-based testing is fine. Walk outside. I know it’s a little different nowadays with COVID, you know, it is what it is. But go out and find somebody. “Hey, you got five minutes? I want to walk through something and just see if it makes sense for you. Here, let me tell you the story arc. Do I lose you at any point?” If you do. All right. Cool. I need to think about that. Maybe this user base, may not be a good base. A lot of times we always seek perfection and perfection is the enemy of the good.

Sean [00:20:13] All right. Little sidetrack here. Somewhere I read that you were working on the Quicken Loans product team as a coach.

Mark [00:20:20] I was. I was at Quicken Loans. That was actually the last job I was at before where I am now with Atlassian and I was there as a coach and I also led a team of release train engineers there.

Sean [00:20:29] Big product, big team.

Mark [00:20:31] Very big product, yep. Rocket Mortgage. Right.

Sean [00:20:33] Lot going on there. I went through it and used the product a few years back and I was very impressed with what they were able to accomplish with that product. So I want to hear about your experience there. So with a team that size, with software, with that level of complexity, talk about how storytelling applied there and how you were able to use it and give us some stories there.

Mark [00:20:54] Yeah. Interesting with Quicken, so Quicken, they’re a, you know, technology team. At least while I was there, it was a team of 2000 team members in technology and then you had your product, parts of the organization that came in. So we had a lot of moving parts. And so for us, the biggest thing was we had to figure out how each of the independent teams that contributed to it fit into the greater picture. And this is where, for us, we went through and basically we helped to understand how each one contributed to the whole. Think of like a Rocket Mortgage, you also think of like servicing and different parts of the company. What’s the user story? What’s the user journey through that? And for us, we leveraged things like value stream mapping. That was a really amazing kind of tool that we used across many parts of the organization to help identify what the user journey was, how we fit into it, and then from there, be able to help map people back to say, “Hey, my team contributes to this part of the journey.”.

Mark [00:21:45] Through that, through those different types of mappings, through those different types of conversations, it caused us to be agile. We had to kind of pivot a little bit. You know, our team’s focus changed. But one of the interesting things we started, so we started getting things started there, we, you know, leveraged the scaled Agile framework. I always like to say that that’s scaffolding. You know, one of my friends said, “the day we implement it was the day we start breaking it down because it’s just enough to get us going.” And so when we launched these Agile release trains, and we had 20 plus of these that were launching, the big thing for us that was important was that every train which was organized around aspects of the journey, understood and knew who they were. They knew their story. And so we actually had them each create their own kind of, essentially, canvas talking about who they are, who their customers are, what their mission is, how do they add value.

Mark [00:22:31] And I brought this team up earlier, the documents team, you know, that was one where they were a team that, yeah, they’re at the back end. You get your documents through the servicing side or through the Rocket Mortgage side. You don’t see all the backend stuff that happens with your documents. But for them, they were a major capability, a major part of the value stream, and they redefined themselves. They said, “Hey, you know what, our goal is to be the best in class document provider, you know, in the world.” That’s ultimately what they were shooting for. And they said, you know, if we were our own independent company. And that’s how we’d hold them. It was like, think of yourself if you were your own independent company, what would you sell? How would you sell it? Those sorts of things. And that was how we built so much energy around these teams where they figured out who they were and why they did what they did because once they knew that they could then work with the other companies, the other arcs that were there, to kind of figure out, who are you? What do you do? How do I interact with you? And so I think through helping them kind of define that who they are, you know, what was the value, and really thinking about it, like I said, as their own independent companies, it really helped them figure out how they contributed to the greater whole, which really helped to bring like I said, 2000 technology team members together there.

Paul [00:23:36] Yeah, that myth of the developer is only valuable when their hands are on the keyboard is sort of a corollary to back-end engineers don’t affect the experience. Nobody thinks the back-end engineer effects the experience until the little red circle starts spinning when you’re watching Netflix.

Mark [00:23:52] Why isn’t anything working?

Paul [00:23:54] Right. You know, the theme that I’m hearing throughout our conversation is bringing me back to just how easy it is to fall into the traps of process. You know, your at Atlassian, you’re, you know, in the midst of Jira and the ecosystem around it, and often we spend all day in Jira just looking at how things move through a KanBan board or how many days we have until the sprint is over or any one of a number of metrics that we think are important. But really, it comes back to what is the impact that we’re having on other human beings and how is this going to make them feel or improve their lives? One of the things that I want to ask is just, how can you take a team that’s process-driven and start to weave in elements of hypothesis-driven development? What are some ground floor tactics that a product manager can implement on a team where maybe this isn’t the culture?

Mark [00:24:47] I think one of the easiest things that a product manager can do for a feature or even a product owner for a story at this level is, you know when we implement this thing, what do we expect to have happen? Because we’re doing it for a reason. And it could be we expect to see less errors. We expect to see a little bit more traffic. We just expect to have happier customers because it doesn’t look as cruddy as a Web site. But something like that, like they just have to be able to ask those questions. It’s like, “what do we expect on the other side?” And I typically like to say, try to make it a quantitative measure, try to be like what it is you’re looking for. You know, and it could be something very rudimentary and simple. So that’s part one. Part two is, now, once you’ve done it, follow up and check that. So many times we will even work really hard to define that, but we never follow up, and so the moment we can follow up and see if we had that impact, now go back and say, “Hey, does that change my decisions on anything else we’re just deciding to work on?” Maybe it doesn’t. Awesome. Keep on going. Or maybe it does. Maybe you put a bunch of focus in an area and you’re finding that you thought you were gonna be a boulder in a small pond, but now you’re actually a pebble in a giant ocean. You didn’t make any waves. All right. Should we keep investing there? Should we try something else?

Mark [00:25:55] And so that’s the biggest thing for me is to think, if I’m going to put a feature out there, you know, and usually for me, a feature is something I usually can get out to clients hands within, you know, a couple sprints. If I’m putting it out there, what’s the impact that I think I could have, even something small, and measuring that. So I think that’s the number one thing that I think gets missed all the time because you think, “I’ve got to do all this big, you know, value-driven engineering. I’ve got to go and have this whole process to do validations.” No. If you’re using Jira, add an extra custom field that says, you know, what do I think will happen and just make it required and I have to fill this out. Boom. Now you got it, right. It’s really simple.

Sean [00:26:32] That’s great. I want to take a half a step back and summarize what I heard you say about big teams and teams of teams.

Mark [00:26:39] Yeah.

Sean [00:26:39] Because I think it’s really important, at least for me, to make it a little more concrete and probably for the audience. So when you have broad teams, big teams, what I heard you say is it’s critical to make sure of the total story so that everybody understands, each team understands, what its role is in the broader picture and that each team is hyper-specific and really clear about who they serve. You said there’s some personas.

Mark [00:27:04] Yeah.

Sean [00:27:04] So who they serve, what problems they solve, and you touched on measurement a little bit, but how they know they’re going to be successful.

Mark [00:27:12] Yeah. And that’s kind of some of that bonus stuff that they can do. But even if, like I said, a lot of organizations, if they just figure out, again, I think you put it really well there was around who they serve, and like, why do we exist? You know, if they can figure that out and then be able to walk that story and say, “OK, now how does that fit into the larger organization?” It’s amazing the new ideas that will just start stemming from that because now we’re like, “all right, this is what we’re there for. I’m not just Team A, you know, I’m part of this team of teams or I’m just a single team and this is what I’m doing. This is the value I provide.” And that’s, for me, one of I think the most powerful things is understanding who you are and the character you are in the larger story.

Sean [00:27:53] That’s great. So, Paul, I’m going to flip around and ask you a question. You’ve got a guy who works on a product that you live in just about every day. There’s got to be something you’re dying to ask about Jira.

Paul [00:28:05] Well, I think the questions that are going to come out are more along the lines of, how can we start to look at Jira differently? When I look at backlogs, my default view is often, what’s assigned to me? What are my next actions? What’s the checklist that I have to go through? I would be curious to know, are there any dashboards that you’ve set up or widgets that you’d recommend or any way to look at Jira a little bit differently that you don’t see it as the default project management tool but you see it is the backbone of the story?

Mark [00:28:42] So I’ve got two things I’ll share. So one’s at Jira and then I’m going to take us into another product that I’m closer to it at Atlassian, Jira Align. But within Jira itself, and this is just for me, as in my past lives always been an Atlassian fanboy. I’ve always used, you know, Jira as a product. But one of the big things I do is leverage things like maybe if you’re not leveraging the component field, or maybe you’ll use labels. If you have like value propositions or you have parts of your narrative, like, apply those to the stories. Make sure you understand how that is and that’s really simple. And then from like a reporting perspective, you can use some of these widgets to report back a JQL query that says, “Hey, find everything that we’re doing in this sprint with that label on it,” or, “give me everything based off of this label or this component.” And now I can see, “oh, cool, this is how I’m investing in different areas. I can see my whole story kind of playing out, like, I’m doing a little work here, a little bit work here. I might have a little bit of work in here, but maybe like I want to do more there.”.

Mark [00:29:34] You can start using some of these, I kind of like to think of them as metadata, to kind of flesh out and intentionally tell your story. Because one of the beautiful things about Jira is you can do anything you want in Jira. It’s also one of the downfalls in Jira is you can do anything you want in Jira. And so you just have to be super intentional about it. That’s one of the things I’ve found. Otherwise, I like to describe it as you can have beautiful Christmas lights put up, or you could have this ball of wrangled up Christmas lights that you’ll never get undone. So that would be what I’d say from a Jira perspective. The area I’ve been focused on within Atlassian is something that I really think is cool. I think it really plays into the space, it’s a product called Jira Align. It’s actually a recent acquisition from Atlassian and it used to be a company called Agile Craft. Like I said, as a prior Agile coach, as a scrum master, I knew of that product, but I never had a lot of interactions with it until coming into Atlassian.

Mark [00:30:20] And one of the cool things that it tries to do is it very much focuses on that story. It connects, essentially, the enterprise and what we’re trying to do from a company, not just from a technology organization, but what are we trying to do strategically, like what’s our goals that we have? What’s our objectives? And it will help you essentially connect the dots all the way down to the work that a team member, does basically at a story level. I’m doing this thing and it connects all the way up to this strategic objective of how we’re trying to take on the world. I’m like, “Oh, cool,” and I can see the causality. And I think that’s, for me, one of the biggest things. And actually I do talk about it in my storytelling conversations is that when you want to bring people along with you, you have to show them causation in terms of why an idea is important. And if I can show you that line, it’s not just a, “oh, here’s a story, do it.” It’s a lot more meaningful.

Mark [00:31:10] We even have something where we intentionally built it in where we have what we call our why button, where if you click on it within any of our work items, so everywhere from a story to a feature to an epic to whatever have you, you click on it and you can understand who the parent is, what the business value associated with that is; if you’ve got a size on it, you can understand a little bit about that, but it basically shows you the causation. And if you’re integrating with Jira, we send it into Jira so that, you know, everybody can see what’s the lineage.

Mark [00:31:36] What’s the why?

Mark [00:31:38] Yeah, because exactly that word is so huge. It’s like, well, why are we doing this? Let’s build meaning into it. And that’s where the story comes in. So I’ve really enjoyed working on this product and helping organizations kind of figure out, how do they find their own why and how do they help communicate that to their teams? Even just before joining Atlassian. organizations truly struggle to understand, like we can build the greatest bridge ever, but is it a bridge to nowhere? Like, how do we connect that to our larger ambitions and our objectives? And that’s something where Align has really done a really good job at kind of connecting those pieces together so you can see it all the way down to a team level to your CEO level in an organization.

Paul [00:32:17] I love that. That is I think a great way to weave all these thoughts together. One of the things that I’m reminded of, I forget who said it, but I’ll make sure to credit them in the show notes. But somebody had an addition to their user stories where they said, “as an X, I need to Y, so that Z, and then I’ll know I’m successful when…” And that simple addition of that clause at the end of the user story starts to weave some of the why back into your backlogs and you can start to see, “I’m successful when somebody is able to move money from their check into their savings so that they can pay for their bills,” or whatever.

Mark [00:32:51] Well, it goes right back down to that, like, what’s that one simple thing that a product manager could do to help, you know, move towards that even hypothesis-driven approach? That’s a great little addition you can just throw on there and then it’s like, “Oh, snap. I have to think about that.”

Sean [00:33:07] Neat. Alright Mark, question, how do you define innovation?

Mark [00:33:11] Oooooh. How do I define innovation? Actually, let me tell you this, so I was working in an organization and they were really big on wanting to become innovative. They went and they created an Innovation Lab. Like I remember I was part of that creation process. They were like, “alright, we’re gonna have like a 3D printer in here, we’re gonna have like a robot. It’s going to be great. We’re going to have these cool couches. People are gonna come here and this is where innovation is going to happen.” And I was like, “yeah, this is gonna be awesome. This is all great.” I went and I was printing stuff. I was playing with the drone that was in there. But you want to know how many people actually came to the innovation center? Like a handful. This was an organization where there were a thousand people in this building and they built this innovation hub. But a handful of people came. And it was a really interesting observation because what they were trying to do was they were trying to say, “innovation needs a space. That’s the only place you can innovate.” It’s like, “oh, you go here, you’ll get inspired, you can innovate here,” where instead innovation is actually something that we do all the time. It’s just how much do we allow ourselves to kind of let go of our preconceived notions and think differently. Because thinking differently, to me, that’s innovation. And so whether it be I’m working on a user story or whether I’m going a bar and I’m gonna go talk to some friends, if I think about my situation differently, I’m innovating. I’m thinking outside the box. And so that to me was a big aha moment for me as I saw this organization come and put this innovation lab, thousands of thousands of dollars, and nobody came. Because it goes right back to what we said earlier, you can build it, but they won’t necessarily come because innovation isn’t something you put a room. Innovation is something that we all have to essentially change our mindset to really get into.

Sean [00:34:53] Great answer.

Paul [00:34:54] I’ve heard a couple dozen versions of that question and that answer, and I think that that is the most unique answer so far. I really liked that.

Mark [00:35:02] Oh, there we go. I like that.

Paul [00:35:05] Last question that we like to ask is for a recommendation of a book that you’re reading or have read that you think a product manager should pick up and have in their toolkit.

Mark [00:35:16] I think, for those on the podcast who are listening, I’ve just turned to look at my library because I was just thinking like, “what’s a good one that I’ve just recently gone through?” I’m going to recommend two. I’m going to recommend a book by Chris Voss and it’s one that you’re not going to think is related to product at all: Never Split the Difference. And the reason I think this is such a great book for a product manager is that a lot of times as product managers, we are faced with a lot of different perspectives that we have to aggregate and we have to make sense of, and in Never Split the Difference, Chris Voss was a federal negotiator, you know, worked on terrorists. And it’s funny how a terrorist and a very irate customer can be very similar. And you have to learn how to navigate that in the conversations you have. So you have to be able to understand how you ask the right questions to get them to kind of provide you the right answers. So I highly recommend Never Split the Difference.

Sean [00:36:13] Or the HIPO.

Mark [00:36:14] What was that?

Sean [00:36:14] Or the HIPO, the highest-paid person in the organization.

Mark [00:36:16] Exactly. The highest-paid person, right, and that’s exactly where this book comes into play is with the highest-paid person too. Because if you just have your CIO say, “let’s do this, let’s do this,” is it the right thing to do? Might not be. So how do you talk to them? The other one I would recommend is, let’s see here, Long Story Short, it’s a storytelling book. It’s from a comedian by the name of Margot Leitman. It’s a really great book about, how do you tell stories that actually make an impact? So she’s a comedian who actually turned storyteller. She does storytelling work around the world. And it’s a really funny book, but it’s also a really like raw book. She talks a lot about her life and the things that she’s done. And basically through her storytelling, how she’s able to connect dots. So, you know, bringing in Chris Voss from negotiating tactics and then someone like a Margot Leitman from a storytelling perspective, weaving those two together, you’re going to become a pretty cool, pretty awesome storyteller who can actually make a lot of waves and make a lot of difference.

Sean [00:37:16] Good.

Paul [00:37:17] Bonus question for the super-geeks in the audience: you and I share an enthusiasm for Brandon Sanderson’s writing.

Mark [00:37:24] Oh, my gosh. Right.

Paul [00:37:25] If you were to pick one superpower of any of Brandon Sanderson’s characters, what would it be?

Mark [00:37:30] Oh, boy, it would have to be, you’re putting me on the spot here with this one. I think I would probably pick from, what was it, the Western-ish series? You know what I’m talking about, don’t you? It’s uh….

Paul [00:37:42] Stormlight?

Mark [00:37:43] No, not even Stormlight, it’s the um…

Paul [00:37:45] Oh, Mistborn.

Mark [00:37:45] Mistborn, that’s what it is. I absolutely love the whole alchemy aspect that kind of plays in there. And so I wouldn’t say it’s one particular one skill. It’s been a little bit since I finished reading that one.

Paul [00:37:56] All the medals powers.

Mark [00:37:57] Yes, exactly.

Paul [00:37:57] Very cool.

Mark [00:37:58] All the medals powers. I always thought that was kind of cool. I love Brandon Sanderson from a storyteller perspective. It’s like [inaudible] archives, you know, it’s a huge book. But it’s purposely big because like somebody could write a book that’s half the size and get the same stuff over, but he puts so much detail into the details that he really wants you involved in the book. And I just think he does such a phenomenal job. You know, my only gripe is it takes like forever to get books out of him. It’s like, I think we’re still waiting. I think we’re supposed to get something later this year, another one in the Stormlight series.

Paul [00:38:30] Yep. Yep. Well, Mark, thanks so much for taking the time. We really appreciate your insight. I think it was a very unique take on how to think about the work that we do every day and really, I think, puts a lot more meaning on how we impact the world and the people that we’re trying to help.

Mark [00:38:45] Thank you guys so much for having me. And the thing I’ll leave with here is that, you know, everything we do is about people. Even if we’re doing it on technology, it’s about people, and people think with their hearts, not necessarily their brains. And storytelling, understanding, and empathizing, that’s how we get to their hearts.

Sean [00:39:02] Love it. Anything you want to promote, sir? I will say definitely go out and check out, if you liked what I said about Jira Alight, go out to Atlassian.com, check out Jira Align. You should be able to reach out to somebody to learn a little bit about that. And then as you go out there, there’ll be a couple of events coming out here where we will be talking a little bit about storytelling from my side. So keep an eye out for some articles on that. If you want to add me to LinkedIn, I’ll be posting on there as well as Twitter. My @ sign is @TealMavericks on Twitter. So keep a lookout. I do storytelling workshops. I’m always open to going in and bringing it into an organization and talking a little bit more about how storytelling can help from a product, usability, even a coaching perspective. So just reach out and let me know.

Paul [00:39:44] Excellent. And we’ll link all that out in the show notes too so people can find you and track you down.

Mark [00:39:48] Beautiful.

Paul [00:39:49] Thanks again, Mark. Really appreciate it.

Mark [00:39:51] Cheers, guys. Thanks so much.

Paul [00:39:53] Bye-bye.

Paul [00:39:57] Well, that’s it for today. In line with our goals of transparency in listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get. So please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.