Overall, it was another amazing year for our family. It's crazy to think that 2018 is over, but is fun to take a look back at how much we've accomplished and how much we've all grown. While I certainly wish a few things could have gone differently this year, I'm overjoyed with how well 2018 treated us. Here are some of the highlights: Kelli and I were fortunate enough to take two vacations together this year. The first one was a relaxing and romantic getaway to Cabo. It was amazing to get out of the cold Utah weather for a few days and spend some time together just the two of us. We also got to celebrate our 10 year anniversary in London! It was a dream vacation for Kelli, who has been wanting to visit their for quite some time. We had a packed itinerary, and walked a lot, but got to see almost all of our wish-list sites. It was an incredibly memorable way to celebrate the best 10 years of our lives. Both McCoy and McKinley have grown immensely over this past year, and we're pretty much busier than ever with soccer, dance, art classes, swimming lessons, etc. I didn't realize how early this kind of craziness started, but we're in the think of it already with both of them. And it's great. It's been amazing to see how much they can learn and grow at such a young age. I was even able to start teaching McCoy to golf. We got a few rounds in during the fall and he is in love with it so far. We were also able to finish our backyard, which was a monumental project and took way longer than I had hoped. It was hot and dusty and something that I don't want to have to do again, but the end result was worth it. We were fortunate enough to be able to do a lot of family activities as well this year. It has certainly gotten easier with the kids a little older now and we've taken advantage of so many of the cool things close by.
I was also able to get my woodshop fully set up again this year, and despite being focused elsewhere for most of the year (that darn backyard), I still was able to get some great things done and had a great Christmas season on Etsy. My favorite thing was probably making a doll bed for Kinley and a corn hole set for McCoy. They turned out really well and Kelli did an amazing job sewing all the pieces to go with both. My hope is that doll bed gets to become something special for Kinley for the rest of her life. This post could probably go on for quite a while still, but it truly was a great year, and it's hard to think of more we could have asked for. Here's to a 2019 that is even better!
0 Comments
When the only tool you have is a hammer, every problem tends to look like a nail. A persistent problem I keep seeing is that some long-standing practices tend to take the place of better ways of doing things. I wrote about the example of product thinking and project thinking here, which is one way this happens. But so many other areas of product development are prone to this same problem. Rather than understanding the underlying issues and determining the best way to address, we can often fall into old habits or familiar thinking. Many times it’s not even a bad way of doing things. But we (and our organizations) can do better. So how can we get out of some of our bad habits? How can we take our thinking to the next level? Elevating Our Product Thinking Understanding Problems over Gathering Requirements The term “requirement” makes me cringe a little bit, and I try to avoid using it whenever discussing problems to be solved. The connotation of it implies a rigidity that simply doesn’t work for modern product development. And the way it has been used for years leads too many people to think of it as an order that is taken by the product manager or product team and incorporated into the product. It’s a requirement after all. Gathering requirements has been happening for a long time, which is why it is such an ingrained way of doing things. But I’d argue that if you’re only gathering requirements and then prioritizing them, you’re missing most of the opportunities to build a great product and experience. A requirement in this sense is really an initial idea or guess at a solution. And usually our initial guesses are wrong (sorry, but it’s true). That’s part of the reason I love the jobs-to-be-done framework (and one of my favorite books on the subject is Competing Against Luck). If you simply stop at gathering requirements, you haven’t gotten down to the actual job to be done — to understand the underlying need and if there is a better way of meeting that need. To get to this level of understanding, we have to go beyond “gathering requirements” to truly understand users. A great way of doing this involves journey mapping and story mapping. (More to come on story mapping later, but if you haven’t already read User Story Mapping, go get it now. Absolutely a game changer.) As an example, we were recently going through the experience for a subset of users of our product. One request they had was a button to export data to Excel. If we would have stopped at that level, we would have missed the real need. As we dove into that request (or “requirement”), we found that the export was an intermediary step. The ultimate goal was to get the data into Salesforce. So what they really needed was to get information into a different system, not an export to Excel. These are the kinds of things we find as we really understand our users rather than simply take requirements. Outcomes over Output It is very easy to get caught up in the output. Output is easier to commit to and easier to measure. Delivering a feature is easy to understand. We committed to a feature, we built it, and now it’s out there. Done. But this kind of thinking the creates poor experiences or features that no one uses. Rather than simply building features, we need to focus on the goals we’re trying to achieve. Building a feature is only part of that. We have to ensure that the feature helps us reach the goal. If it is meant to get more users, did it achieve that? If not, what is our next step to achieve the goal? This is a major focus of our roadmaps, and what we’re trying to achieve with a good strategic roadmap. I wrote about this at length here, so I won’t belabor the point. But the focus should be on outcomes rather than outputs. Value over Estimates Along the same lines as the above, it is easy to get into a vicious cycle of estimation, sizing, etc. This seems to be intended to give comfort to teams and managers that everything has been estimated and will only take X weeks to complete. But the cycle gets worse as initial estimates are missed, forcing everyone to participate in more meetings to determine why the guesses were wrong and how can we make better guesses in the future. This, of course, leads to missing more timelines, creating more meetings, and on and on and on. Do we really want our teams to be experts on guessing (if that’s even a thing)? Or do we want them to be experts on delivering value? Because we tend to put a lot of emphasis on one over the other. I’ve even heard it said that the mark of a good team is being able to give really accurate guesses. I’d argue the mark of a good team is being able to quickly and frequently deliver value to users. I’ve found that this type of focus on estimates and timelines can actually be a substitute for delivering actual value. In my experience, nothing has quieted the calls for estimates and projections like delivering actual results. It’s certainly no silver bullet, but can help us make significant progress. So if we could take back a little bit of the time we’re committing to estimating and projecting, and use that to start to deliver small increments of value to users and stakeholders, maybe we can get out of the vicious cycle and focus on what we’re all trying to ultimately achieve: delivering value. Shared Understanding over Comprehensive Documentation In his book User Story Mapping, Jeff Patton gives some incredibly useful advice when it comes to documentation, particularly around requirements and user stories. First off, “You and everyone else will learn that stories aren’t a way to write better requirements, but a way to organize and have better conversations.” The purpose of stories isn’t to have some sort of complete documentation of the requirements on what to build (see above), but they are the starting point for the conversation. The goal is to get to a shared understanding. Again from Jeff, “Stories get their name from how they should be used, not what should be written.” Most of us are probably familiar with the format of a story: As a [user] I want [a thing] so that I can [accomplish something great]. But it’s not about the format. It’s about the conversation. It’s still far too common to think of handoffs between groups as the way of doing things. Siloing people into buckets/areas of responsibility that don’t cross over. The stakeholders give requirements. The product manager documents them. The team builds it. But that is how terrible software gets made. What we need is more collaboration between groups. The product manager should facilitate the understanding. The development team should be involved early on with stakeholders and users. The right solution is a joint effort, not a series of orders or handoffs down the line. This goes not only for the stories, but also for acceptance criteria. Too often we look at acceptance criteria as the final word on what should be built. But the same theme applies. If acceptance criteria are created before a shared understanding, they’re likely to be wrong. What we need is team collaboration on what is being built. And that’s not to say that good acceptance criteria for features aren’t important — they are — but rather that they shouldn’t take the place of ongoing conversations and shared understanding. Just-in-Time Refinement over a Comprehensive Backlog Another concept I’d challenge is the idea that a team should have months of refined stories ready to pull into sprints, so that the next few months are planned and ready to go. Again, not that I’m opposed to the principle of planning and refining. I’m actually in favor of both of those things. But do we really know exactly what we should be working on in a few months? If we plan out all the details today, do we expect there will be no changes in 3 months? No learning that will take place between now and then? A better way is to get continually more granular as we get closer. We can certainly have a plan for the next few months and next few releases. Even to the feature level. We should be looking ahead and understanding upcoming needs and priorities. But shifting focus from our current priority to the planned priority 3 months from now, and trying to get the same level of detail for both, is the wrong focus. We can’t, and shouldn’t, think that we can fully prepare stories and development work, then let it sit for a few months, and simply pick it up and begin coding when its turn comes. Rather, our energy is much better spent on the specific details of the very near-term, the broader details of the short-term, and the strategy of everything beyond that. High-Integrity Commitments over Comprehensive Project Plans All too often we fall back into the trap of putting dates on every possible feature and commitment from now to the end of the year (or other time period). The idea of a comprehensive project plan that will guide all our work and hold the team accountable is fraught with problems. In one of my favorite product management books Inspired, Marty Cagan talks about high-integrity commitments. The idea being that we shouldn’t be putting dates on every single thing we do. Rather, we should only be making commitments to dates when it is necessary for a very good business reason. And when we commit to dates, it’s not a wild guess, but a well-researched and understood date that both sides can agree on. And we do this only when it is crucial. That way commitments to dates are meaningful. Again, we put the focus on the outcome we want to achieve, not the output. And we don’t drive our teams to exhaustion with endless dates. We make and keep meaningful commitments. And they are meaningful because they are not the norm. Real-World Experience over Textbook Simplicity Finally, every approach needs to be modified for the context it’s being used in. There is a ton of great advice out there, and many great examples of how to do things well. But almost everything will need to be modified and adjusted for the world you’re working in. It is one thing to understand the principles and methods. It is another thing to appropriately apply them to the user cases and business problems you’re solving. That is part of what makes product development and product management such an exciting and difficult thing. It is as much art as it is science. There isn’t necessarily one “right” way of doing things, as much as we may want to think that. It is a balancing act. On one side there may be folks who say things like “that will never work here.” On the other side, there are folks who say things like “all you need to do is XYZ. It’s easy, I’ve done it before.” Be wary of either mindset. While we want to continually push for best practices, some of them need to be modified to fit. But that certainly doesn’t mean it can’t work here. At the end of the day, the goal is to improve the lives of the users of our products. But we often can get caught in mindsets that keep us from achieving that goal as effectively as we might otherwise be able to. Often we have to get out of our comfort zone, and help others get out of theirs as well, in order to do great things.
If I could pick one thing to kill because of the problems it causes, roadmaps might very well be at the top of the list. And it's not that I don't like roadmaps, or at least the principle of product roadmaps. It's the misunderstandings that they bring. Sometimes the misinterpretation of a roadmap actually causes far more problems than the roadmap sets out to solve. Why is that? And what can we do? Purpose of a Roadmap The first thing is to really understand the purpose (or purposes) of a product roadmap. Fundamentally, a roadmap is a strategic document used to create the overarching product vision, articulating the value you're delivering to users and the business in order to gain support and alignment. I break this down into a few key categories:
All of these pieces are crucial, because a roadmap is a living document. The purpose of a roadmap isn't to create an artifact that we can refer people to or post on a page somewhere. The items above are a continual loop as we learn iterate. By creating the vision, having the right conversations with users and stakeholders, and adding the learning that we get as we progress, we can continually refine our direction and plan for the future. So Where Does This Go Wrong? The purpose of the roadmap sounds great. Who doesn't want to inspire their users and stakeholders while ensuring everyone is strategically aligned? Why would anyone want to kill that? Where does this go wrong? A roadmap is not a project plan. Far too often a roadmap gets confused for a project plan. A roadmap isn't meant to be the detailed execution of specific projects. It's not meant to commit to dates for releases or timelines for features. There is certainly a place for that level of specificity, but it isn't the roadmap, especially as we look several quarters into the future. A roadmap is not set in stone. This is probably one of the biggest problems that many of us have faced. Far too often a plan is put in place at the beginning of the year with themes or focuses for the entire year. And we get stakeholders or users who view the roadmap as a commitment to those specific items, even if we find we need to pivot along the way. This problem is exacerbated when the roadmap becomes a project plan with specific features called out far in advance and commitments to them made with dates. See this article for more about keeping a product mindset. A roadmap is not a list of features or requirements. A roadmap should be strategic. It should be focused on the vision and direction of the product, and the problems we're solving. It is about the value we're delivering, not necessarily the features. While it certainly is okay to talk about features on the roadmap, especially the near-term features that we're confident in committing too, it's important to caveat specific features with the understanding that the features are meant to solve a problem or achieve an outcome. We aren't simply delivering a wish-list of features. Key Principles Now that we're clearer on what a roadmap is and isn't, what can be done? How can we craft roadmaps that fulfill the needs of users and stakeholders while still allowing us to learn and iterate along the way? No two roadmaps need to necessarily be the same. And I won't advocate for any specific template over another here. I've used variety of different types of roadmaps and they all have benefits and drawbacks. There are a few key principles that are true of most roadmaps.
An Example What I have done with my roadmaps, and what (fortunately) seems to be becoming more and more common, is something like below (this is very simplified, but has the key ingredients): One of the key features is the focus on themes. This has been critical in aligning the product team behind a common goal. It's also incredibly useful for discussion and alignment. When we introduce the themes, it opens the door for discussion around the possibilities. For example, if the goal is to launch to a new group of users, the themes may be focused around the key items needed for that group to successfully adopt. Knowing that this new group of users needs the ability to create portfolios then becomes a theme, with potential features or ideas that we can implement in order to make that happen. The exciting thing about this structure is that it doesn't tie us down to any specific path initially. The goal is clear and the metrics are clear, but how we get there is open for discovery and experimentation. We aren't tied to a specific feature if that's not the best way to solve the problem. In the case of portfolios I mentioned above, the solutions may involve building that functionality, integrating with other applications, or finding some other way to fulfill that need for the user. A portfolio may not be the right answer at all, which is why we do discovery around the theme. Of course, as we get further down the road, our level of specificity decreases. We simply can't know a year in advance what the solution to those problems will be. Or even what the most important opportunities will be at that time. We can certainly have some ideas and don't need to be afraid to share them, but we can't tie ourselves down to a particular course so far in advance. A good roadmap helps paint the vision and strategy for the product. It outlines the key goals, often by quarter, and shows themes or opportunities that the team will be focused on. If you're interested in diving deeper into roadmaps and alternatives to the way roadmaps have been done for a long time, I'd highly suggest Product Roadmaps Relaunched, which has a lot of great tips on better ways of doing roadmaps. Ultimately a roadmap is about creating a shared understanding with our team, our users, and our stakeholders. It is not about creating a document in a specific format or with specific pieces. Part of that shared understanding needs to be that we will learn and iterate as we go. We're focused on solving problems, not releasing features. And while we may have talked earlier about a specific feature, if we can find better ways to solve problems and deliver value, many of the specifics may change as we go. Our roadmap is meant to help facilitate that understanding between groups and ensure alignment. It is about the vision and the value of what we're delivering. So hopefully more roadmaps can become helpers, rather than hindrances, in getting us to those end-goals. Roadmaps can be a critical tool for progress in product development. Even if we have a love/hate (& hate) relationship with them sometimes.
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. 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. Over the past two months, we've been relentlessly working on building our backyard. And as I got ready to post some finished photos of it, I realized that I should write a little bit about the journey as well, since it has been non-stop work for weeks.
So before we did anything else, we knew we needed to get some concrete poured. And if you're going to do, might as well do it right, you know? So we went all in for a new patio, a parking pad, and a shed pad. Basically just making the whole yard concrete, as a few people joked. And it turned out great. We still have big plans for this space, but more to come on that later.
Fortunately, I didn't have to do it alone. Grandpa was here to supervise and to help lay pipe. And the kids were out most evenings cheering us on as we moved as quickly as possible. (We gave ourselves a week to do all the sprinklers and get the grading done before the sod came, so it was quite the race). In our old house, the sprinklers didn't reach all of yard, so we had to do a lot of watering by hand. We wanted very much to avoid that, so we put in a lot of sprinklers. Like, a lot. Enough that a few minutes per zone would be enough to keep the lawn nice and green. It is overkill without a doubt. But I'd rather have that than the alternative. We also got a smart controller, which I can't recommend enough. Being able to test out zones from your smartphone is awesome. We'll be replacing our other controller soon so that we can control all sprinklers from our smartphones.
Part of the kids excitement was also due to the fact that they knew that once grass got put in, they were going to get a playset. We purchased a kit a few months ago and it's been sitting in the garage. And a couple times a week the kids have been asking why it hadn't been put together. "That silly daddy, he hasn't built our playset yet." That's what I've been living with for months now.
A few more evenings of work though, and we had it all done. And following a terrible tradition of doing outdoor projects on the 4th of July, we put down the rubber mulch after the parade. And with that, the first phase of the backyard is just about done. The grass is in. The playset is built. We planted lilac bushes along the back for privacy. Next up, we'll be putting in a fence and doing some additional finishing touches along some of the side and back.
But at least we now have a usable, fun space for the kids. 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.
|
AuthorMy personal musings on a variety of topics. Categories
All
Archives
January 2023
|