One of the biggest challenges a product manager will face (or an organization for that matter) is trying to elevate thinking and culture from a project level to a product level. Project Thinking Project thinking is fairly pervasive. Many folks, especially in software development, have spent a lot of their careers focused on projects and project management. Large organizations often have PMO departments, focused exclusively on project management. It's not surprising, because project management has been around a very long time. And we as humans tend to think in terms of projects: things we need to get done. So what is project thinking? The focus of project thinking is delivery. This could be the delivery of specific features or software, or really the delivery of anything. From aircraft to houses. And because the focus is delivery, the primary measurement is on the timeline and schedule. Project management is specifically focused on the output, and is measured by how accurately we were able to estimate the timeline beforehand and then deliver the specified output on that schedule. Success is largely defined as taking the specs of something beforehand, setting up a schedule with milestones all along they way, and then hitting those dates. Product Thinking Product thinking takes a fundamentally different approach. Rather than focusing on the output, product thinking is focused on the outcome. This is a significant shift from the mindset of project thinking. Rather than focusing on timelines and dates, we focus on the goal we want to achieve or the job to be done. Because we're focused on the outcome rather than the output, it is much more difficult to put time constraints around the delivery, at least up front. Primarily because we don't necessarily know how we're going to accomplish the goal up front. This kind of thinking can be quite the shift, especially for folks who have spent a lot of time focused on projects and project management. Many people are uncomfortable with the uncertainty of not having structured timelines and schedules that they can monitor on a regular basis. The Benefits So what are the benefits of letting go of project timelines in favor of focusing on outcomes? First of all, it is ultimately the outcome that we are driving toward, regardless of how we try and get there. The main benefit of a product mindset is that we ensure that we get to the outcome more efficiently. With a project mindset, we assume at the beginning that we already know how to achieve the desired outcome. Working from that assumption, we create a project plan and timeline full of the requirements and milestones, and then begin execution on that plan. If we're right, and what we assumed initially turns out to be the right solution, then we're in great shape. We just execute the plan and achieve the outcome. But what if we were wrong initially? What if the solution we identified isn't going to achieve the outcome we had hoped? That is where project thinking gets us into all sorts of trouble. Once we set a plan in motion, it can be very difficult, especially in larger organizations, to pivot and change. Once dates have been put in place and everyone has agreed on a plan, that is usually what sticks in everyone's minds, despite our best efforts to learn and adapt. And if we end up missing a date, it can cause incredible issues for teams and businesses. But with a product mindset, we are able to learn and adapt as we go. We aren't set on dates and milestones, but rather are focused on learning and achieving the outcome. If something doesn't work out or customers don't respond well to one thing, we can take that into account, adapt, and still work toward the outcome we had intended without blowing up a beautiful plan that is everyone's focus. Crucially, when problems arise (and don't kid yourself, they always will arise), product thinking allows us to learn and adapt, and stay focused on the outcome we're trying to achieve. In contrast, when problems arise and we're stuck in project thinking with its focus on the timeline, we will often get sucked into endless meetings trying to determine why our initial guesses were wrong and how do we get back on schedule. This ultimately leads to sacrifices in quality, work-life balance, and the outcome since we need to stay focused on delivering the output we initially agreed on (regardless if that is still the right thing to do). A Project Example We've been talking about a lot of concepts, so let's take a look at some examples to better illustrate these points. A great example of a project is the construction of a house. My wife and I built our house last year. We went through the whole process of selecting the floor plan, choosing all the finishes and details in the house, and then paying large amounts of money to get it going. When we started, our construction manager (who was absolutely excellent), gave us the estimated finish date. It was about 6 months in the future. Obviously there are many things that go into these estimates, and things often come up that throw the dates off, but since the construction of a house is a very repeatable process with defined inputs, a good construction manager can look at the plan week by week and determine when they expect to complete the work. Our house was off by about a week, which feels like a bulls-eye in my opinion. One of the trades was delayed in getting their work done, so that set things back a few days, which had some ripple effects. But that is fine. It's expected. When it comes to these types of construction projects, they are very much geared toward project management. Everyone knows what needs to be done and keeping people on schedule is a real key, especially since it wasn't just our house being worked on, but the whole development. A Product Example But does this kind of project management work everywhere? No, it doesn't. As much as we'd like to think of software development as construction, it isn't. The clearly defined plans and work don't translate to product development no matter how hard we try. While there is great comfort in well-defined timelines, that's not how we should do product development. In a product I've been working on, there is a key problem I identified and knew we needed to solve in order to continue to broaden our audience and reach additional users. The traditional approach to this would be gather the requirements, scope out the work, and then build the features. But much to the consternation of many folks at my organization, I don't take that type of typical approach. Once I understood the problem, I dove into researching solutions, from building the features to integrating third-party software. As I did this, it became apparent to me that the solution was, in fact, not to build anything. Rather than build new features or integrate someone else's software (in this case, it was a portfolio for students), the solution was to change what we were asking students to do. Rather than focus on the portfolio tool, we could simply ask them to create the portfolio pieces and then utilize whatever software solution they wanted to in order to showcase their work. The benefits to everyone would be significant. Students would be in control of their portfolio, and we wouldn't be tied to building software or using any specific vendor. We would have never come to this solution with project thinking. This solution came about because I was focused on the problem and the outcome (getting additional users on our application) rather than building the next feature. This type of result is typically the outcome of product thinking. And it can come at any point along the way. In my example above, we avoided doing any development work. But often it may take several design prototypes to figure out what will work. Or we may do small amounts of development work in learning what features will truly drive the outcome we want. No matter where in the process we learn, the key is that we are learning along the way rather than deciding on the course up-front and following a project plan. The Right Way So how do we do that? How do keep a product focus? All products and product management involve some level of project management. We have to keep things moving along and it is (unfortunately) unrealistic to assume that we can work in environment where our stakeholders and partners won't expect some dates or commitments. The key is to make commitments and project plans only at a point when we can do it with a high degree of confidence. So rather than committing to a specific path beforehand, we commit once we've validated what we're doing and have had a chance to really understand what it will take. Often that is a sprint or two into the work. That may feel really late in the process, but it is at the point when estimates and plans can actually mean something. Marty Cagan, in his book Inspired: How to Create Tech Products People Love, calls this type of commitment a "high-integrity commitment." We allow teams time to do proper discovery and research before asking for commitments. And we also need to help others realize the benefit of product thinking. There is a reason many folks ask for dates and timelines. Part of it is because of old habits. But there are times when it is necessary for business and budgets. So we need to understand what the job of the timeline is in those cases. If it is to help sell the product, we should turn the focus from specific features to the higher level story. If it is to manage risk, maybe we need to help folks understand that the real risk isn't missing a date, it's missing the mark completely on what value we're trying to deliver. At the end of the day, the whole purpose of product development is to deliver value to users and customers. Most of the time we don't know exactly what is going to deliver that value though. To think that we can come up with the right solutions up-front, sometimes a year in advance if you do annual planning and budgeting, is pretty unrealistic.
While project thinking focuses on coming up with solutions up-front and then delivering against a schedule, product thinking keeps the focus on the outcome. That involves some level of comfort with uncertainty and learning, which can be pretty hard. But if we want to get to the right outcome, and not just an on-time output, it is really the only way to work.
0 Comments
I was recently asked what a typical day was like for me as a product manager. As anyone in the role will likely attest, there is really no "typical" day for a product manager. Every day is different and filled with its own set of challenges and opportunities. So it's hard to say what a normal day looks like. However, if you expand out the time frame a bit, you can start to get a better picture of what product managers focus on regularly. So I thought I'd post about a recent week of mine as I think it has a good representation of many things product managers do. So here we go. Themes: As a product manager, I am responsible for the high level strategy of our products as well as the day-to-day execution of what the team is working on. A product manager wears a lot of hats, as many are aware. So that typically means that certain times are filled with more strategic items, such as creating the vision and evangelizing it. While other times are filled with some of the details, such as working with the team to refine stories in the backlog. And of course, meeting with users and stakeholders all along the way. You'll see that most of these items are represented throughout the week. Monday: Monday had a little bit of everything, including an array of meetings with various groups including users, stakeholders, the dev team, purchasing and the legal team. Of course we had our daily team stand-up in the morning (these happen everyday, so I'll just mention them here) along with conversations with the team throughout the day. Since most of us sit in the same area, spontaneous conversations are pretty frequent. We often brainstorm ideas or chat about issues as they come up. I also try and start each day looking over key metrics and reviewing anything that may have happened the previous day. Our UX designer and I met with some users to review some feedback that had been submitted in order to get a better understanding of what they were trying to do and why they were having some issues. All of the meetings I have like this include myself, our UX designer, and typically an engineer depending on the topic. I also met with a member of our legal team to discuss our application and then a small group of stakeholders to address some questions that had come up the previous week. Finally, the day finished up with a meeting with the purchasing team. We're negotiating several contracts with vendors. As the product manager, I have the best idea of what our usage projections are going to be as well as what we'll be needing from various vendors going forward. Together with our business partners, we work with the purchasing group to make sure we have that all in order. Tuesday: Tuesday was more of strategic day (not necessarily by design, but it was the day of the week with the fewest meetings, so it gave me the most time to work on some longer term, strategic items). I do try and block out time each week in order to work on strategy/vision, but it doesn't always work out that way. Anyway, I had the chance to think through some of the problems I know we'll be addressing down the road, and how best get stakeholders throughout the organization aligned with our vision. I put together a few documents outlining the framework I'm proposing. In addition, we had two focus groups reviewing some prototypes that we had put together the previous week. Our UX designer and I had been working on some options and wanted to get them in front of students, which we were able to do. And as always, getting user feedback yielded some unexpected surprises. Wednesday: Wednesday was packed with meetings, most of them with the development team. We started the day with a two hour refinement session. We use this time every other week to review upcoming priorities and share knowledge. I'm primarily responsible for getting the stories in our backlog, but my main purpose is to make sure that we have a shared understanding of the context and desired outcomes. So most of the items in the backlog aren't surprises (since we try and have members of the team involved in discovery), but refinement gives us a chance to discuss as a team and begin to think through scope and implications. Wednesday is also the day I meet with our UX designer to discuss our prototypes and designs. We talk much more frequently than once a week, but it gives us a chance to go through the kanban board I set up to keep track of all our ongoing items. We had monthly IT department review of the month (including wins and misses), and then met again as a development team to brainstorm ways to keep our applications running smoothly. And I finished out the day again meeting with a group of users to get feedback on a few questions we have. Thursday: Thursday was another day filled with learning and discovery, as well as working with stakeholders. I started the day meeting with one of our key VPs and sponsors as we discussed upcoming strategy and key priorities. We typically meet one-on-one at least every other week to discuss these types of things. We had a working session with a group of users to determine the next phase of role management within our application. We've been working with very minimal functionality so far, so we're identifying key problems in order to start to prototype some solutions for the next phase of development. We had also been sending around emails for most of the morning regarding some language changes within our application. There was some confusion, so I called a quick huddle with everyone in order to resolve. Fortunately, we were all able to get on the same page and even came up with some better phrasing to explore. Since we had just finished a large rollout of our application to about half of the university students, I met with one of our stakeholders to review how our communication went and determine things we could do better for the next time. A mini retrospective. Friday: I try and keep Fridays relatively unencumbered by meetings (as much as possible). We usually do have a product manager meeting on Friday. A chance to chat with the other product folks in the organization. I also send out a weekly update on Fridays to senior executives, recapping anything that's happened during the week such as releases, discoveries, meetings, etc. And letting them know what's coming up for the next week. Since I'm the product manager for our current flagship effort, it is of particular interest to everyone and I want to make sure they are well-informed. I also do a monthly roadmap meeting with key folks within the IT department as well as across the business. That was set for the following week, so I spent Friday afternoon making sure that everything is up-to-date and ready for those discussions. I also spent some time reviewing an array of reports that I use regularly. They show a variety of usage stats as well as feedback and satisfaction. I had a couple things I wanted added, so I worked with our data team to do that. I also needed some additional information for our roadmap discussions, so I reached out to a few folks to gather that. So that pretty much wraps up the week. And I'd say that's probably about as typical a week as I could expect. There are also seasonal factors that come into play, such as the beginning of the fiscal year and the planning involved in that. And anytime there is a large release or rollout, things are notably different.
But hopefully that is helpful in describing a week in the life of a product manager. You can probably get the sense that there is a wide variety of things that a product manager is responsible for. And it's true. I am involved across the board in many discussions and on many initiatives. It is incredibly exciting but can be incredibly stressful. Ultimately though, it's about creating a product and experience that users love, so there is no easy path to get there. In a product manager meeting at our organization recently, we were all handed the book Insipired: How To Create Tech Products Customers Love. Our leadership team had just started reading it and wanted all of the product managers to read it too. They asked if anyone had read it already, and I was the only one. Which surprised me a bit. So with that, I wanted to put together my 5 "must read" books for product managers. I limited myself to 5 because this list could become huge. But these are the books that I've found the most useful and most important for product managers. I'm planning on writing a few more posts that break down books by stages of career and personal development, but here is my quintessential list of must reads for any product manager. 1. Inspired: How to Create Tech Products Customers Love by Marty Cagan This is basically the best handbook on product management that I've ever read. It is primarily written for product managers and outlines the roles and best practices for product teams. Marty has vast experience working on products and with product teams, and has managed to distill that experience into a guidebook for all ofus. Honestly, if you don't ready any other book, this could probably get you started on the road to creating great products. However, he does reference and pull ideas from many places, so the more familiarity you have with things like lean, agile, research, organization, etc., the more you'll get out of this book. Not only does this book outline best practices, but it calls out the things to avoid. And if Chapter 6 sounds at all familiar to you (it had me pretty depressed with how close to home it hit for me and often still does), then you know you need the lessons from this book. It is also very much worth re-reading. As with any book, the lessons you're likely to take out of it depend on what you are currently experiencing. So this is a go-to book for me, and one of the few books that I have on my list to re-read periodically. 2. The Design of Everyday Things by Don Norman If there was an entrance exam into product management, then this would certainly be one of the textbooks you'd need to study in order to pass. I didn't read it until years into my product management career, and felt a little embarrassed that I was just picking it up. It is incredibly detailed and dives into all things design. Everything from the psychopathology of things in our world to true design thinking. The 2nd edition has a lot of updated examples, which are incredibly helpful. And there are still the classics, like office doors that don't have appropriate signals to let you know whether you should push or pull (we have doors that slide in my current office, so you can only imagine the havoc that has wreaked on people as they learn the identify the cues). I'm a firm believer that as product managers we must be well-versed in good design. It certainly isn't something that is "just for the designers" (though your team's designer should be working with you every step of the way). 3. Competing Against Luck by Clayton Christensen If you're not familiar with Clayton Christensen's books, you should definitely check them out. He is probably most famous for The Innovator's Dilemma which is foundational to the idea of innovative disruption. Certainly a must read business book. But Competing Against Luck is much more applicable to product managers directly in my opinion. It is pretty much the culmination of all their team's research and writing on the idea of "jobs to be done" and its application. Jobs to be done essentially boils to the idea that customers don't buy products for the sake of the product. They "hire" products in order to help them get jobs done. No one wants a quarter-inch drillbit, they want a quarter-inch hole. So we need to focus on the job to be done and why customers hire our products. I've been a long-time subscriber to the theory of jobs to be done, and this is one of the best books that brings all the research and theory together. 4. The Lean Startup by Eric Ries This book pretty much started a revolution in how we create products (or brought together a lot of the new techniques that were taking off). As a product manager, you need to understand the principles of lean. Whether it is for a startup or for a large company, the principles are largely the same. Getting to validated learning, rapid experimentation and shortened development cycles in order to understand what customers want and deliver those solutions. The Lean Startup is pretty fundamental to product development these days. It is pretty much assumed that everyone is familiar with most of these principles, so you'll want to be familiar with this book. And more importantly, they will make you a better product manager creating better products. As you learn, get feedback and iterate, you will be able to avoid the pitfalls of so many products out there. 5. Sprint by Jake Knapp This book has been really influential in my application of design thinking. Like the title suggests, it is about testing ideas in order to solve big problems. And doing it in a week. It gives the blueprint for how to conduct a "sprint" (I think of it as a design sprint since we use sprint in other places for scrum). And it shows how to get from problem to verified solution in a week. In my experience, you don't have to run design sprints to get the benefits of the principles of the design sprint. I've taken may aspects of this book and applied them to meetings or other contexts. We've done "mini-sprints" where we take smaller problems and go through the steps over the course of a few hours. So whether you're looking at small problems or need to do a full week-long sprint to validate ideas, this is a very practical book on how to get there. So there it is. My top books for product managers. It was pretty difficult to narrow this down to just 5 books. There are a ton of great options out there that I couldn't include here. But I truly feel like these 5 books lay an incredibly solid foundation for product managers. So if you have read any of these before, you and your organization will benefit from these principles.
Happy reading! The comparison has been around for a long time – the product manager is the CEO of their product. It’s become ingrained in our thinking and the way we talk about product management. For newcomers, it’s an exciting concept. Everyone wants to be the CEO, right? Make decisions. Create vision. Command respect. But is it true? Is the product manager the CEO? The short answer: it depends. The product manager isn't an executive. She doesn't have final authority. She can't hire and fire people. She can't determine the budget and pull resources in most cases. In short, she isn't really the CEO in that way. But you say above that the product manager is the CEO. What gives? Many characteristics of a good CEO should be emulated by product managers. Ownership, leadership, drive, ambition, etc. So here is how the product manager really is the CEO of their product. Chief Empathizing Officer One of the most crucial characteristics of a good product manager is empathy. Empathy for users of our products. Empathy for our stakeholders. And empathy for anyone impacted by our work. With that, the first role of a product manager is to be the chief empathizer. When I first came into my current role in developing a new application for university students and faculty, I knew I had to get a much deeper understanding of all our users. So I started doing frequent interviews. I would watch as they did their work. I would ask questions. I would then take what they were doing and do it myself, going through the whole process. Only after all of this was I able to really understand the pain points these users had. Some of the pain they didn't even realize. The pain had been around for so long that it had simply become "the process". Those were the things that I knew we could solve. The things users didn't even realize were terrible because they had always been terrible. A product manager has to be able to understand the users and customers of their product. The product manager needs to really internalize the user experience and be their advocate throughout the product development process. Of course, this doesn't absolve the rest of the team or business from having empathy for users, but I'd argue that no one should embody that role more than the product manager. Chief Experience Officer I know this is an actual title in some places, which is excellent. Along the same lines as empathizing with users, the experience of the user should be first and foremost on our minds as product managers. We aren't simply designing tools or applications or software, but are ultimately creating experiences. No piece of software is used in isolation. No application is used without some context. We as product managers need to understand that context and understand the experience. There is an excellent story about this over on the Inside Intercom blog. James Buckhouse does a masterful job in audio storytelling. It's short, so I'd encourage you to give it a listen. It's about truly capturing the human experience. And while geared toward designers, I'd say just as true for product managers. We have to own the experience, which means going beyond the pixels. Chief Editing Officer The product manager is the chief editor. If we look at an editor's role in writing, he is meant to be a gatekeeper between an author and an audience. To ensure that the message being conveyed is clear and concise. The best editors are often a bit harsh, forcing writers to think about their audience and shorten things so that the point is clear and the flow is logical. This is crucial for product managers. A good product manager should be constantly editing their product. Ensuring that the features are core to the strategy of the product and company, and not just a laundry list that customers or management have asked for. The product manager should also constantly be forcing the team and business to think about the audience - the users of the product. It's about what to include and what not to include. One of my favorite examples of this is Google Docs. It is an application I've used for years and probably will continue to use for years. Many of you probably feel the same. It is not nearly as powerful or robust as Microsoft Word. And that is partly the point. It doesn't have to do everything. It is a simple, online word processor that can do 95% of what most users need. Sure, there is a place for Word and likely always will be, but for simplicity and functionality, you can't beat Docs. Chief Evangelizing Officer I love this one because it plays so well to most product managers I've seen. No one else is going to be an advocate for your product like you are. No matter how much we think our products may sell themselves, we can never stop evangelizing the benefits of our products. I'd also take this a step further to say that the product manager generally needs to be a consistent communicator. That goes for both the good and bad. Evangelizing typically connotes positivity and bringing people to our side because of the benefits of something. But no product manager should look at their product with rose-colored glasses. There are trade-offs to be made. Honest discussion about those things is crucial. That doesn't mean we have to lose our positivity, but be realistic about the positives and negatives. Marty Cagan shares a great story about Lea Hickman at Adobe as they transitioned their creative suite from a purchase model to a subscription model. It was a monumental change to the way Adobe built and released software, and to how customers used it. One of the keys to making the move was the evangelizing that Lea, the product manager, did throughout. To get an entire company to buy into a massive change is no small feat. And it involved trade-offs across the board. But ultimately was the right decision. Chief Expert Officer Another key role for product managers is to be an expert in their product. Any questions about the product should be readily handled by the product manager. But it goes beyond knowing the product inside and out. The product manager also must know how their product relates to the larger business, the strategy of the company, and the broader market. The product manager has to keep a pulse of the industry and trends, and be the local expert for their team and stakeholders. In fine, the product manager needs to be an expert in the problem (or problems) they are solving. It goes back to empathy and experience. The problems that users are facing need to be deeply understood by the product manager, so that she can deliver the right solutions. Chief Experiment Officer In order to get to the right solutions for users, a product manager has to experiment. This means uncovering problems, asking questions, creating hypotheses, and then testing those hypotheses through experiments. (For a handy guide, check out this article). Experimenting is a lot of hard work. But it is a crucial part of the process. Taking solutions and actually testing them out before implementing them across the board. It's a way to understand what is happening when you make changes and homing in on the right things. A favorite example of experimenting and learning is the story of Dropbox. They were able to do experiments throughout their initial phases in order to learn what users wanted, and what they didn't want, in order to build the right features. Experimenting is key to product success. Chief Facilitating Officer And if it's not enough for a product manager to be a CEO, we'll add CFO to the title as well. Why not, right? In this case, however, we're really taking about being the facilitator. Gone are the days when a product manager served as a proxy for the business or the customer, being the gate between them and the development team. At least those days should be gone. A key role for a product manager isn't to be the go-between, but to actually bring the product team together with business stakeholders and users and actually facilitate the learning and interaction that comes from it. In my experience, bringing the developers into the conversation adds tremendous value. Rather than me simply taking the message back, the development team gets to actually hear from the users and see their pain. That has, on more than one occasion, turned the entire conversation. So while a product manager may not be the full-on CEO of their product, there are many ways that they are the CEO. Through empathizing with users, owning the experience, editing and evangelizing the product, being the expert, experimenting, and facilitating learning and communication, they are the leader that is accountable for success or failure. And while no one should go into product management believing they are going to be the actual CEO of something, embodying the traits of great CEOs will lead to success.
And with that kind of experience, it's not surprising that many product managers eventually make great candidates to take on the executive role. So if you want to be a CEO, don't make the mistake of thinking that becoming a product manager makes you the CEO. But don't be surprised when you get to an executive role at some point in the future after being a great product manager. I was on the golf course a few weeks ago. It was pretty warm, but it was likely the last chance we'd have to go before the weather got really hot, so we took advantage of a cool morning to hit the links. Now I'm not a great golfer, so this isn't going to be a post describing best practices when it comes to golf. I tend to be all over the place for most of the time. But one area where I am pretty consistent is on the green. When it comes to putting, I may not be sinking 50 foot birdies, but I do tend hit generally good putts. The right distance. The right line. They don't always go in, but they tend to get me pretty close. My key to that has always been taking my putts really slowly. I think about them. I visualize them in my head. When I get up next to the ball, I don't just hit it. I stand over it, gauging my swing and the green and all the other variables that go with putting. I go really slowly. It sometimes drives people a little crazy. But I don't care. I take my time and hit my putt. How often are we rushing our putts? All the time? It kind of feels like it. As I contemplated a typical day at work, it generally consists of rushing from one meeting to the next. Rushing to get emails sent out. Rushing to gather information. Rushing to have quick conversations with folks to check in on things. Everything is a rush. I get it. Everyone is busy. We have lots to do. We have tons of things to cover in our meetings. We have so many responsibilities that we have to rush from one task to the next in order to make sure nothing is falling through the cracks. But it's not just work. How often do we rush to get to work, or get home from work, or get to the store? We rush to have dinner in order to make it to evening activities, which can also be a flurry as we rush through them so we can get home in time for bed. But how much are we missing as we rush? I'd estimate that we're losing some of the most important details in our rush to get things done. This is happening to each of us individually as well as our teams and families and friends. At work, I've noticed this in countless meetings I've been in lately. We have a packed agenda that we need to get through so we plow through as quickly as we can. There isn't time for a ton of conversation because we have items we need to get through. And if discussion starts to happen, it is generally shut down after a very short time as something that is better "taken offline." And it isn't just other people. It is all of us. It is me. I don't think I could keep track of the number of days that I rush from one thing to the next, only to reach the end of a blurred day to wonder what had happened. The cost of this kind of rushing is high. Recently another product manager and I realized that our teams had been working independently on very similar projects. Now there is certainly something to be said for process, coordination, and all of that. But I can't help but wonder if, as product managers, we had slowed down just a little and had some conversations in the various meetings we're in. Rather than sticking so tightly to agendas, what if we had just talked about things we had in the works. Would we have realized this sooner? I believe so. And what about the cost to our families? Are we missing the most important moments? When our son was born, I was working 70-80 hours per week. That continued for a time after that. I was constantly in motion, running as fast as I could to get ahead. It was pure chance I was home one evening around 5pm (early for me at the time), and was able to actually witness him taking his first steps. It caused me serious pause. What other moments was I missing out on in my rush? And finally, what is the cost to ourselves? How long can we keep moving at 100 miles per hour, rushing through life before it begins to take its toll? Another shot of caffeine to keep us moving. Not enough time for a decent meal, so we eat whatever is quick and easy. Not enough time to properly plan for our futures, so we have to take whatever comes because we don't have time to prepare. So how can we slow things down?
I will be posting more about this soon, but I've started to block out time each day to slow down. To actually think. To work on important tasks that tend to get lost in the rush of everything else we have going on. We can also start to take time in all of our meetings and interactions for actual discussion. Maybe even begin to plan for meetings that are just about discussion. I've been in meetings like this and found them to be the absolute most productive meetings I've participated in. No agenda, no bullet points to get through. Just discussion. As we allow ourselves the necessary time to slow down, I think we'll find that we're able to get more done. More of the important things. We won't waste so much time being pulled in different directions. We'll be able to focus on thing things that are important. I've started to find that as I try not to rush my putts at work, I'm actually getting much closer to the hole than I was before. I'm able to size up what I need to do and then execute better than ever before. So take a minute, take a breath. Don't rush your putts. As I've started new jobs, whether changing companies or taking on new projects, I've realized there is really one thing you have to get right if you want to be successful long-term. It's building credibility. This is particularly important for product managers, since we have no direct authority over anyone, but need to influence people throughout an organization in order to be successful. Of course, building credibility is crucial in most roles, especially as you get started. As I've been thinking about my own experiences and watching those around me, I've realized that credibility is very much like like an investment account. You add a little bit to it at a time, and it starts to grow. And once you've made enough deposits, you can start tapping into it without drawing down too much. But you can't make withdrawals if you haven't made deposits, at least not without seriously damaging yourself. Asking people to trust you without giving them any reason to trust you is a surefire way to lose. Lose face, lose credibility, and lose long-term influence. It may seem fine at first since people may have no other option, but those withdrawals will come back at some point, especially if you haven't delivered, but often even if you have. So how can we make deposits into our credibility account? The good news is that you don't have to be an industry expert or a visionary. You just have to start to lay the foundation of trust in order to build upon it. So here are a few key ways to do that, especially as you begin a new role. "You may be the world's foremost expert on something, but if you don't understand the context you're operating in, not a single person will care about what you have to say." Have Humility Coming out of college, I was pretty cock-sure of myself. As most college grads seem to be. Particularly, I was abundantly confident in my Excel skills. I had taken several classes focused on Excel and had been using it for work and projects, so why wouldn't I be an Excel expert, especially compared to folks who clearly weren't as well-versed as I was? That was the attitude I took into my first job. I can recall working with an experienced product manager and noticing that they were doing something in Excel that could be sped up with a shortcut. So I, of course, showed them how to use the shortcut, subtly demonstrating my knowledge and experience. Fortunately she was very gracious and thanked me for showing her. I figured that most of my team probably didn't know Excel that well and I could take that opportunity to teach everyone. I couldn't have been more wrong. Everyone I worked with was vastly superior in their knowledge of Excel. As I sat down again with the aforementioned product manager, she began to walk me through several spreadsheets she had built for a project I would be taking on. I was overwhelmed because I didn't understand half of the things she did. She had to walk me through a couple times all of the functions and macros and queries she had built so that I could even take notes. So while I may have known about some shortcuts, I was vastly unprepared for the depth of knowledge that others had for the job specific things that they were experts at. That was a humbling experience, but I see it repeated so often. When we come into new roles, we may have this idea that those around us aren't as capable as we are. Be humble. There is a good chance that you, being the new person, will have a lot to learn. And that's not just coming out of college. You'll have a lot to learn even with 20 years of experience. The best people always do. Be Patient In another role that I had previously, we went through a significant change in management. Not only did our entire organization get moved, but our managers were also shifted. Up to that point, our group had been working with a significant amount of autonomy, which upper management wanted to end. So they brought in a new manager for our group with the intent of reining things in. But that's not what happened, at least not immediately. Our new manager came into his role with a mandate from his superiors, but he didn't do anything initially. He told all of us that his first order of business was to get a deep understanding of our group and organization before he made any changes. And that's what he did. He met with all of us multiple times to fill in his understanding. He was open about the changes that were being considered, and asked for frank feedback. In the end, there were a lot of changes made to our organization and group. Not all of the I agreed with. But I wasn't upset about any of them. Because rather than come in and simply rush to make senior leaders happy, our new manager was patient. He made sure that changes made sense and that he took the time to really "get it" before moving forward. That's a lesson for us all. As you move into new things, be patient. It is probably going to be incredibly difficult, but your teams will thank you for it. Gain Understanding Another real key to success is gaining understanding, like my manager did above. You may be the world's foremost expert on something, but if you don't understand the context you're operating in, not a single person will care about what you have to say. I've seen this frequently with certain groups of agile coaches and project managers that are brought into organizations. Ever eager to bring their "expertise" to the group, they jump right into their solutions before they even understand what the problems are (if there are in fact any problems). Just because something you did in a previous role was a huge success, doesn't mean it's the right thing for a new role or project. How would you even know if you haven't take the time to understand? Understand the team, the organization, the customers, the stakeholders involved. In one instance in my career, our organization hired a project manager to be part of our product team (I know, another story for another time about organizational structure). Within a very short time, he was trying to change the workflow of our team from top to bottom. He had lots of charts and documents showing what he wanted to implement and what he expected. It was truly bizarre to me. Because as I looked through these things and listened to him, it was very clear to me that he had no understanding of how our team worked or what we were already doing. Credibility lost. Don't try and make withdrawals on credibility you don't have. Just because you have 20 years of experience doing something, doesn't mean you can be immediately prescriptive of what others should do. Rather than be like this project manager, be like my manager above. Understand the people. Understand the problems. Understand the current state of things so that when you do make suggestions or implement changes, you can do it while getting everyone on board together. To gain understanding, you'll have to ask a lot of questions and really listen to the people involved. You'll likely hear different things from those in the trenches, and that is often where your key insights will come from. Add Value Finally, you need to find the places where you can add value. It's not just about listening and understanding, though that is a huge part, but you also need to contribute to the success of the team and organization. That's what they brought you on for, right? While there are numerous ways you can start to add value (while adhering to the advice above), here are a couple that have worked for me: 1. Get involved - Don't let the fact that you're new or unfamiliar with things keep you from raising your hand whenever possible. Take on projects that will not only help you learn, but will start to help you make those credibility deposits as a team player. 2. Make your suggestions - While this may seem to go against some of the advice above, it's really all about your attitude and delivery. Don't be prescriptive, but tell the stories of how you did things and ask if those around you think that may be helpful. Let your new team guide you, but don't be afraid to ask the question. As you start a new role, whether in your current job or with a new company, focus on making credibility deposits. Don't try and draw down too soon. You may have been the guru before, but it will take some time to build up that kind of reputation again. Don't worry, it will come. Just do it right and you'll be off to a great start.
Some teams have backlog refinement (or grooming) down to a science. Other teams, not so much. Either they don't even try, or it is a time that is more or less wasted since there is no clear direction or purpose. I've been there. We've probably all been there. And if you haven't, I suppose you can stop reading now. But for anyone who currently finds their refinement efforts lacking, here is a little something to try. And even if things are going well, maybe this could help focus you even more. As I was contemplating how to make our refinement meetings more focused, here is what I came up with. FUSE. As we examine each story in our backlog, along with the epics they belong to, I've asked the team to help think about 4 things in order to ensure each story is ready for prime time. Focused: Is each story appropriately focused? As we build out stories and descriptions and acceptance criteria, there is always the possibility that we've included too much in a given story. So asking the team to help us take a step back and make sure that the story is focused enough and doesn't need to be further broken out. Understandable: Is the story understandable? What questions remain? This is probably an area that I always need some guidance on. I understand the story since I put it into the backlog. I generally know the entire backstory as well. And the business need and the user perspective etc. But the team may not always have that full perspective. This is a great time to not only explain everything, but to also make sure all of that is captured in the story. Sized: What is the size of the story? Of course, no refinement exercise is really complete if we haven't estimated a size for a given story. Once the story is understood and broken out sufficiently, we need to size it so we have an idea where it will fit into one of our sprints. Of course, sizing is a separate topic in itself, so we'll leave that for another post. Expounded: Finally, is the story fully expounded? This ties in very nicely with it being understandable, but I think it deserves its own section. We need to make sure appropriate detail is there, and doing this jointly with the development team is crucial. It involves getting their input and including that. Expounding also extends to the epic or version as well. Our refinement meetings are great opportunities to ensure that the stories we've written include all the necessary items. Hopefully that is the case, but it's never a bad idea to pause and think again about all the stories together to ensure nothing has been overlooked. As we've implemented this "checklist" into our refinement meetings, it has vastly improved our productivity. It has given our team the ability to focus on what we need to get done and given us direction. We no longer meander through stories but have a purpose in analyzing everything. So give it a try and let me know what other practices you use to get the most out of your refinement meetings.
My Time at Goldman
A few years into my career at Goldman Sachs, I got a phone call from a recruiter for another company. This wasn't unusual, but a question he asked stuck with me. When he probed a bit about my willingness to leave and detected my hesitation at that point, he posited "So you're a Goldman guy for life, eh?" I didn't plan on being a Goldman guy for life, but I also had several things I wanted to accomplish before leaving. I wanted to establish myself as a leader within my team and within the Salt Lake office. I wanted to advance to become a vice president. I wanted ensure that I created some lasting products. Fortunately I was able to accomplish all of those things. I proposed Goldman begin to participate in the Salt Lake Corporate Games, and led the whole office in coordinating that effort for five years. It included hundreds of people each year, and over 40 teams. And each year our office was in the running to win first place. Our best finish, in my final year, was third place. A huge accomplishment. I also established myself as our team leader, taking on a mentoring and leadership role for the Salt Lake fixed income group. And in just over 5 years, I was promoted to vice president. In my final few years at Goldman, I also led the creation of multiple new products. This consisted of financial products, including three new money market mutual funds, as well as technology products, including investment tools and internal and external websites. You can learn more about my journey into product management in this post. It was after I reached many of these milestones though, that I started to think deeply about what was next for me. My Decision to Move In college, I struggled initially with deciding on a degree path. I enjoyed business and management. I seemed to have an affinity for finance. I was surprisingly adept at accounting. I loved technology. Ultimately, I settled on pursing a degree in finance since it would give me a path in a few of the areas I enjoyed. It was also a way that I could help people. Money will never go away. And people/businesses will always need help in that area. So it was decided. I would go into finance to ultimately help people achieve their goals. After nearly seven years at Goldman Sachs, I began to really think hard about what was next. There were many options for me still. I could continue in my role, taking on more projects and helping to grow the Salt Lake office. I could take a trading job in New York, and move my family out there. Or I could begin to pursue other opportunities. I also began to really evaluate what I wanted my legacy to be. A few conversations I was having with family and friends had turned my thoughts to the very long-term. When looking back on my career, what did I want to have accomplished? What mark was I going to leave? What would bring me the most joy? When I initially got into finance, it was with the intention of helping people. And while I certainly think there is a role in helping large institutions that ultimately impacts individuals, I felt too far removed from my original goal. And in my role as a product manager, I found myself the most passionate about the technology products I was creating, rather than the financial side. Moving On So with all of that in mind, I knew that the next step for me would be a technology focused role that had a significant impact on individuals. Creating the products that could improve or change lives. In order to accomplish this, I first decided that I should expand and "level up" my tech skills. So I did a coding bootcamp in the evenings and started to teach myself coding wherever I could. This of course helped in my existing role working with development teams, and set me up to better be able to move fully into the tech space. I also primarily focused my job search on the education space. I knew that there is no way to make a bigger impact on people than to help them change their own lives through education. Fortunately for me, my own decision to move on aligned with the build out of the product management organization at Western Governors University. And a great fit was made. So I left my role with Goldman Sachs in March, and straightaway started as a Senior Product Manager with WGU. With Gratitude When you're going through things in the moment, it can often be hard to be grateful. I know that is certainly the case with many things in our careers, and is certainly the case with many of my experiences at Goldman. There were some really tough times. But ultimately I'm grateful for the opportunities I had there and the things I accomplished. I'm already looking back nostalgically on a few things (though other things might take a little more time still). I learned a great many lessons in my time, and hope to continue to build on those experiences as I build the next generation of products that are going to change people's lives. When I first started in my first role out of college, multitasking was not just the norm, but the expectation. I recall getting training on a few things that I'd be doing. One task involved pulling data from a few different reports that we generated and then using that information in a handful of spreadsheets that then got put into another report. All well and good. But while the reports were being generated for that task, we switched focus to another task. As soon as a report popped open, we'd switch back to the first task. Back and forth. Add in a few other tasks during all this and hopefully you get the picture. The ability to multitask in this way was worn like a badge of honor by many people. The expectation was that everyone have the ability to switch from one thing to another to another constantly. Emails to tasks to phone calls to reports etc. Of course, I noticed this and tried my best to follow suit. After all, I was a smart individual and knew I could keep up with the best of them. Fortunately for me, I realized quickly how terrible this was. I marveled that everyone else wasn't making loads of mistakes working this way. Until I realized they were. And I was too. Any time I might have gained by switching back and forth so as to not waste a second, cost me more time going back through all my work to check for mistakes. It was a real waste. Research There has been plenty written recently about how multitasking in this fashion. Rather than gain efficiency, we actually lose it and increase risks. In the case of work, it means making mistakes on what we're doing. When it comes to something like driving and texting, the risks are even higher. The American Psychological Association has some great studies about the costs of trying to multitask and our inability to do it. There is even a great little experiment that shows how poor we really are when it comes to multitasking. Try writing a sentence and then a sequence of numbers. Now try writing one letter and switching to a number and see how well you do. Not well, I'm sure. What to Do I have the feeling that many of know this to a large degree. We know multitasking is bad. Driving and texting, Facebook and meetings, etc. But we still fall victim to it at work. At least I did, until I actively decided to kill multitasking. Here are a few of the things I did early on and try to do still. Leave the Email The main culprit I noticed early on was email. I know that not places are the same, and some organizations abuse email more than others. It wouldn't be unusual for me to receive an email or two every minute. Some requiring my attention, others not. But to stop to check email every time I received one was the biggest productivity killer there could be. So I stopped. I'd allow emails to wait until I was at a point I could shift my focus for a minute. No more being a slave to my inbox. Set Expectations This led me directly to setting expectations with everyone I worked with. I wanted to make sure they knew I'd get back to them, but not to ever expect immediate replies or answers. This took a little bit of time, but with good communication and follow-up, it works wonders. All of my colleagues knew they could depend on me to get back to them, but that I wasn't living in my inbox and may take a few minutes. Once the expectations were set, life became a lot better. Prioritize Clearly set what your priorities are going to be. What is the most important? The most urgent? What can be knocked out quickly and what might take some more time? Once you've established priorities, it's time to focus. Focus on One Task Forget about jumping back and forth between things. Focus on one thing and do it well. Even if there is a little down time in that task, like there was for me when I was generating reports, it costs much more to try and switch back and forth between tasks. By staying focused on the current task, I didn't have to try and remember where I was and what I needed to do. I saved the mental cost and mitigated the risk for me. It's impossible to multitask like we commonly think about. This doesn't mean you can't balance multiple things going on at the same time (which is the life of a product manager), but it does mean not allowing yourself to get pulled from one thing to another every few minutes. Focus on priorities and work until you get to a place where you can effectively switch tasks without losing efficiency. When it comes to multitasking, just don't.
Having a dedicated UX person or team is great for many reasons. They are experts in the different areas of user experience. They are another set of eyes on ideas, constantly thinking about how users are going to interact with different products and features. But that doesn't mean that UX should sit with a dedicated person or team. Everyone is responsible for thinking about what the user experience is going to be. I think that is especially true for product managers. We can't deflect the responsibility simply because there is someone else who does it. So with that, here is a framework that I've used in my own product management experience. It is my four "F"s. Function First off is function. Because you simply can't have a product or feature that doesn't function. For me, nothing else matters if this part isn't there. Of course, this is driven by the user's goals. What is it that they want to do? What problem do they have we are trying to solve? How are we best positioned to solve the problem? When it comes to beautiful design, it's hard not to think of Apple products. And usually the function is there too. But in the case of the Magic Mouse 2, design clearly took precedent over function. While adding the ability to recharge it was great, the lightening port was put on the bottom of the mouse, making it completely unusable when you need to recharge it. Putting the port on the front of the mouse may have made it a little less beautiful, but it would have made it usable when it came time to charge it. Fortunately most of the products and features I've worked on, especially recently, have always been about function first. But I do recall a time when that wasn't the case. We wanted to create a new web page for clients with lots of information that wasn't currently available. It had lots of nice looking charts and graphs and information, but unfortunately got pushed live before any historical information was available. So while it was very pretty, most of the information it promised wasn't there yet. Users got a snapshot of the current day, but without being able to compare that to other things it was useless. Needless to say, we had to pull it back down since it was causing confusion rather than helping users. Form This is the next building block of the user experience for me. Once the function is there, the problem is being solved or the goal addressed, it has to have some aesthetic appeal. When I first started my coding bootcamp, the idea of form was addressed by one of the instructors. He was teaching CSS and showing some cool tips and tricks. At the end of his lesson, he begged everyone to not forget about the look of their products. He said it happened in every cohort, all the time. People became obsessed with getting the functionality of their apps or sites or projects, only to run out of time to make it look good. So at the end of the bootcamp, people demonstrate their apps with awesome functionality, but they all look like crap. I tried to take that lesson to heart for my projects during my time there as well as after. Products have to look good or people won't want to use them. There is a certain level of distrust we have if an app or site doesn't look professional. The alarm bells start to go off that it might not be legitimate. This doesn't mean that every product has to go out perfectly polished, but good form has to be there from the start so it can be improved upon. Fit Once you have the function and form, the next step for me is thinking about how a product or feature fits into the user's life. Solving a problem and making it look good are great, but if it doesn't fit into the user's life, they simply aren't going to adopt it. This tends to be the problem with many fitness and weight loss tools. I think MyFitnessPal is a great app and I tend to start out using it periodically with the best of intentions. But unfortunately I just can't ever get into the habit of entering information after every meal. It simply takes me too far out of my routine to be useful. I had this problem with a financial product that we launched. It was useful product, at least in our view, that people should have in their portfolio. But no one seemed interested and it didn't go anywhere. So I set out to do some customer research. Among a few other problems, we discovered that people just didn't see how it fit into their portfolios. So we addressed that issue with some new online tools to help them see where it would fit and we saw much more success after that. Fun Finally, it has to be fun. When I think of something "fun", I think of something that I want to come back to, something I want to do again. To me, the "fun" is the culmination of the other elements. When things are done right, you should have a product that makes people want to come back to it again and again. Pinterest seems to have fun nailed down within its product. It's easy to use and a fun way to find new ideas for cooking, DIY projects, clothes, styles, etc. It's got the functionality, the form and fits easily into people's lives. Nothing is simpler than pulling up the home page of Pinterest, scrolling and pinning things. It is something that many, many people keep coming back to. Now I'm not an avid Pinterest user, but I can certainly understand the appeal. Many of the products I've worked on recently aren't what you'd traditionally think of as "fun". But it is an aspect of UX that I've tried to always keep in mind. How can we make this product or feature something that people want to come back to again and again? An example is a redesign of an internal website that I created to help our sales and marketing teams. I took several sites and consolidated it all down to one, easy to use site with only the most relevant information. We added data that was useful and suddenly had a tool that people were checking frequently because it was the quickest place to find what they needed. Not a super sexy app, but fun enough to keep people coming back. UX and product management tend to distinct roles at many places, but I don't think we can really afford to completely separate the two. Product managers need to keep the full user experience in mind as we design and implement new products and features. And by keeping UX in mind through the process, we will certainly always come out with better products.
|
AuthorMy personal musings on a variety of topics. Categories
All
Archives
January 2023
|