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.

Paul [00:00:28] Well hey Sean, how are you doing today?

Sean [00:00:29] Doing great, Paul. Excited.

Paul [00:00:32] You know, Michael Sacca was one of my favorite interviews so far. I think somebody listening to this, no matter where they’re at in their career, can learn from the topics that we covered.

Sean [00:00:41] Yeah. It talks about shaping as a key concept for product leaders versus prescribing, which I think is something we can all learn from.

Paul [00:00:48] Yep. We get into the social dynamic of what decisions product managers make and how to succeed, and maybe even more importantly, how products fail, right.

Sean [00:00:59] Yeah, the themes from all of his podcast interviews about why products actually fail. So we have a lot to talk about. There’s a lot of value in this podcast. Buckle up.

Paul [00:01:08] Let’s get into it.

Sean [00:01:08] Let’s do it.

Paul [00:01:13] Well hello product people, we’re excited today to be joined by Michael Sacca. Michael is the V.P. of product at Dribbble, as of the time of this recording acquisition complete of Creative Market. He is also a 15-year product design veteran. He’s been involved with firms like Scholastic, G.E., Nike, Siemens. He’s founded Design Asset Management Software. He is a product leader in the product podcast space, which is a very exciting point of note for us to learn from today. But Michael, welcome to the show. We’re so excited to have you with us today.

Michael [00:01:44] Excited to be here. Thanks for having me.

Paul [00:01:46] Yeah. Welcome. So one of the things I want to jump right in on is I feel my voice on the podcast is in the trenches. I’m the product manager day-to-day and what I want to bring out is one thing that we were just chatting about in-process and how you’ve taken a model that’s sort of showing its age a bit. So Agile has been around. Everybody’s sort of adopted it and we’re starting to find that everybody tweaks it a little bit to make it a little bit different. How have you taken process and shaped it to work for your organization and what can we learn from there?

Michael [00:02:19] Sure, yeah. I came in about a year ago to the product team. I’ve been at Dribbble for three years. I was running the strategy team, I set up the sales team and the marketing team, and then I moved over to the product team. And when I moved over to the product team, we were running kind of Agile-ish. We weren’t pointing, but we were running on kind of a two-week cycle. We’d kick off these large initiatives and we’d just kind of say, “well, I think it’ll take a month,” and it would take six. And no one ever knew why things took as long as they did and we always missed really core components. So we’d get right to the finish line and we’d realize, “well, what about this?” And that would spin us out for another two months. We’re also fully remote, so communication is always an issue. And so I first implemented a kind of a pointing system at least, so that we could start to understand the work that we did. The purpose wasn’t really to have points because I don’t really think points are all that accurate or meaningful. What we wanted to do was go through the process of planning and actually start to plan out the work we’re going to do because if we thought about the work we’re going to do, we would start to catch all those outliers that we weren’t catching for so long.

Michael [00:03:21] And then I was interviewing Ryan Singer and he said something along the lines of, “have you ever finished work in two weeks?” And I was like, “no.” We’re like we’re 10 years old, right, the code base is vast, right, and we have a monolith. So everything takes a long time just because it’s complicated. And it kind of clicked for me that the way to get the team to start to ship more meaningful work and ship faster was to start to time box the other way. So rather than requiring them to tell me how long something’s going to take, we just gave them six weeks to figure out how to ship something meaningful, right. That was kind of the methodology behind Shape Up that really resonated was all of a sudden, now we have six weeks. So we went slow. We were doing like two weeks sprints and then we started to take a week break every other sprint. So we’d do four weeks on and then we’d do a week of what we call kind of like tech debt clean up. And it was OK, we’d really just do more sprint work during it., but it was at least a first step to start to take that bullet break and do some planning. And then we moved to two weeks and then we moved to six-week builds.

Michael [00:04:26] And now we’ve kind of moved away from sprints, right. I think the team still thinks about sprints, but we’re really trying to think of this as really six weeks of work. And if you want to play in two weeks at a time, that’s great, but we’re not going to do the usual agile. We’re not going to stop and do a retro after two weeks. We’re not going to do grooming meetings. We’re not going to do any of that usual Agile stuff because it didn’t give the team context. And so what we found was the team was really unhappy and they were unhappy doing Agile because I was handing them the design assets, we were writing the skills, we were basically telling them what to build and then they would have to go build it. And half the time we’d get it wrong because I’m not deep in the code every day, right. So I don’t know what issues they’re always facing, but we would be very prescriptive in order to get things done fast. And what we did was we started to flip that around where we were just shaping the work and telling them, “this is our goal, this is generally where we want to go, but you’ve got six weeks to figure it out and ship something meaningful.”

Paul [00:05:22] Well sir, I think you just described about my and 90 percent of my peers day-to-day.

Michael [00:05:26] OK.

Paul [00:05:29] That two-week meat grinder does start to wear on teams. And I think that that prescriptive model does start to wear on product managers and I think that there is a lot of missed opportunity. But one thing that I think is key: your title right now is V.P. of Product, right, and you’re the one laying out this vision for the team. When the leadership is expecting a Gantt chart or burn down or quarterly business review and it fits this Agile thing that needs to produce an artifact at the end of it, it makes it much harder. When leadership is aligned on a new way of thinking, it makes it much easier. I think that’s a great thing to call out for any leaders listening to the conversation about what influence they actually have on organizations. It’s not benign, right, it has a big difference.

Michael [00:06:13] It’s true. Yeah, yeah.

Sean [00:06:15] So these changes, have they been impactful?

Michael [00:06:18] Incredibly. So the biggest problem that we faced before was the team didn’t have context, right? They had a ticket, but they didn’t really know why we were doing what we were doing. We’d be doing presentations at our all-hands every week and the team would be explaining the work but sometimes they were just very wrong as to why we were doing what we were doing. And that was a failure on my part, right, was to get them that information. And so now we’re in a process where we do six-week build time, we do one week of hands down planning where we don’t write any code. It’s actually what we’re in the middle of right now. And so that allows us to do any prototyping, to do any additional design exercises, to start to write our tickets and plan and the team actually finishes the scope. So we kind of give them a shaping document and they finalize the scope during this time. And then we do a six-week build and a one week kind of tech debt which is just cleaning up anything, any feature gates, anything that we left from that six weeks of building and start to talk about where we’re going.

Michael [00:07:16] So what we found is that, I mean, one, the team’s a lot happier. They’re a part of the process now, right. They’re not just like a cog in the machine of product. They’re actually part of the planning, of the implementation, and they decide how things are built, what we’re building with, and what scope we’re cutting. So before, everyone was scared to cut scope. Now, you’ve got six weeks, you have to cut scope, right, constantly. So after week two, we start cutting back. “All right, well, we’re behind. We’re not going to get to this. We’ll cut it. It’s not that important anyway.” And so we’ve been able to refine the process to where we’re always, at least in my opinion, building the most important thing and not wasting time on features that probably wouldn’t matter anyway. And so it gave us that chance to cut down the scope, give the team control over what they were building, and then create a more reliable release cycle. And so we just did some quarterly reviews and overwhelmingly, the team has come back and said that they feel more in control of their work. That makes them happier, and that means that we’re going to build a better product when they’re happy with the process that we put in.

Sean [00:08:19] All of the social science tells us that autonomy… Self-determination theory, it’s a core fundamental need if we want to intrinsically motivate people. The more we undermine autonomy by forcing process and forcing people to follow the specific prescription, so to speak, the more we take that away from people and we’re hiring people with a lot of skills.

Michael [00:08:40] Yes.

Sean [00:08:41] So I think it’s even more important at that level, with those level of people, to support that.

Michael [00:08:46] When we were doing like that waterfall Agile, kind of passing off all requirements, we were losing, you know, 70 percent of the capability of the team to actually think, right, and they just became task-doers.

Sean [00:08:59] Automoton.

Michael [00:08:59] Yeah. And that’s not the goal for any of us, right. Like, when you hire a brilliant team, you want to be able to best work together, right. So, yes, it’s been fairly new, about three months, but the results have been really impactful for us and we’ve been able to pull off some really big projects that before would have taken us months to finish.

Sean [00:09:18] Fascinating. So you mentioned a shaping artifact or shaping documents. I like that context. So when these documents come from leadership, you’re calling them shaping, as opposed to, “here’s your ERD or your requirements documents or the prescription,” so to speak.

Michael [00:09:34] Yep.

Sean [00:09:35] I like that distinction. I think that’s cool. Can you talk about that a little more? What’s in that shaping document or that shaping artifact?

Michael [00:09:41] Right. So what we do during the six weeks is our leadership team then basically shapes, as Ryan Singer describes it in the book, we shape the next six weeks of work. And so what we’re producing is kind of either high-level wireframes or designs. And then the general KPIs for the project, the goals and the description of what we want to do, but without the details of how we’re going to do every single step, right. So we’re giving them like the project like we just launched what we call Boosted Shots, which is promoted content, but we left a ton open. We knew that we wanted to promote content on Dribbble. We knew that we wanted to add it to a certain place on the site. But other than that, what is that pacing algorithm? How does the purchase flow work? Even what is the pricing? All of that we can leave up to the team to then figure out during those six weeks and figure out what that implementation is along the way and then they end up writing their own detailed tickets of the technical requirements. So we also don’t have, like engineering managers or people that are writing those kinds of pre-scope tickets. Our engineers take that week to actually write their own tickets, and that way they have the best understanding of what they’re going to build.

Sean [00:10:55] Great answer. I think a lot of our teams could use that distinction as well, this concept of shaping artifacts versus, you know, defacto artifacts. Good contribution. By the way, little plug for Dribbble, we’re a card-carrying member. ITX has been a pro subscriber to Dribbble for a long time.

Michael [00:11:11] Thank you.

Sean [00:11:11] My designers love it. We use it. We put lots of cool, creative things there. As a product leader myself, I’m not a designer. The tool is really for designers and design organizations. But as a product leader, I love when you log in, you ask, “what are you here for?” It’s like the first thing you ask, “what are you here for?” And one of the options is design inspiration.

Michael [00:11:27] Yeah.

Sean [00:11:28] So trolling through your collection of artifacts that you’ve posted on Dribbble, I found a very cool one where you did a poster of Chuck Close and it says, “inspiration is for amateurs.” Do you remember that one?

Michael [00:11:42] Yep. Yep.

Sean [00:11:43] So clearly we need inspiration. And, you know, most of us aren’t so creative that we just can operate perfectly creatively without inspiration, especially, I believe, in the design space. I’d like to get your thoughts on Dribbble as a design inspiration platform, design inspiration in general, and how important it is to building great products.

Michael [00:12:04] Yeah, it’s a bit of a fascinating topic. I won’t go too off-course, but I think it’s essential and I do feel like Dribbble as a whole has really helped to shape the way that products look and feel today. I mean, I do think there’s an argument that you could trace like Slack and kind of the revolution in enterprise software directly back to Dribbble. And you could even trace like the pseudomorphic original iOS designs back to Dribbble, right, and what Dribbble really is is a collection of the evolution of design, right, just like throughout history where you see various styles come about, say in cubism or modernism, right, and you’ve got 10, 15 really famous artists pushing that forward. Today we only remember Picasso, right, but at the time, there was a ton of people riffing with each other to create that style and I believe that’s the same that we see today with software design, illustration, motion design, all happening on Dribbble. So there is this criticism that because Dribbble is so ubiquitous within the design community that you start to get the Dribbbleization of design. But I actually think that this is a very human and natural concept to start to collaborate together and I think what we do is collect that trending information and give it back to the design community.

Michael [00:13:15] So, yeah, we started off as like a way to showcase your work. That’s one of the big criticisms, but I think over time we really have become an inspiration platform. So we think of ourselves more as a search platform, as a discovery platform, and so I think inspiration is incredibly important. I don’t think we’ll give you the answers, but I do think that we can give you that creative spark or that feeling when you get really excited about your idea, right, and you could start to see it come to life. I have that happen so often just browsing Dribbble, watching how people are pushing kind of UI design forward. And I think what we’ve seen in the industry is like even enterprise software now has become fun with Slack and Bonusly and these various other companies that have made their product fun, right, where 10 years ago, enterprise software, most designers didn’t want to work in the space, now they’re excited. They’re some of our biggest companies. I think part of that is in thanks to the Dribbble platform.

Paul [00:14:09] That’s, I think, a great segue into where product management as a whole is looking. So design is one aspect. I was a graphic design major, went back to school for my MBA. I have two legs of the Martin Eriksson Triangle of business, UX, and tech. You’ve added more of a pentagon flavor in your model, including business development and marketing. Marty Cagan has the more ambiguous usable-feasible model. Product management is changing before our eyes, right. Your, if I may be so bold, your conferences and podcasts are doing the shaping in many ways. I think, you know, the voices that you’re bringing together in the interviews and in the collective, I think it’s turned from a cottage industry into a career that people actually aspire to, where most people who’ve been in it for a while kind of found it by accident, now people are seeking it out. So what is it about product management in this moment, in 2020, where we’ve got this collection of talent and business and design that’s coming together? Where do you see the practice in writ large today and where do you see it going forward maybe in the next five years or so?

Michael [00:15:18] Yeah, I mean, there is like the old adage, like the product manager is the CEO of the product. I don’t think we’ve ever really fulfilled that. I think it’s kind of a nicety, you know, but you’re not the CEO of the product. And I don’t think most product managers today really could be. The evolution of product managers came from design in tech, right, with tech at Microsoft, and design through the ad agencies is really where this position evolved. But what we’re missing is that business component. And that’s where I think product managers, moving forward, will have more of an impact is being that business voice. I know a lot of the people that we interview have great organizational skills, they have great project management skills, but oftentimes we are missing that big picture business component that the CEO brings. And I think if we want to fulfill the promise of being the CEO of the product, we have to be able to do sales. We have to be able to understand marketing. And [name] Taylor had, like the heuristics of a product manager and he had five points. And I think that’s really where we’re moving too because it is a creative position, but yet it actually can be a very boring position as well. And so I think it will attract those people that, more like a CEO, are able to straddle the various entities within an organization, be able to speak at the same level as your V.P. of Engineering, as your Head of Sales, and then being able to adapt that into actual products solutions. I would say oftentimes we kind of follow the lead of either our customers or our internal sales team if you’re a very sales-driven organization. I do see product managers having more creative control and being able to build products that are a little bit more delightful and less rigid in where we were just adding features and features. But I don’t know exactly where the industry is going, but I do think the heuristics of what will make a great product manager are expanding beyond tech and design.

Paul [00:17:09] Yeah, I think one of the things that is becoming more and more clear the longer I’m in this path is the people side of it. We tend to focus on what makes cool design, what’s the bleeding edge tech, how we’re pushing the envelope in those spaces. But really, when it comes down to it, we’re the face of the team. The team looks to us for leadership. And it’s not just in creative leadership or tech leadership, it’s in holding the team together and articulating a vision. And, you know, the longer I’m doing this, I’m finding it’s a people business. It’s not a tech business. It’s about building empathy and building teams and bringing people together.

Michael [00:17:42] Yeah, I like that a lot.

Sean [00:17:43] Have you turned a corner there, Paul?

Michael [00:17:47] There’s a backstory there, isn’t there?

Sean [00:17:48] There is a backstory there. We won’t get into that today. I love how you guys are using the verb around Dribbling, so Dribbbleizing, the Dribbbleization of design.

Michael [00:17:59] It’s been used for us.

Sean [00:18:00] I know, I know. Even at ITX, it’s come up, like in some of the products that we build. Again, going back to this creative inspiration thing, do you feel like that’s actually continuing to happen in the world? Are all products starting to look more and more the same? Is there going to be some more divergence in the future? Where do you see that going?

Michael [00:18:17] I think it’s a constant evolution. I remember when iOS 7 came out and everything went flat, right. And then people thought that was the end of design and we’re not going to need designers anymore because, you know, it’s just boxes and colors. And now we’re seeing, like, neumorphism come back where, you know, you’ve got these… starting to bring in more shape into the design. I think it’s a constant evolution. It’s never stopped changing from, really ever, but, you know, if you look at software design from the 50s to today, it’s never stopped changing. And we reach these plateaus where like, maybe, you know, material design was hot for three years, right, and it feels like forever when you’re designing because you have to work within this framework that society deems as acceptable at that time. But I don’t see this ever really stopping. I think as humans, we’re always looking for something new. And so I think the community will just continue to push forward and there’s people that’ll be on the cutting edge and then there’ll be the rest of us that are taking the best of what is being developed and then actually put it into real-world use. And, you know, for us, building these larger applications, we’re like three or four years behind what the hottest trends on Dribbble are, you know because it takes us a year just to get it into production. But, yeah, I do feel like it’s a constant evolution and I really don’t see an end. I think if material design didn’t kill UI design, then we’ll be OK.

Paul [00:19:39] Well said. I think the way we work is a segue I wanted to get into. It’s a bit time-boxed for where we are at this moment in time and I think the thought on everybody’s mind, at least at the time of this recording, is how do we work together separately? We’re getting into technology that’s been, I won’t say on the fringes because remote work has been a thing for a while, but now everybody is suddenly a remote worker to some extent or another. And I think the way that we’re collaborating now, as an amateur behavioral economics fan, I think there will be fallout from this moment in time for years, whether this virus continues for another month or another year, the way that we’re figuring out how to work together overnight is radical. And I think that we’re going to be seeing changes in the way people work. What are some of the things on your mind about collaboration in general, but maybe some specific thoughts about how you’re seeing changes for better or worse?

Michael [00:20:35] Yeah, I mean, I have been remote for the last six years, right. So this hasn’t affected me as much, right. I think a lot, like at Dribbble we’re in North America. But you do see more importance around, like, the philosophies of remote work. And, you know, we’ve seen some companies that go remote and then they’re turning on everyone’s camera and making sure they’re at work, right, in kind of this Big Brother approach. We’ve found this middle ground between, like asynchronous work of Base Camp and, you know, the synchronous work that naturally happens in an office. So we are all online at the same time. We do have a lot of meetings and conversations. It’s kind of the opposite of the remote work philosophy.

Michael [00:21:14] So I think as more companies come out of an office and into remote, we are going to see more philosophical advancements of how remote work is done. The biggest challenge of remote work is collaboration, right? Remote work is great when everyone’s heads down and they’re building. But what happens is these silos build up really quickly. People go too deep on work in the wrong direction and they spend way too long doing it. And then ideation is really hard. Like even at Dribbble, we still do a yearly product offsite where we bring all the product leaders from our organization together and spend a couple of days basically figuring out, what are the big things we want to accomplish in the next year? That’s really hard to do remotely. You know, it’s hard to sit on a video call for five hours and plan, right. It’s much easier to sit in a house, take breaks, you know, have that side chatter going on. None of that is really possible through our current tooling anyway. And so there are challenges that still really haven’t been figured out, right. We have the tools to do the work, I just don’t know if we yet have the tools to do the work most effectively or as effectively as you can in the office.

Sean [00:22:17] Alright, I’m going to go sideways on you here because I’ve got something that’s been scratching at the back of my head since we talked about doing this podcast with you.

Michael [00:22:24] OK.

Sean [00:22:25] You’re 400 episodes into Rocketship with Mr. Bellsido and company, which is a fabulous contribution to our space. So thank you for that.

Michael [00:22:33] Of course, yeah.

Sean [00:22:35] Honored that you joined us. But I’m a big fan of metadata. So you have a collection of data there in these interviews that you’ve done in these podcasts because it’s largely interview-based. So I’m curious, so have you looked at that, like what are the themes that you’ve seen around… anything?

Michael [00:22:51] Yeah, so around products, we really went deep into product probably three years ago. You know, three years ago, it was all jobs-to-be-done. It was Bob Moesta, it was Clay Christensen, and then the different factions of jobs to be done. There’s actually people who hate Bob Moesta and I had to learn all of that live on podcast, which I didn’t realize. And so there was this research component that was really hot. Now, like whenever we have Ryan Singer in Basecamp on these process ideas, the evolution, I think it’s to what you were speaking to before in that Agile is getting kind of old. And so when we have him on, our downloads explode, right, because he is a really prominent voice that is pushing these really new concepts forward and these concepts that are actually working for people. So the process has been more and more. What I have found is that when we go into any kind of economics, any kind of like sales, any kind of marketing, the community isn’t as interested. And so we’ve as a podcast, you know, made a conscious decision to tell some of those stories. And they haven’t been as popular. Diversity in tech, we did a huge series on that and I think was important for us to do but it really wasn’t as popular as I thought it would be with all the chatter. And so I think we have some work to do there.

Michael [00:24:10] And then, you know, we’ve slowly evolved the show into more of like an editorial show and that has really helped us bring out some of these stories that we wanted to tell. But I’ll be honest, we probably could be a lot bigger than we are if we kept having the big names on, which is really what drives when we’re looking at metadata, that’s what drives the downloads. But we’ve consciously moved away from that and really just focus on the stories that we want to tell. And so we have seen these trends come and go over the years. And in terms of like, everyone was an entrepreneur six years ago and then everyone was a research expert three years ago, today we’re getting more into process and what does it mean to actually be a professional product manager? So we’re interviewing people at Asana, people at Microsoft, about their day-to-day. But yeah, what we’ve found is there is an interest in the role of product management. What I want to do is really expand people to think a little bit bigger and understand the stories that they’re trying to tell with their product and get out of kind of the conference room, if you will. It’s important to listen to your customers, but we do have the opportunity to do something special and I don’t think just listening to the sales team and listening to what your customers want you to build is really the role of a product manager. And so with Rocketship that are trying to tell the stories that are a bit bigger than the day-to-day. And that’s the contribution that we’ve tried to make is to better understand our world around us as product managers.

Sean [00:25:31] From my perspective, and this might seem a little voyeuristic, but one of my favorite series that you had was the Product Failures series.

Michael [00:25:38] Oh, yeah. Yeah.

Sean [00:25:39] And I’m really interested to ask you if you have gone through and looked at any themes in there or any trends. Have you looked at like, what you think is the most common thing to cause a product failure?

Michael [00:25:49] People. It’s all communication, every single time. It’s either the founders don’t have the same vision, it’s the product manager didn’t have the skills to communicate. Every time that there was a misstep, it was always in a, I mean, you could say it’s failure in people, but really what it is is failure in communication, right? It’s that inner office, the inner workings of an organization that cause it to fail. Even like Audible, right, which is a fairly innocent example where they just, you know, they released a version without the night, but their whole office was in New York City. They only hired people that lived and rode the subway to work. And so no one had the experience of being a long haul trucker and having, you know, this, like, blaring device at you all of a sudden because it was so white and they couldn’t even use it because it was blinding to them. They didn’t have the experience of maybe being in a long term relationship and waking up their partner trying to fall asleep at night because all of a sudden this thing is a beacon of light in the bedroom. So they didn’t think through those use cases when they went to redesign, and that’s fairly innocent.

Michael [00:26:49] But then you look at like a cultural issue with American Airlines, right, where as an organization, you don’t talk about things that go wrong. But then when things do go wrong, you fail, you fail to communicate that. So we did that whole episode around 9/11 where they failed to put the emergency codes into their phone system. And so when people were calling in trying to check the status of these flights that had crashed and that their loved ones were deceased, they were being told that the flight was still on the air, which was a complete flip from Delta, who finally, at a leadership level, decided that it’s OK to talk about it in extreme circumstances and so people got the right information when they called in. And those are all organizational and communication issues that we as product managers need to communicate. We need to be that voice, you know, and Blake Bertelli was that when he was working on those phone systems and he was able to get the organization to do the right thing.

Paul [00:27:41] It’s profound. I think that’s a little bit on my heels for that thought and just sort of how powerful the concept is and what kind of influence we have. I do have a question and I want to go back to a couple of minutes ago when you were talking about the themes of the podcast and how you were starting to weave together the stories that you want to tell, right, and how you see people think diversity is important, but it’s not maybe interesting to listen to, or economics and sales is an aspect of product management that’s critical, but it doesn’t get the downloads. So you’re seeing these things that you think are worthy of talking about but don’t get the traction that they need. So you’re shaping it. You’re pushing ahead. It’s sort of the nature-nurture of debate of product management. We can listen to our users all day long, but at the end, we do need to have a vision that we’re pulling people towards and not just reactive robots towards. That brings me to, I think, a deceptively simple question, which is what is innovation? How do you define innovation in this mix?

Michael [00:28:42] Yeah. So innovation, I believe, is simply a milestone in progress. I don’t think we have a lot of big breakthroughs, but I do think we make constant progress. And I think too often we think of, like, we did a whole series on disruption versus innovation, right, and we talked to labs in Toronto, healthcare companies that were doing innovative work, but it’s iterative. You know, it’s slow and it’s iterative and it’s going into work every day and making that progress. And this kind of relates back to that Chuck Close, because that’s what he was referring to, too, was just his quote around, amateur’s need inspiration, essentially, because he just goes into the office and he puts in the work. And I think for many of us, we read this fallacy of innovation as this one singular moment in time that suddenly something new in the world has evolved. But when you dig into those stories, that innovation is all built on top of each other, right. That innovation wouldn’t exist with the people that came before it in that space with those ideas. Much like Dribbble, right, like the designs that you see today wouldn’t exist without the people who posted last month or last year or 10 years ago, because all of those designs are built on top of each other. So I think what we call innovation in the West is simply the marker of a moment in time where we’ve realized things change. But I think the truth is it’s slow, methodical work that does push mankind forward, right, and so with the podcast, we’re not creating innovation by any means. But if we can somehow plant a seed somewhere and slowly move the conversation, eventually, that will be called innovative.

Sean [00:30:18] Great answer, Michael. I really enjoyed that answer. I’m going to use some of that in my future work. I see a large bookshelf behind you so our last question that we ask all of our attendees is, what are you recommending these days in terms of books for product leaders?

Michael [00:30:33] Yeah, I always recommend one book, and that’s The Social History of the Machine Gun and I think it exemplifies what we have control of as product managers, right. So it goes through essentially the evolution of how we got to the machine gun and deadly warfare. At every step, there was a decision to be made to make something deadlier and so it essentially summarizes the work that we do where you’re working for the scope, you’re satisfying the requirements, but was any of it really necessary or good for us? And so I find the book an amazing reminder of the work that we do every day, the choices that we have, and the impact that our work can have. And even though that was innovation, right, every single stage in that was innovative, but was it necessary? Right, and gun rights and all that aside, you know, you can see the level of destruction that we’re able to cause throughout the years as you know, basically World War I, World War II evolved, and the way that we’ve approached that I think is telling of us as humans, as society, but those are all choices and choices that we’ve made. And I think to a lesser extent, we can make the same type choices every day. But I always found that that book makes it incredibly obvious, the impact, negative and positive that our work can have.

Sean [00:31:48] I think it’s important for us to keep our eye as product leaders on the longer-term ball like we are here to make the world a better place through the software products that we produce. And if we see that decisions are being made that are not doing that, they’re causing us to manipulate our users versus inspire our users… That is the prime directive, in my opinion. You know, I’ve never read that book. I haven’t even heard of it. So I’m going to order it and that’s a profound thing to think about. So thank you, Michael.

Michael [00:32:18] You’re welcome. Yes.

Paul [00:32:19] Absolutely. Thanks so much for spending some time with us today, Michael, it’s been a real pleasure just picking your brain, hearing what makes you tick, and getting to know a little bit about where you’re at and where you think things are going.

Michael [00:32:29] Yeah, no thanks so much. This has been great, guys.

Paul [00:32:32] Absolutely.

Sean [00:32:32] Yeah. Thanks for your time, sir.

Paul [00:32:34] Cheers.