Welcome to the first recording of our Product Momentum Podcast! In this episode, we introduce you to your hosts, Sean Flaherty, EVP of Innovation at ITX Corp., and Joe Hoffend, Director of Product Innovation at ITX Corp. Both Sean and Joe have dedicated the majority of their lives to solving complex technology problems for their clients and will discuss what it means for software products to have momentum in the world, and what it looks like when they do not. The concepts discussed in this episode will be recurring themes in episodes moving forward. We look forward to taking you along this journey of discovering all the possibilities in our digital world to better deliver for your clients.
Read the Transcript:
Sean: [00:00:00] Hi, welcome to the product momentum podcast – a podcast about how to use technology to solve challenging technology problems for your organization. We’ve analyzed thousands of projects and products over the last 20-some odd years and figured out this formula for what it takes to really build software products that have momentum, and we’re going to use this podcast as a forum for teaching people about what we’ve learned.
Sean: [00:00:22] I’m Sean Flaherty. I started innovating with software products at about 11 years old on an 8 bit Commodore VIC 20 computer and I’ve never really stopped. I joined the Navy after high school, studied aviation electronics, I worked on F-14 Tomcats while there, and I even built software for the Navy when I was there. I studied molecular genetics at the University of Rochester but even built software all throughout that career, earned an MBA from the Simon School of Business, and I started working with software professionally in the late ’90s, really during the beginning of the Internet when I figured out how to put the first databases on the web using a product called Microsoft ASP Technologies. Most of my experience, however has come from working in the trenches with my amazing clients, building innovative software products that move, touch, and inspire the world. I’m most fortunate to have the privilege of leading the team that is ITX. We have a passionate team of awesome technologists and artists that inspire me everyday with the magic they produce for our clients.
Joe: [00:01:19] And I’m Joe Hoffend. I’ve been building software for about 18 years. I started out when I was a kid just kind of browsing Angelfire and GeoCities, checking out some of those sites. And that evolved into some startup experience for myself, specifically in the video gaming space. And so I built that up over a number of years with some cofounders and then eventually transitioned to ITX. I’ve been here about 8 to 9 years now. I’ve been a project manager, a scrum master, a team manager, a manager overseeing several teams here, but most recently, I’m the director of product innovation and I have a team of product innovation leads that work with our clients to help them steer the product in terms of the vision, the roadmap, making sure it’s a success in every way. We’re talking to users and delivering ultimately what product users want. I’m the guy who’s walking around the world thinking about how a product can be made better standing at the pump at the gas station wondering what the conversion rate is for if you want a car wash or not, and so that’s just kind of how my mind works.
Joe: [00:02:20] So Sean, since this is a podcast about product momentum, can you just give us a brief introduction of what it is and why we use it?
Sean: [00:02:30] Sure. Well we learned about momentum in high school, right? So it’s part of Isaac Newton Newton’s laws of motion and I’ve found it actually to be an extremely useful analogy in business as well. So essentially, Newton says once things get rolling, they are hard to stop unless they’re acted on by outside forces like friction, for example. Software products and platforms work in a similar way. Once you supply the right inputs and you get them moving forward, they become hard to stop. However, if you don’t pay close attention to the sources of friction that get in your way, they can overcome your progress and they can send you on the wrong course. And if you pay attention to what causes momentum in software products, you can create momentum. You can accelerate momentum and you can accelerate your products and you can actually make real progress in the world with the software products that you’re building. So you create momentum by setting direction with your vision and a roadmap, you inspire the people who are responsible for producing it, and you make sure that they have the right capabilities while reducing the sources of friction that stand in the way of all those things, of realizing that vision that you set. If you work with digital products long enough, you’ll see that there are all kinds of friction slowing the product development down, stalling momentum, and just plain getting in the way. That’s why some projects succeed when some project teams fail. Some are able to produce great products regularly; others get stuck frequently and can’t seem to get them out the door. So we’ve analyzed thousands of products over the years, over the 20-some odd years we’ve been developing them, and we’ve determined that there are four key things you have to have to build it. So Joe, do you want to describe the formula?
Joe: [00:03:58] Sure thing. So it’s encompassing four key topics. And the important thing to note here is that it’s a multiplier effect, so if you’re missing even one, you essentially don’t have any momentum at all. So the formula consists of vision, roadmap, motivation, and capability. And we’re going to touch on each of these real quick and then further episodes are going to dig deeper into each one of those and how to create momentum for each one.
Sean: [00:04:28] I think it’s important to note that multiplicity is important. So, as you have a better vision you get more momentum. As you have more capability, you get more momentum. But if you don’t have any of those things, you don’t get any momentum.
Sean: [00:04:40] Let’s talk about vision real quick. So vision is a clear, executable, comprehensive vision for your product that includes understanding who your customers are, what they care about, and how your software product is going to take them on a journey towards advocacy for your product. A product’s vision includes a comprehensive understanding of your ecosystem and what problems your product is solving for the people in that ecosystem.
Sean: [00:05:07] We’re going to spend a lot of time in this podcast and lots of subsequent episodes talking about the different tools and strategies that we’ve employed for helping to manage and test the product’s vision. But the key here is that when you lack clarity in a product vision, it’s difficult for your team to remain aligned, and when you lose alignment you lose confidence, and when you lose confidence you start to get really inefficient and all kinds of bad things happen in software products. In fact, confusion is what usually ensues when your vision is not clear, and confusion creates friction for your team. So a clear and executable vision for your product will reduce confusion and will help you to kickstart momentum.
Sean: [00:05:40] So we also believe that you can measure the validity of your vision by the ability of your software product to inspire your users and we’re going to talk a lot about that later on when we talk about measurement. So with that, I’m going to turn it over to Joe to talk about roadmap. Why is roadmap, Joe important for momentum?
Joe: [00:05:54] So roadmap is really important because, while the vision, you know, tells a year out, two years out what you’re hoping the product can be, the roadmap is actually how you get the product to be what you want it to be. It’s what you are actually building to accomplish that vision. And that’s really what the key differences here are. The vision is, “what we do we want the product to be?” The roadmap is, “how do we get it to be that?” And so the roadmap is never set in stone. It’s something to revisit really frequently with your team, because if there’s one thing we can always count on in software development, it’s that things change. Things might change in the industry you’re working in. They may change with what your competition is offering. They may change with user feedback you’re collecting.
Joe: [00:06:38] So we want to have a framework for something that can really digest change as well. And so that’s what this momentum formula also consists of, as well as how your general approach to software development should be in your mindset with your team. With the roadmap, we don’t really put specific dates in. We may have targets for when we want a release of a feature, for example. But like I said with change, we know that the breadth of the scope may change, meaning we think of new features we want to build in. The depth may change, meaning within that feature we’re building we want to do some extra bells and whistles for it. But a lot of that is largely unknown when you’re planning the roadmap, so we like to keep high-level and plot things out, generally in three columns, something along the lines of Now, Next, and Later, and we may put a loose range around that as well just for context for the team. Maybe Now equates to within three months, Next could equate to within six months, and Later could mean anything after six months.
Joe: [00:07:38] But the roadmap is also encompassing the backlog when we talk about it here. We rely heavily on having a really well-crafted backlog that’s full of user stories that are clear for the team to work from. You know, they’re groomed well and everyone’s clear on what they are. And we have mechanisms for actually measuring “What what does it mean to have a healthy backlog?” which will also be a future episode. So roadmap overall: you want to know how you’re going to build the product, and then the backlog for day-to-day in your sprints: how to get it done. Sean, do you want to talk to us about motivation now?
Sean: [00:08:18] Yeah. So think about the phrase that comes out of college football about “One team, One dream,” right. When you have a really good vision and you have a really good roadmap that your team actually created together and they’re aligned with, motivation is almost unstoppable, it’s like palpable. And when teams are inspired, when they’re unified and aligned around the vision, they’ll naturally gel and they’ll naturally be more motivated to achieve it. And we’ve found that if teams are not as motivated as you, you’re not going anywhere. It doesn’t matter how good your vision is. You know, your vision is, like I said it’s the true North for your product, and you may all know where you want to go and where the product wants to go, and you may have a really healthy roadmap, but if the team is not motivated you’ll get resistance. They’ll find other things to put in the way, they’ll find other priorities that are more important than getting your product out the door.
Sean: [00:09:09] So the most powerful strategies that we’ve found for companies are those that are created by leadership teams together making sure everyone’s opinions and ideas are considered, even the bad ones. When everyone is aligned on what decisions are made, decisions flow faster, things get done. And alignment, it’s hard to create. It’s hard to really get people motivated, but when you have it, you know, productive conversations increase and organization collaboration, it’s just unbelievable.
Sean: [00:09:37] So motivation is one of those things that we manage tightly and we have tools around “How do you manage it?” and “How do you monitor it?” and “How do you make sure that the team… And when I say the team I don’t mean just the people that are working on the product, I mean everybody that’s involved in the success of that product inside of your organization or if you’re working with a vendor, then in the vendor’s organization as well. Everybody who has a stake in making that product successful is a part of the team and they all need to be motivated in order for us to get real product momentum going.
Sean: [00:10:07] Part of motivation also is having internal alignment for the team around what the goals are for the product, and understanding that the customers, the people that use the product, are the ones that should drive the decisions and drive how we’re stack ranking our backlog. So to speak to Joe’s point and how we’re creating our roadmaps, that’s a critical component to achieving alignment, having the right goals and understanding what problems we’re solving for customers and why we’re solving them. When teams are not aligned, it manifests in resistance or malaise, like I said before. Things get de-prioritized. We need motivation.
Sean: [00:10:43] So we believe we can measure motivation through the activity levels of the team, the sentiment of the team, the growth of the product backlog, and the engagement of the team just through simple and brief surveys and through just monitoring certain things inside of our Jira instances, for example. When your team has clear vision, an executable roadmap, and they’re motivated, the only thing left to create real momentum for your software product is capabilities. So with that I’m going to transition back to you, Joe to discuss capabilities.
Joe: [00:11:11] Thanks. Capability is really kind of a building block at the very most basic level. So capability has three core pieces to it. The first is tools, the second is skills, and the third is funding. So what do I mean by tools? It means basically what does the team need in terms of software tools, hardware tools, whatever the tool may be. What do they need to be able to do their job effectively? So for us, a lot of times that means the team needs a place to put their user stories, so we used Jira. Or maybe the development team wants to track their technical debt, and so we want a to set up sonar and have that running and tracking, because that in turn can actually feed the roadmap and the backlog.
Joe: [00:11:57] But then there’s skills, and skills I’m sure everyone who’s ever worked on software development has seen this. Maybe you don’t have the right people working on the product. And that doesn’t mean it’s a good or a bad thing, or they’re not the right people in general for your company, but we need the right skill sets working on the right product. So if we’ve got a product that thousands or millions of people are going to be using, we need the right experience the support that. We need user experience designers who know how to scale, visually, a product that can support that many people. We need developers and engineers who have the right experience building systems that can scale, that can perform, and are secure and just fundamentally, you know, whether it’s PHP, .NET, whatever it is, they have the right experience on that technology stack so that they can be successful.
Joe: [00:12:44] And then finally with funding, the last but not least. The final portion comes down to, “Do we have the right budget, the right funding, to support this effort?” There’s one thing that we always talk about, you don’t want to think about your software as a project. It’s a product. It’s a product because if you look at any of the projects you’ve built in your past, they have a start date and an end date, and after that you’re not collecting any feedback, you’re not improving it, you’re not maintaining it, and eventually the product dies. We’ve seen it happen over and over again with some of the products that we all love and maybe have tried out before. But overall, this takes knowledge of the team to be able to t-shirt size epochs effectively, which we’ll talk about in an episode, and really understand that software is a reflection of your brand. And that means that you’ve got to put some money behind it.
Joe: [00:13:36] Now that being said, not all software has to cost millions of dollars. You know, we want to talk about iterating and starting somewhere simple so that we can maybe measure some key performance indicators, get some user feedback, and then understand where to take the product next. So all in all for capability and some of the fundamentals before you even start: having the right people, the right tools, and the right funding in place to be successful.
Sean: [00:14:03] Cool. So if we look at this formula, we take it and look at it in a four quadrant sort of a model. On the top of the quadrant, you would put things that are more abstract or strategic, and on the bottom you’d put things that are a little more tactical or concrete, and on the left side of the quadrant you have things that are around the product, and on the right side of the things around the team that are going to build the product. This is what we think are the core four elements in that four quadrant model to really create successful software product momentum.
Sean: [00:14:36] So in the upper left hand quadrant, you’ve got vision. It’s strategic for the product. On the upper right hand quadrant, you’ve got motivation which is strategic for the team, right. So you need a highly motivated team to build out a product vision. Sun Tzu said in The Art of War, “strategy without tactics is the slowest path to victory, but tactics that strategy is that clinking of swords that you hear right before you get defeated, right, as the as the enemy is marching into your camp.” On the bottom half of that four quadrant model, those are the tactics. So you need a roadmap, a strong, healthy road map and a healthy backlog for your product, and you need the capabilities. You need teams with the right swords, the right tools, the right skills to actually achieve the success, to achieve the product momentum that you want to achieve. But when you don’t have things, when things are missing, this is a diagnostic tool that we use, and I’m going to turn it back over to you, Joe, to talk about how we diagnose a product that’s kind of off-track, things aren’t going well.
Joe: [00:15:36] Yeah, so it’s kind of like on the flip side, we talked about vision, roadmap, motivation, and capability. Well with each of those, when you’re missing one, you will see or feel something. So when you’re missing a vision, you see a lot of confusion in the team, or frankly maybe even the users. When you’re missing something, or when your roadmap is not really what it should be, you’re going to be seeing wastes. When you’re not having motivation, you’re going to feel resistance. And when you don’t have the right capability, you’re going to see frustration in folks. So Sean, you were telling us about vision. Tell us more about that confusion aspect.
Sean: [00:16:18] When you lack vision, you get confusion. We’ve all seen this, but what does it actually mean? So, an example of a product that I’ve worked on in the past: it’s a large product with many teams working on it, and the the technology leadership came down with an edict that they need to get off Flash. So everybody walks around chanting “get off Flash, get off Flash,” so we’re building a product to simply get off Flash. Well if you think about that, and you think about what the vision for the product should be, the vision for the product should be to inspire the users that use it, right. And those are two very different visions for the product, two very different true Norths, and you’re going to get very different decisions made, even at the coding level. Even at the coding level for that software product, if your vision is just to get off Flash, you’re going to take the existing product and you’re going to code it up in the new technology, new platform, as quickly as you can to get off Flash, versus building the right product knowing that you’ve got to change the product that’s out there today. You have to learn from what you’ve done in the past and build a product that’s got a proper vision aligned towards making the users, or converting your users into advocates. Does that make sense, Joe?
Joe: [00:17:31] Yeah absolutely. And so on the roadmap side, when you don’t really have a clear roadmap, you’re going to be seeing a lot of wastes. So that can mean you’re releasing features and the user says, “I don’t need this, I don’t want this, I don’t need this, I don’t know what it’s for, the feature provides no value to the business” even, and just overall it’s a huge waste of time and money. And you know, the best road maps are built by just, it’s kind of like a cycle. You talk to users, you talk to the people internally who talk to the users, you get feedback, and you fill in your roadmap. Then you can you can use metrics and data to support all that too.
Joe: [00:18:07] Just to be clear though, a little bit of waste here and there is totally okay and totally natural in software development. We want to be trying new ideas, we want to be trying to push the envelope on what our product is and giving users what they want, but maybe not necessarily how they asked for it. Through talking to many users, we can think about what their ultimate problem is that we want to solve or the job to be done, and then our teams who innovate can figure out the best way to deliver that. But really, the waste you want to avoid is where you’re just building features for the sake of building features, because internally, “We’ve got to get something out, we’ve got to get something out.” But if you’re just guessing what that should be, if you’ve never actually spoken to a user, or talked to a salesperson who talks to users, or a customer service rep, or the people on the front lines who are hearing a lot of feedback day-to day, then you’re really just doing yourself a disservice. It may even be best to just pause at that point and get the right items in the roadmap. So Sean, what do we see with resistance? This is my favorite one, actually, of the four.
Sean: [00:19:14] So resistance is a symptom that you see, Joe, but the actual functional component of momentum that you need is motivation. You need a team to be motivated. If you’ve been in the software product development industry long enough, we’ve all seen teams that are just full of malaise or apathy, they’re resistant to actually getting things done. They just don’t get it done, and you have to ask yourself why. For me, the number one reason that we’ve found why teams are resistant or don’t produce the best quality that they could possibly produce is because they’re not necessarily aligned. And alignment comes from having a solid vision, having a good roadmap. But you don’t know that unless you assess, and sometimes it’s personal, sometimes you just have people that have personal problems in their lives or you have other things. But you have to be monitoring for team motivation in order to overcome the friction, the product momentum friction of resistance. So that’s what we’ve found with resistance. Does that answer your question, Joe?
Joe: [00:20:11] Yeah absolutely. I mean, we talk to folks all the time where they’re supposed to be dedicating a lot of time to a software product, but they just have so many other responsibilities. And that’s the other thing with software development is not only is there change all the time, but it takes a lot of time, it takes a lot of effort, and it takes a lot of focus. So that kind of rolls into capability here. And yet the flip side of it : when you don’t have capability you have frustration. We’ve all heard a team member say “If we could just” or “If I could just” and when we boil it down, maybe someone already knows that maybe they need to take a course to learn a new skill better to be more effective on the project that they’re working on. Or maybe we’re using outdated software that really doesn’t support our way of working anymore.
Joe: [00:20:55] But at the end of the day, we need to have the right budget as well. If management doesn’t see value in the product for some reason yet to fund it further, we have ways to help create a better story around what this product is and maybe the potential it has, and use that as a way to maybe get them to take a chance, to put some funding towards this project and this product and, you know, really see what we can do once we actually talk to users and get some feedback. But one of the things that we see when we either have capability or don’t is that we can look at a team’s velocity, and it’s not the be-all, end-all silver bullet, because they could have a high velocity but be delivering waste like we talked about with a roadmap. But velocity can be a great indicator of if you’re delivering and have a team that’s capable of doing that.
Sean: [00:21:46] Or if you see a reduction in velocity that can be an indication that your team is starting to experience some frustration, or maybe they’re up against something that they don’t have the skills to achieve, right?
Joe: [00:21:58] Yeah , and so with the formula, we’ve got different aspects of it that future podcasts are all going to go into. But really, it’s about starting to raise the red flag here and there and being able to see some of these issues starting to pop up before they get too far, though. That’s the other thing, is when you let a problem fester and just spiral out of control and become a snowball, that’s really when it becomes rather than turning a speedboat, you’re turning the Titanic at that point. So we like to use these diagnostic tools and the momentum formula to catch issues early on and change course.
Sean: [00:22:35] We also use it at the front end of most of the products that we work with to set them up properly. So we’ll workshop our way into making sure that we’ve got a really really good, healthy vision, a strong roadmap for the products, and a motivated team. And then it just becomes a function of filling the right capabilities to get the product momentum kickstarted.
Joe: [00:22:55] Absolutely. And so we will probably do a future episode on what Sprint Zero is, or what Sprint Zero can and should be. But you know, after we do those visioning exercises up front and building a road map, Sprint Zero is where we have a chance to really get the product built and started off on the right foot.