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. |
AuthorMy personal musings on a variety of topics. Categories
All
Archives
January 2023
|