Will Bachman: Hello, Matt. Welcome to the show.
Matt LeMay: Thanks so much, Will. Thanks for having me.
Will Bachman: All right, Matt, I want to start with a question that’s going to reveal my deep ignorance to all my listeners, but nevertheless, it’s been a question I’ve been wanting to ask, and you seem like a perfect person to answer it. Tell me what exactly is a product manager? Okay, you’re laughing at me. That’s fine. I don’t mind.
Matt LeMay: No, I’m not laughing at you because that’s an ignorant question. I’m laughing at you because that’s the question that product managers ask themselves all day every day, but, usually, with more anxiety and occasional crying and screaming behind it.
Matt LeMay: Product management is a really interesting role, in part, because what it is supposed to be on paper and what it inevitably is in practice are two very different things. On paper, a product manager is pretty much what it sounds like, you’re the person who’s managing the execution and ultimately, responsible for the success of a particular product. You could imagine that, to use the G Suite, the formerly Google app suite of products, you have a product manager responsible for Google Docs. You’d have a product manager responsible for Google Sheets. You’d have a product director or a group product manager in charge of the entire suite of apps. Each of those people would be doing things like managing the success metrics for the product, working with the development team to make sure that they’re prioritizing the right work, facilitating or, in some way, taking responsibility for the product roadmap, things like that, which in the abstract, feel like impactful, high status, high authority work.
Matt LeMay: In practice, that’s barely the case. Product managers often have a lot of responsibility, but very little authority, which means that so much of the work they do isn’t around taking ownership and control of things, but rather, facilitating between people who might have different agendas, who might have different visions for success. In real-world organizations, things are never so neat and so linear. Even something as simple as deciding what the success metrics are going to be for a product, in a real-world organization, that can mean resolving, or at least moving forward, amidst competing visions for what the overall goals of the business are. It means working with developers to help them prioritize both the work that they want to do, and that is the most technically plausible and interesting, with the work that you believe is going to be most impactful for the business, which often means working to establish some agreed upon rubric for what success for the business even looks like. It is really, really, really hard work, is the very short answer to that question.
Will Bachman: When we say the word “product manager”, is it usually referring to technology products? Is there a product manager at Procter & Gamble for their next diapers or something, or is that term mostly referred technology project, like you mentioned, G Suite is the first thing that came to mind?
Matt LeMay: Yeah. It’s funny you mentioned that because a lot of people trace the history of the product manager role back to Procter & Gamble, and to people who in the obviously outdated parlance of the time were referred to as the brand man, who was the person who understood, who kept track of all the P&L for the product, and all the different moving parts, and was responsible for managing each of those moving pieces, and keeping things coordinated. The person who would work with the designer working on the box design and would work with the chemist who were formulating the product, the person who was ultimately where the proverbial buck stops for the success or failure of that product and doing whatever needs to happen in order for that product to succeed.
Matt LeMay: The role of product manager has been largely revitalized or re-popularized through the lens of technology. But I think the core challenges for a product manager in terms of managing and directing specialized work towards an agreed upon and well understood set of goals that meet the needs of some kind of end customer are consistent across technology products where the specialized people you’re working with are designers and developers, or consumer products where the specialized people you’re working with are chemists and patent lawyers.
Will Bachman: Okay, fantastic. My next ignorant question of the day is Agile.
Matt LeMay: Yes.
Will Bachman: I hear this term a lot, but I’m not a product manager as you can tell, and I haven’t designed products. Frankly, I can look up the definition of Agile, but you’ve actually written a book, “Agile for Everybody:Creating Fast …
Matt LeMay: Yes, I have.
Will Bachman: … Flexible and Customer-First Organizations”. I want to get into the book and about your consulting, but first, just help me to understand, what is Agile? Give me a little history. What’s that term mean in practice?
Matt LeMay: Sure. Your uncertainty about the term “Agile” is not something I would characterize as a sign of ignorance so much as a sign of the ambiguity out there around that term and what it means. The first time I was told about Agile was when I was working as a product manager, and a leader at my company said, “We’re going to start using Agile, which means that we’ll get twice the work done in half the time.” I remember thinking, “Wow, that’s awesome. I’d love to get twice the work in half the time. Who wouldn’t want that? This Agile thing must be really great.”
Matt LeMay: I looked it up in Wikipedia, as you do when some new concept that is critical to your success at work is introduced. There were all these ideas of self-organizing teams, iterative development. I was like, “All right, those all sound like they’re good things, but I also don’t know what those things mean.” It’s a very classic circular Wikipedia definition problem of one term that you don’t understand is defined by lots of other terms that you don’t understand. Then when you look up, “All right, what is iterative development,” it says, “Iterative development is how Agile teams work.” But I just was looking at Agile teams. What do I do?”
Matt LeMay: This is a bit of an aside, but one of the informal success metrics I use for my own writing is Wikipedia is to understanding, which is how many terms you have to look up on Wikipedia before you understand the article. I try to get that down to zero wherever I can [crosstalk 00:06:35].
Will Bachman: That reminds me a little bit, a complete useless aside, but I just read this morning that if ants somehow managed to get walking in a circle, so they’re following their own scent, they can get into ant death spiral and they’ll just stay on that circle.
Matt LeMay: Oh, wow.
Will Bachman: That may be urban myth, but I would be interested to watch that happen. I would, of course, try divert them from the circle and save them from that death spiral.
Matt LeMay: That’s an excellent metaphor for-
Will Bachman: Yeah, for the Wikipedia death spiral definition.
Matt LeMay: … for an alarmingly large number of business issues. Speaking of which, so I was introduced to this idea of Agile as this sort of magical way to get a ton more work done in a ton less time. Looked it up, didn’t really understand it. Some of the developers I worked with at this company were both skeptical and helpful because they had heard this before and had less than an ideal experiences with it. But in the interest of helping me understand those less than ideal experiences, they walked me through what Agile represented on a number of different dimensions. I’ll break this down in terms of how Agile is used colloquially, versus what Agile means historically.
Matt LeMay: Colloquially, Agile generally refers to a way of working in which you’re completing work in smaller complete cycles, as opposed to in multiple, highly planned handoffs. You could imagine Agile if you’re building a website for your customer, if you’re a small business building a website. In a traditional or waterfall approach, you would plan out the entire website, then you’d take that plan and that would be handed off to a design team who would make a design. They would take that design and hand it off to developers who would build that thing and then they would hand it back to the people who initially planned it. They would look at it, see whether it meets their needs, and then they would put it out there in the world. That could take anywhere from three to six months I’d say.
Matt LeMay: In an Agile environment, what you’d do is you’d say all right, we’re going to work in an affixed cadence of small chunks of time. We’re going to work in two week cycles that are often called sprints, or iterations, we’re going to say what can we do in each of these sprints or iterations that will deliver some value to our customers. You might say for example, all right, what are our business needs, what are our customers. The first thing we need to do is make sure that people know that we exist and how to get in touch with us. On our first two weeks we’re just going to put up a splash page which says we exist, email us here, here’s our phone number. In two weeks you’ve done something, you’ve released and launched something which is doing something in the real world to solve your business problems and meet your customer needs.
Matt LeMay: Now you might put that out there and say, “All right, well everyone’s emailing us and nobody’s calling, so for our next two week sprint we’re going to do an email list so that we can start collecting emails and reaching out to potential customers through that”. The upsides of this approach are pretty straightforward in that you are doing something, putting something out there into the market that’s generating value right away. Where people get tripped up is that you don’t have that comfort and safety of having a long-term plan and then executing it to get to that plan.
Matt LeMay: One of the first things that I think when somebody dispatched that to me is well you’re doing all this work like it’s thrown away. You do that splash page then when you build website and getting rid of the splash page you’re doing work that has to be undone in order for you to move forward. That’s understandably stressful for people. In colloquial terms, Agile refers to that approach to working whee you’re working in smaller complete cycles with releases and feedback that are usually structured around a fixed finite cadence as opposed to saying we’re going to do this until it’s done, here’s how long it’s going to take, and here’s what the whole plan it going to look like. That’s one sense of Agile.
Matt LeMay: Historically, Agile is actually a slightly different thing. In 2001 a group of 17 independent software developers who had been working on their own new ways of working, so these are the people who developed methodologies like Scrum, and extreme programming, and Crystal, they decided to get together and figure out what high level principles united their respective approaches to working. This type of word agile had never been used to describe any of these methodologies.
Matt LeMay: Scrum, which is still the most commonly used Agile methodology, existed, but the word Agile wasn’t use to describe it. It was just a new way of working along with all these other new ways of working and the 17 people who developed these new ways of working got together in Utah and said, “What are the principles that actually unite these different methodologies,” because working software developers, they understood that there’s no one right way to do something. Every team, every product, every group of people needs a slightly different approach based on the individuals at play and what they’re actually trying to accomplish. To that end, they wrote a document called the “Manifesto for Agile Software Development” which is often called the “Agile Manifesto”. This is when the term Agile first really came into play to describe these ways of working. The “Manifesto” is a very straightforward document. It’s 68 words. It says, “Individuals and interactions over processes and tools,” putting these out of order, but the other three are “Responding to change over following a plan” “Working software over comprehensive documentation” and “Customer collaboration over contract negotiation”.
Matt LeMay: These are the four ideas that they said, “Look, we’re not going to argue which of our methodologies is best. These are the four principles you really have to follow if you’re understanding what these methodologies are all bout”. What’s fascinating to me is that there’s a huge tension at the heart of this, which is that they are saying right out of the gate individuals and interactions, overprocesses and tools, and responding to change over following a plan. At the same time, there are people and organizations looking to implement this as a concrete finite set of practices. Practices can look a lot like processes in tools when they’re implemented in a way that isn’t respectful of the individual’s practicing them.
Matt LeMay: If you look at Agile very broadly there’s kind of the colloquial way of working definition and then the historical movement based on principles definition. What’s interesting to me is looking at those things systematically and saying the real challenge at the heart of Agile is how do we take ownership of the way that we work, how do we implement practices and new ways of work that will put these high level principles into practice in a way that meets the specific, unique needs of our teams and our customers.
Will Bachman: That’s super helpful. Let’s zoom forward, you were product manager-
Matt LeMay: I was.
Will Bachman: … and then you left that world and-
Matt LeMay: Yes.
Will Bachman: … started doing knowledge work and some consulting-
Matt LeMay: Yes.
Will Bachman: … and then you’ve written this fantastic book “Agile for Everybody”, and you talk about three core principles. Tell me about those principles, maybe tie them to your own knowledge work, and let’s go through them one by one. I’ll start you off, Agile means that we start with our customers. Talk about that one [crosstalk 00:14:20].
Matt LeMay: Yes, thank you.
Will Bachman: Yeah, there we go.
Matt LeMay: If we go back to the “Agile Manifesto”, the “Agile Manifesto” says working software over comprehensive documentation. My suggestion is that what that ultimately means is that we should be doing stuff that delivers immediate value to our customers rather than getting stuck in a lot of intermediate states. Starting with our customers, it’s really challenging because it means we don’t do the work we’ve always done. We don’t go through things in a linear fashion and say we’re going to do an outline, then we’re going to make a plan for what we do with the outline. Then we’re going to do something around that. Then in six months we’re going to show something to our customers.
Matt LeMay: Starting with our customers means understanding of their needs and what will be valuable to them before we start doing any work. For knowledge work this is particularly challenging. The moment I really started to think about this as critical reframing for knowledge workers was thinking about PowerPoint presentations, which for better or worse, is a lot of the day to day work that knowledge workers do. I suspect you’ve probably had this experience. I’ve certainly had this experience where you put together an outline which you know is the way we’re all taught the work in high school. You do an outline for your presentation, you put a lot of text in that outline, you get feedback on the outline. People take a look at the outline, they say it looks great. Then the day before your presentation you go to put it into slides and you realize that you have made a great outline, but a terrible presentation. You wind up with huge blocks of text on the screen and you’re like, “Oh, this is really not going to do well, people aren’t going to like this.” I think the challenge of Agile is to work backwards from the experience we’re creating for our customers, rather than working forwards in a way we think will give us the most control and certainty.
Matt LeMay: What my business partners and I do know is when we have a presentation to do, we will give ourselves an hour, prototype the presentation, then actually deliver the presentation to each other in the room or over video chat before we put together an outline, before we put together a higher level plan, because those higher level plans are not actually the experience we’re delivering. They’re not what the customer sees. They’re not what creates value for the customer in the moment. One of these first and most important ideas behind agile is we want to start with the experience we’re creating for our customers and get as close to that experience, as close to understanding the value that experience creates as quickly as we can. That’s a big shift for knowledge work.
Matt LeMay: One of my favorite interviews I did for the book was with somebody who works with non-profits. She said the problem with a lot of non-profits is they do direct mail. They are really good at optimizing direct mail, but they haven’t opened up a space to find out if that’s even what their customers want. I’ve never met anybody who enjoys receiving direct mail from non-profits, especially when that direct mail looks like it was very expensive to print and leaves you wondering what this non-profit’s even spending its money on. So [crosstalk 00:17:31] part of the challenge-
Will Bachman: Only if they have those little return address labels that are useful that have your name on it.
Matt LeMay: Yes.
Will Bachman: Those are helpful.
Matt LeMay: That would be a great example of starting with your customers. That’s something that actually you could argue adds value for your customers, that’s something they want. You’re solving a problem for them. That’s a great example.
Matt LeMay: One charity recently sent me a letter with I think a nickel attached to it. I was like, “Why would you do this? How expensive must it be to mail a nickel to somebody, but keep that nickel and give it to the people who you’re asking me for money?” There’s all kinds of issues that happen when we become too enamored with our own ideas. I’ve seen this so much in marketing organizations who should be representing the voice of the customer and should be very close to their customers and often are not. They’re much more enamored with their own ability to come up with interesting ideas than they are to openly and furiously learn about customer needs. The first and most important part on any Agile approach is we start with our customers, we understand what their needs are, we understand what’s going to deliver value to them, and then we try to spend as little time as possible in intermediate states that might help us feel like we’re doing things the right way, or having a good time, or doing something interesting and creating a sense of certainty, and get right to that customer value as quickly as we can.
Will Bachman: All right, so let me test that and see if I am understanding how you apply that to knowledge work. The way I was trained, if we’re doing a presentation, what I typically do is ghost out the document. That means not just an outline, but often, sketching out the pages and we don’t have the data obviously yet because it’s the beginning of the project, but sketching out what the chart would look like. This is going to be a bar chart and imagine that it’s going to be going up and down, whatever, and then having the titles of the pages with typically maybe not even text heavy, but more just sketching out almost by hand what the pages are going to look like and then showing that to the client day one, saying here is what we’re targeting for the final presentation, is this the insights that you’re going to want? If we had all this data today would that address what you’re looking for? Is that what you’re talking about or something else?
Matt LeMay: I would describe that as a very Agile approach. What you’re doing is you’re starting with something that you can show to the client and say, “Hey, is this what you had in mind,” an you’re doing that in a way that’s as close to that final experience you’re going to be creating as possible. We’re big fans of sketchy, and prototyping and doing things like that quickly.
Matt LeMay: I think what the … and this gets to some of the other principles, is the Agile intervention here would be to define a very finite period of time as a starting point and to say we’re going to do this in one day, or one hour, or two hours, and then however far we get that’s what we got. Working within those time boxes as opposed to working until we’re “done”. It sounds like that’s kind of already what you’re describing. That, to me, feels like a much more Agile approach than many of the approaches I’ve encountered.
Will Bachman: Oh okay, cool. Mackenzie’s approach is to try to have a day one answer or even a day zero answer where he’s saying, “Hey, you put a gun to our head today. This is our best, current hypothesis of what we’re thinking about,” and then always be iterating off of that. Any kind of time anybody suggests an analysis or is thinking about it to always ask yourself let’s assume that we knew the answer to that, and it came back either A or Z, or it came out either 1 or 100. If we had did that survey and we got the results would we care? What’s the impact going to be? Is that going to change the final answer? If the answer is no [crosstalk 00:21:46] don’t do it or-
Matt LeMay: That makes so much sense, right, because you’re starting with the outcome and so much work that gets done in modern organizations, especially enterprises, is busy work. There’s so much work that gets done that’s not actually driving a decision or leading to an important outcome. It’s work for the sake of doing work and any time you can put those outcomes front and center … When we are developing deliverables we have a practice we used which we developed together based on Agile principles call why, how, prototype, iterate.
Matt LeMay: It sounds very similar to that approach where the first thing you’re doing is figuring out what your high level goals are, what are you actually trying to achieve for the client, and we put those on sticky notes and stick them front and center for everything we do, because it is shockingly easy to lose site of those once you get into executional work. Then and only then, once we’ve defined the outcomes we’re working towards, we define what the deliverables going to look like, which is the how, so how are we going to do this if these are the outcomes we’re pushing towards. In a lot of cases, this has actually led us to not doing presentations at all, which is kind of interesting. Just asking that as a high level question, how do we achieve these goals for our clients.
Matt LeMay: In a lot of cases we’ve proposed things like hour long working session instead of presentations, or sending an email to them rather than doing a whole slide by slide presentation because when you’re laser focused on the outcomes you’re trying to drive you’re letting the execution be an open question. In a lot of cases you realize you actually have a lot less work to do than you thought you did.
Will Bachman: Number two is Agile means that we collaborate early and often. Tell me about that.
Matt LeMay: Yes. Early is really the key word here because one thing that we found, especially in a lot of the enterprises we’ve worked with, is that collaboration only happens very downstream. Folks come up with a strategic plan, they know what they think they want, and then they go to somebody and say, “We’ve made this whole thing, what do you think of it?” That creates what I refer to as a report and critique culture, which is a culture where people report out on work that’s already been done and ask for feedback and critique on it, which is really not helpful, and which I think is part of the reason that so many organizations have trouble seeing the value in collaboration. When you’re only sharing stuff when it’s pretty much finished there’s not actually a lot of opportunity to get value out of collaboration. You’re just showing something to somebody and really looking for a rubber stamp or looking for some kind of validation.
Matt LeMay: There are a number of reasons organizationally why I think this happens. One of them is that teams don’t always have aligned goals. One team might be working towards something, another team might be working towards something else, and there’s legitimate risk involved in trying to involve another team so early that they might redirect your project strategically. In other cases I think it’s just human nature. It’s really hard to show something to somebody when you know it’s unfinished and it kind of looks like garbage and to say yeah, I know this looks like garbage, but are the ideas there, is this getting us to the experience and the outcomes that we want.
Matt LeMay: The idea of collaborating early and often is that you’re not just finishing work in your own team or silo and then handing it off to somebody else, but you’re actually involving people openly and strategically when there’s still opportunity to adjust course. Going back to our why, how, prototype, iterate approach, you involve people when you’re defining your why you involve people when you’re figuring out what your goals are rather than once you’ve actually executed something and you’re trying to get their transactional feedback. This one, I think a lot of organizations that I’ve worked with and that we’ve worked with, when we worked with and had a workshop on these principles this is the one that people always get a little nervous about. One think I hear a lot is collaboration’s fine so long as we’re actually getting work done, which, to me, begs the question well then how are you spending your time collaborating if it’s not getting work done, that’s a real problem. If the time you spend together is time just reporting out and giving feedback on things that have already been done of course you’re not getting value out of it. Changing that culture is really critical and really difficult.
Will Bachman: Can you give me an example, maybe a sanitized example from your client work-
Matt LeMay: Sure.
Will Bachman: … of a case where maybe a team did not collaborate early and then they found out three months later we already did this, or we already disproved this thing, or maybe an example of, alternatively, where different function of groups are collaborating and how they do that? Maybe give one example of each.
Matt LeMay: Sure, I’ll give you an example from my work when I was a product manager because this was a lesson I learned a very hard way. When I was working at Bitly, the analytics and link [inaudible 00:26:56] company, I was responsible for being the product manager, a redesign of our link statistics experience. I had a team I was working with, developers, designers, and we were going to redesign this experience. I said, “All right, let’s go, let’s do this, let’s have something really polished and finished that we can show to our data science time and to our sales team,” because I’m caught in the middle. I want to build credibility. I want my team to look good. I don’t want to go showing something that doesn’t look good, that doesn’t reflect the best capabilities of my design and development team.
Matt LeMay: We built this prototype and I showed it to our data science team like “Voila, look at this awesome thing we did.” One of the data scientists said, “It really bothers me that you’re showing bucketed data with a continuous line.” I blinked a lot, which I often do when people were very smart talk about things that are even remotely mathematical. I was like, “What do you mean?” He said, “What you’re showing is bucketed data, is clicks per day, but you’re showing it as a continuous line, which makes it look like it’s not bucketed data, that it’s continuous data, which is a different thing.” I was looking at it and I was like, “Oh yeah, that’s a valid concern.”
Matt LeMay: I had that feeling in the pit of my stomach, which I think almost everybody has had that if I had taken care of this two weeks earlier, if I had just shared with somebody, if we had sketched this up just on a piece of paper in 10 minutes, showed it to someone on the data science team before we started doing the executional work we would have gotten out ahead of this. We wouldn’t have wasted two weeks of my team’s time. We wouldn’t have driven a wedge between these different groups. We could have actually done something that not only was better to meet user needs, but better to meet the needs of our team, which brings me to the other big part of this story that’s missing, which is that I designed and developed this without ever talking to our sales team, which in retrospect, was insane. This is one of the things that we’re selling out there on the enterprise side and just because of the way the organization was set up I didn’t involve those people early enough on to even know if this was worth doing.
Matt LeMay: This was something that came down as we should redesign this, great, let’s go do this. But there was no sense of prioritizing against real customer need, which also speaks to how these principles tie into each other, that when you’re starting with your customers you should never go and do something just because it seems like a thing to do that will get you credibility and progress within an organization. You should really be looking to understand what your customers need, first and foremost.
Matt LeMay: One of my favorite positive stories about collaborating early and often, which is in the book from Jody Leo, who’s an incredible user experience designer, is about working at a financial services company. I’ve worked with a lot of financial services companies, a lot of pharma companies and they always say the same thing which is, “We’re regulated. We have all these constraints. All our lawyers to everything. You could never understand the pain we go through, how hard it is to try to get anything done.” This financial services company had to basically create the first financial services app for the Apple watch when they didn’t even have an iPhone app yet. They were working to create for a new platform that had no documentation with a team that basically had no experience working in this entire universe, technically.
Matt LeMay: What they wound up doing was they invited the lawyers to sit with them. They were like, “There’s no way we can possibly get this done. If we finish something, ask a lawyer for feedback and then have to go back and redo it.” They actually had the lawyers come down for a couple weeks and sit on the product teams. What they realized was that these lawyers who they had thought of as the people who just say no to everything, they actually had pretty good solutions to these things. If you involve people earlier on, the lawyers, for example, could say, “You can’t do this for these reasons, but you can do this.” If you’re engaging those people early enough to actually adjust course, then what would be that kind of oh no feedback where you realized that X amount of time has been wasted actually becomes really helpful feedback because there’s still an opportunity to fundamentally readjust your plan.
Will Bachman: Let’s talk about number three.
Matt LeMay: Yes.
Will Bachman: Plan for uncertainty, which is almost, almost a code. It’s like-
Matt LeMay: That was-
Will Bachman: Not quite, it’s not one hand clapping, but plan for uncertainty. Talk a little bit about what that means.
Matt LeMay: Sure. Planning for uncertainty, this is an interesting one and this is actually the one that I think is probably the most tactically instructive. I talk about having a regular cadence, that one of the things that’s pretty consent across Agile practices is that rather than saying we’ll work on this until it’s done, you say we’ll work on this for two weeks, for one week, for three weeks, and then we’ll take stock of where we are and what we should do next. This, to me, is where Agile really becomes magical and mystical in a way that you approach it, which is probably why that sounds like a poem, which is that if you tell organizations, or if you think as an independent worker that the world is uncertain, things change, it can start to feel like you’re floating around. Everybody’s out there talking about the world is changing faster than every before, blah, blah, blah, digital, which is true, that’s absolutely true.
Matt LeMay: But the beautiful part at the heart of Agile is that structure actually gives you flexibility. This is a principle that I have applied to my work life too, to just the way I structure my days. I have a checklist at my desk of what I do every morning, when I do it, what I do every afternoon. The beauty of this approach, of having structure, is that it gives you guard rails. It gives you a sense that any investment you make in time, and energy and experimentation has a limit to the amount of cost associated with it.
Matt LeMay: One thing I’ve found taking an Agile approach is that if you know you’re only going to spend two hours working on something, you can work on something a lot weirder. You can get pretty far out there. You can try something without it needing to work in order to justify the time commitment. When you’re dealing with, for example, covering up with workshop ideas.
Matt LeMay: There have been times with my business partners and I where we’re preparing a presentation, we’re like, “Well what if we did this with no slides, what if we just did this all through talking, and facilitation and keeping people’s energy in the room?” With an Agile approach you can say, “All right, let’s spend one hour just trying that and seeing what would happen.” Let’s prototype this for one hour. Worse to worse, we’ve lost an hour, which actually isn’t that bad. You can lose an hour pretty easily. I lose hours looking up cat and bird videos on Instagram every day. If you lose an hour trying an approach that you learn something from it’s not really a lost hour at all. At the heart of Agile in practice, is learning to trust and believe, and this also takes practice and takes time, that if your goal is to be more flexible, more adaptable, which it’s called Agile for a reason, then the way to achieve that practically is often by implementing more structure, not less structure.
Will Bachman: Translate that for me a little bit. Give me an example in the knowledge work space, not in product management, how would you translate that kind of more structure yields more flexibility?
Matt LeMay: When we’re working on big projects for clients and big deliverables, what we will always do, even if we’re just working independently on business develop meetings and stuff we will always have a fixed cadence that we are entirely beholden to. One very specific tactical manifestation of that in knowledge work is running what’s called a time box meeting, which is where you say very specifically that a meeting will end when it is scheduled to end even if it does not achieve its intended outcomes, which sounds insanely counterproductive at first, but in practice what it’s done for us as a small team is changed the way we approach our time. When you’re practicing time boxing what you’re really saying is we will put a fixed cadence in here, this is all we have to work with and whatever we get to at the end is where we are.
Matt LeMay: I’m a huge fan of this. I was actually just in a meeting with some folks we were working with a few weeks ago where we agreed to a one hour time box. Everybody talked a lot, but didn’t get to the end of the meeting, like didn’t get to the conclusion. We called it, we said, “All right, this is whee we’re at.” That’s one example. I don’t think that speaks quite as directly to the planning for uncertainty piece as I’d like to, so I’m trying to think of some other good examples of how that works.
Matt LeMay: One thing that we have gotten in the habit of doing, which is a classic Agile practice, is just a daily check in, or standup, or status meeting. It took me a long time to appreciate and understand these meetings, in part for the reason we talked about, the reporting critique issue, but also because the whole point of having a meeting every day is being able to adjust course every day.
Matt LeMay: The whole point of having a fixed cadence and having this opportunity to change the work is that as new information comes in you actually have a chance to get out ahead of that information when different people are working on different things. When we’re working with marketing teams, for example, that are doing campaigns, a campaign plan can take a long time to execute. Part of the problem is that something will change on one side, which doesn’t make it to other people. Somebody with hear about something else going on somewhere else in the organization. They’re not really talking about it because it’s just moving forward.
Matt LeMay: When you have a plan to actually adjust course every day or every week, to actually look at some of the fundamental assumptions and reevaluate them, it actually makes you much more flexible in the scheme of things. In the absence of structure things just tend to go forward as planned, and when you actually commit to a fixed, regular cadence for adjusting course, then adjusting course becomes possible in a way that it wasn’t before.
Will Bachman: Fantastic. Tell me a little about your consulting practice, Sudden Compass.
Matt LeMay: Sudden Compass is a super exciting thing to be working on, in part because I am so constantly in awe of and am grateful for my business partners. Sunny Bates and Trisha Wong and I are the three principals in Sudden Compass. We came together because we had seen a lot of the same issues from different perspective. Sunny who I know has also appeared on this very podcast, which is awesome, as you know is an expert in human networks and an understanding of networks from a non-transactional perspective. I always say that’s Sunny’s superpower that she doesn’t see the world through transactions, she just sees the world through shared opportunities, which is really amazing, and really rare, and precious and awesome.
Matt LeMay: Trisha Wong she has a background, Trisha Wrong is just the most amazing … She was Sally Ride’s assistant NASA, which I didn’t even know until we’d been working together for like two years. She’s like, “Oh yeah, I used to work with Sally Ride at NASA.” I’m like, “Wait, what?” That’s usually something you lead with when you meet people.
Will Bachman: That’s amazing.
Matt LeMay: Now I get to lead with it for her. She did a lot of work in ethnographic research and bringing what she calls thick data to the world of big data, so helping companies that have become over reliant on quantitative data to understand the value of qualitative data, transforming research functions and large Fortune 500 enterprises. I had been working on this question of how do you take these Agile principles and practices, which are well suited in the sense of product work and apply them to all different kinds of work knowledge, work marketing, et cetera. We came together and basically realized that there’s an awesome opportunity to bring these things together, work within enterprises to change the way that people make decisions and learn about their customers.
Matt LeMay: We created a cross-functional practice, which we call unlock sprints, taking that sprint parlance from Agile, which is really just a time boxed … It’s very Agile and it’s cross-functional which is also very Agile, practice for groups of people to take their business questions and reframe them as human questions, gather the data they need to answer those questions, whether it’s qualitative or quantitative data, analyze that data to get insights, and then put those insights into action quickly. We’ve seen, especially in a lot of marketing and insights functions, there’s just frankly a really [inaudible 00:40:55] lack of direct interaction with qualitative and quantitative data.
Matt LeMay: People rely a lot on vendors, they rely a lot on PowerPoint presentations coming in and being presented very transactionally like you want to learn about your customers. Here’s the 200 page PowerPoint presentation about your customers which is obviously not a great way to feel super inspired about solving problems for people. When we talk about starting with your customers, if your sense of who your customer is and what they care about comes from a 200 page PowerPoint slide that somebody emailed you is not really going to help you very much.
Matt LeMay: What we do is we go into enterprises, usually starting with the marketing and insights function, we bring together a cross-functional group and we lead them through these unlock sprints to rapidly generate and activate insights. It’s so rewarding and so cruel to see what happens when people who’ve been at their desk all day so worried about what their boss told them they should do and when this presentation’s going to happen, and all these very company centric things actually start interacting directly with customers and with customer data. It’s an enormous, magical, beautiful shift that happens and I’m just very grateful and excited to have the opportunity to bring that to people and see that set of Agile principles and practices having an immediate affect on the way that people were to solve customer problems.
Will Bachman: Can you give me an example of what would happen during one of these unlock sprints, is it let’s go out and talk to customers at the mall today, or what would it look like?
Matt LeMay: Sure, I’ll share with you an example of some work we did Procter & Gamble because this is my favorite example of what an unlock sprint can accomplish. Procter & Gamble, huge CPG company based in Ohio, several years ago they were trying to grow their urban audience. They wanted basically more people in urban markets buying Procter & Gamble laundry products. They were struggling with this in part because doing laundry in Cincinnati in a suburban home is very different from doing laundry in a big city.
Will Bachman: I’ll say.
Matt LeMay: Right? It’s an entirely categorically different experience. I used to live in Brooklyn and the laundromats in Brooklyn people would get dressed up to go to the laundromats on Metropolitan Avenue and Williamsburg. It’s was like a pretty happening place. They came to us with this business question, which is how do we grow our market share in urban markets. The first thing we did was we said all right, if you actually want to start with your customers you can’t ask a business centric question. You have to start with a human question because when you start with a business centric question all you see is operational, all you see is what you’ve always done and how to optimize it. We got them to ask this broader question of what does it mean to do laundry in an urban setting, which is a very different question. We found that there’s always a challenge here because you do have to get people to trust that the insights that come out of that when you really do start with your customers it is going to answer your business question, but it’s going to give you an answer you hadn’t already thought of, which is a good thing.
Matt LeMay: That was the first thing we did, then we looked at what the next step would be to acquire the data necessary to answer that question. Now sometimes that is quantitative data, sometimes when you’re asking a human question that best first step is to go to a dashboard, is to go to a spreadsheet, it to go try to figure that out. In this particular case it was very clear that what they needed was qualitative ethnographic research. We put together a cross-functional group from Procter & Gamble, and they came to New York for one week and worked out of a laundromat in Brooklyn, which took some negotiating. Enormous credit goes to Trisha for making this happen.
Matt LeMay: In this particular case, to answer their human question, we acquired qualitative data and then we worked with them to analyze that data and develop some insights. What they found right out of the gate was that doing your own laundry in a city is a point of pride. It’s part of the urban experience that you’re not selling people convenience. Convenience is almost a dirty word when it comes to doing your own laundry in a city. It’s about toughness and pride, I’m going to go to the laundromat and take care of this myself. It’s part of the urban experience. It’s a social experience for people. What they had been doing was selling, “Our is more convenient and here’s a coupon for it,” which was not the right message for that audience at all. What they wound up doing with our help was, in keeping with the theme of collaborating early and often, we brought in all their agency partners very early and said, “You need to change your whole approach to messaging. This is not going to work anymore. Don’t bother creating a whole set of campaign ideas and running them past us so we can tell you that later. Let’s talk about this now and figure out how we can work together to adjust course.” The result of that was very successful for Procter & Gamble. They increased their market share in urban markets by about $300 million.
Matt LeMay: What I love about this example is that it’s not that complicated. One of the things that I really like about the Agile movement, about the ideas behind Agile, is that they’re not that complicated. They’re actually pretty obvious when you think about them. They are common sense in a way, but a lot of our working practices have chosen bureaucracy and hierarchy over common sense. If you want to know about people the idea that you would start by talking to those people is not rocket science, but in most modern organizations it’s not what happens. It’s not the first step that people take, so much of the work we do around unlock sprints is just putting structure, and language, and repeatability and practice around a set of ideas that are completely compatible with human nature and with our wish to talk to people, and interact people, and understand people and solve problems for people. When people start to rediscover that part of themselves and see a way for that to be compatible with their day to day work, it’s just super, super, super cool and super gratifying.
Will Bachman: That really resonates. I served a telecom provider, a small one, a cable provider, and we were trying to look at customer retention, and churn and so forth. Our team asked, this was all the executives sitting around the table, “Who has spoken to an actual customer and asked them why they decided to switch to the competitor,” and nobody had ever spoken to a customer. That’s only for the call center, we don’t talk to customers.
Matt LeMay: I’m so glad you touched on that because that speaks to something, and this to me is the biggest disease affecting modern organizations is that there is usually 10 or 11 levels in the org chart in a large company between the people making decisions and the people talking to customers. Every one of those levels things get sanitized, so it’s not uncommon for a situation where people who are directing and interacting with customers understand the problems really well. They send a PowerPoint presentation to their manager to look at it and say, “Well my boss is going to be kind of pissed off they see this thing, so I’m going to take that.” Their managers will look at it and say, “Well my boss is going to be kind of pissed off if they see this thing, so I’m going to take it out.”
Matt LeMay: By the time it actually gets to organizational decision makers, they’re like what they see is, “Great job boss. Everything’s awesome.” They’re like, “Oh great, well I must be doing a great job.” Then the people who are interacting with customers [inaudible 00:49:14], they say, “Well our leaders don’t understand us because they’re acting as if everything fine.” But in a lot of cases that’s not actually the leader’s fault directly. They’re following along with this chain of command where once things get to them they’ve been sanitized, and gone over and abstracted out so much that there’s no urgency, there’s no empathy anymore. It’s just bonkers to me. It’s bonkers, bonkers, bonkers to me.
Matt LeMay: At Sudden Compass our slogan is that we put customer centricity into practice and that’s because we’ve seen so many organizations that talk such a big game about we put our customers first, we love customers. Every town hall meeting you ever see for any company, the first thing they talk about customer centricity, but then when that very question that you’re describing comes up when it’s like, “All right, well when’s the last time that somebody in a leadership position talked to a customer,” there’s like this blank stare. It’s baffling.
Matt LeMay: There’s a thing I talked about in the book, there are three what I call Laws of Organizational Gravity in the book, which came up a lot through doing the research. It’s basically saying what are the forces that are stopping people from doing this, because the ideas behind Agile aren’t that complicated, they aren’t that esoteric. They should be easy, but they’re not. The first law of organizational gravity in the book is that individuals in an organization will avoid customer facing work if it’s not aligned with their day to day incentives and responsibilities. I used the word “avoid” very pointedly there because as with collaborating early, there is appreciable risk to being customer centric in practice.
Matt LeMay: If you go and talk to a customer and hear that your customers don’t want the thing that your boss just told you to do, that sucks for you. What are you going to choose? Why would you want to put yourself in that situation? There’s no reason to do it. You’re way better off just doing what your boss tells you to do and then blaming them if it doesn’t work. Accountability bingo, it’s a real issue. One thing that we really believe about unlock sprints, and part of the reason it’s so exciting to run these is that it creates a responsibility around customer centricity and practice. When doing these sprints is part of your job then talking to customers is part of your job. If talking to customers is not part of your job, it’s not something you’re going to do.
Will Bachman: Customers are dangerous and should be avoided at all cost.
Matt LeMay: Yeah, that’s the reality for a lot of people. I empathize with that enormously and I’ve been in that situation. When I was building that analytics page for Bitly, did I go and talk to customers? Absolutely not, in part, because I think I have the sneaking suspicion that if I talk to them they would say, “Yeah, we don’t really care about that,” and what would that have meant for me if I had hinged my success as a person in an organization on something that customers don’t want? That kind of goes back to the planning for uncertainty too. In organizations that are really taking these ideas to heart there is always the opportunity and the appreciation for killing off a project if you find out early on that it’s not what your customers want, which is also so hard to do.
Will Bachman: Matt, I often ask folks if there’s a productivity hack or some practice that they’ve recently adopted that they found works really well. You actually mentioned one that I’d love to hear you tell a little bit more about. You said that you have a checklist at your desk of-
Matt LeMay: Yes.
Will Bachman: … things that you do every morning and every afternoon. Could you tell us a little more about that? I’m curious to hear what is on your checklist.
Matt LeMay: Oh I would love to. This has been such a game changer for me. Have you read the “Checklist Manifesto”?
Will Bachman: I love it, it’s one of my favorites, Atul Gawande.
Matt LeMay: Yep, so we are on the same page about this. The thing that I loved about the “Checklist Manifesto” was I was always one of those people who was like I am too smart to write things down, which is a terrible habit. It’s a terrible habit, it sucks for the people you work with, it’s just pure wretched human defensiveness at its worst. For a long time I was like, “Oh, I just know how to do this,” but what I didn’t realize and what that book helped me understand, was that I was kind of making myself crazy by doing that. I was costing myself so much cognitive overhead in order to keep all that stuff and then I would drop the ball on stuff sometimes. I need a checklist that says Matt Daily Work Checklist.
Will Bachman: All right, awesome. What’s on it?
Matt LeMay: I’ll tell you what’s on it, beginning of workday (8:30 AM), update QuickBooks. As somebody who manages the finances for our business, I actually like to look at QuickBooks first thing every day to know where we’re at and to get that taken care of because then when tax season comes I don’t have to think about it.
Will Bachman: Nice.
Matt LeMay: I have check email, either respond or make to-dos for outstanding items. This is my inbox zero approach, just first thing in the morning if it’s something I can respond to quickly I respond to it. If it’s something that needs to be turned into a to-do, what I usually do is make a to-do and then still respond and say, “Thank you so much, I’ll get back to you by this date,” so that I’m keeping everything moving. I think as independent workers in particular, responding quickly to email, even if you respond quickly just to say I will respond later, it is so important. I think-
Will Bachman: I should probably do more of that. That’s a nice trick to say, “Hey, I got it. I’ll respond.” I like that.
Matt LeMay: I honestly feel like maybe 30-40% of the repeat business we’ve gotten is just because of that practice, just because people know that when they email us they’ll get a response. That’s a gimme. That’s one of those things where if you can just make yourself do it every day then you stop overthinking it over time. Then I have review the previous day’s Sudden Compass updates on Slack and respond to any action items.
Matt LeMay: One of the things that my business partners and I did is we created a comms guide for each other, which I also strongly recommend that any teams do, especially remote teams. We capped it to one sheet, we used our why, how, prototype, iterate, practice to do this, but why do we have a comms guide in the first place? The answer that we kept coming back to was to create expectations so we can better manage our own time because it was unclear when an email came in is it urgent, when a Slack message came in when do you want a response by. We wrote out basically like email internally to the team will be responded to within 24-48 hours. Slack messages will be responded to within 24 hours. If anything requires fewer than 24 hours to respond, send it over WhatsApp. I printed that out and have that over my desk also. One of the things I do every morning is I check Slack and see if anything came up that needs my attention. Because we all understand that Slack is on a 24 hour cadence, which feels very Agile, then we can just manage that in the morning and not have to keep our eyes on another quasi synchronous communication platform that sucks untold time out of people’s lives.
Matt LeMay: Check today’s calendar for any potential conflicts or changes. This is another huge pet peeve of mine that I’m sure a lot of other independent workers in particular struggle with this. Clients move things around on my calenders without telling me did it. They’re my clients, I love to love all my clients, but when I check my calendar and a meeting that I thought was going to be at 4 in the afternoon is suddenly at 10 in the morning, and they’re like, “Why weren’t you at the meeting? We changed it on the calendar, didn’t you get the calendar notification,” because sometimes you don’t get the calendar notification. After that, I check today’s calender for any potential changes or conflicts.
Matt LeMay: Then I check Todoist and plan out the day’s activities. What I do is at the end of the morning I basically take a look at created the to-dos when I was going through my email. I look at that and I’m like, “All right, what are my to-dos for today, what’s my calendar for today, how am I going to structure my work?” Then at the end of the day, end of work day (5 PM) respond to all outstanding emails or Boomerang if more time is needed. It’s that same thing where I’m checking emails at the beginning of the day and at the end of the day because I know that anything coming in from my business partners if it’s actually urgent is going to come in through WhatsApp and if it’s quasi urgent it’s going to come in through Slack. I’ll check email periodically throughout the day, but I’ve found that generally speaking, so long as people are getting a response from you by the end of the day, that is a great track record when it goes to email, you don’t need to respond in 10 minutes. Sometimes it’s counterproductive to respond in 10 minutes. I go to sleep at inbox zero every night, which is hugely freeing.
Will Bachman: You must rest-
Matt LeMay: And then-
Will Bachman: … easy.
Matt LeMay: Yes. Then I check tomorrow’s calendar for any potential conflict changes, the same thing. Check for the next day just to see if there’s anything that’s changed. Check to-do list, check off completed activities, reassign dates as needed, sometimes you got to push stuff. Post Sudden Compass daily update, explicitly flagging any action items, including requests for additional meeting time. Then set an alarm for the following morning based on calendar and other stuff. I put that on as well, just because my schedule is variable. But every morning I start with my checklist. Every day I end with my checklist. We use the comms guide.
Matt LeMay: The other productivity hack we’ve done, which actually I just wrote a thing about a couple days ago, is we use a style guide for all of our email subjects, which I also highly recommend people do. Where every email subject that we exchange between each other includes whether it’s an FYI, whether there’s a response requested, or whether there’s a response required, and if so, by what time the response is requested or required. If something comes in from a client that I’m not sure that Trisha or Sunny needs to know about, but I’m like, “It probably couldn’t hurt,” I put in brackets at the beginning of the subject FYI, and I forward it.
Matt LeMay: If it’s something where I could kind of use some input before I send something off, but I’m in no rush, I will say, “Feedback requested by Wednesday 9 AM”. I’ll be very structured and very, very, very direct about what kind of feedback I want and why I want it. If there’s something where I need feedback, what I’ll usually do is send an email that says, “Feedback requested by this date,” and then if it’s super urgent, also send a WhatsApp message just to get everyone’s attention. But if it’s medium term urgent I’ll ping people on Slack as well, which they know they don’t need to respond to until 24 hours from then.
Matt LeMay: A lot of what we’ve done to stay productive as a distributed team is really just about using every instrument of communication purposefully and never assuming that people know what to expect from those instruments of communication, but just putting it super, super, super plainly and clearly in writing, “Here is what an email means. Here is what a Slack message means. Here is what a WhatsApp message means.”
Will Bachman: I love the style guide idea. That’s great, just being crystal clear about if it’s response required or set it as getting this big massive emails that are undifferentiated.
Matt LeMay: Yeah.
Will Bachman: Matt, it’s been fantastic speaking with you. I’ve learned a ton. I now at least have some sense of what Agile means, what a product manager does. I really enjoyed your book.
Matt LeMay: Thanks so much Will.
Will Bachman: What is the best place for people to come and find you if they want to learn more about your work and about your firm’s work?
Matt LeMay: Mattlemay.com if they want to learn more about my point of view on product management and Agile. Suddencompass.com if they want to learn more about the work that we do as a team at Sudden Compass. I’d say check out the book, check out “Agile for Everybody”. It’s intended to be as fun and easy a read as a book about new working methodologies can be. The part of the book that I’m proudest of is just the stories I was able to share from people. I find it really comforting and really valuable to read stories from people who’ve also found their way through uncertainty. The stories in the book are not by the numbers case studies, do this, and do this, and do this, and then you’ll have success, but rather, people who’ve taken these ideas and tried stuff out, and seen what works and seen what doesn’t work, who are able to share really candidly and openly what those experiences have been like. If nothing else, just buy the book and then skim through the parts that are indented and italicized which are the parts that other people told me.
Will Bachman: That is awesome. All right Matt, hey, thanks a lot. It’s great having you on the show. I really appreciate it.
Matt LeMay: Thanks so much Will. This was such a great conversation. I really appreciate it.