While most clients have a clear understanding of whether they need design and engineering teams, they are often unsure whether they need a product manager. At Def Method, we staff projects with a combination of a Product Manager, a Designer and/or Software Engineers.
We’ve seen first-hand what projects can look like when one or two of these disciplines are missing and have learned some of the common patterns that emerge when product management is absent, or ineffective.
A quick reminder: What is a product manager?
In a nutshell, a product manager is responsible for figuring out the most important thing to build, and for positioning the designer and engineers to build this thing incrementally while taking on the least possible risk. They ensure that the team is solving the right problems for users and aligning their work with the most critical business outcomes.
Want to find out more about what, exactly, is a product manager? Read this article to find out.
Why can’t I just use a project manager, a product marketer, or a business analyst?
Product management is part art, part science and 100% a full-time job. Even if Marj from marketing has what it takes to manage your product, is your business prepared to deprioritize her marketing responsibilities in order to give her role as a product manager the attention it needs? In our experience, when a client dedicates a great product manager, their collaboration with our designers and engineers delivers tremendous outcomes.
Dedicating only a portion of a person’s time to product management, underestimates the bandwidth required and misunderstands the scope and the skills needed for an effective product manager. Just changing the titles from project manager or business analyst to product manager without giving the person tools and time to act effectively in the role is unfair to the person placed in this role, as well as the product and the team.
To help you understand whether you need to dedicate a qualified product manager to your project, here are 7 signs to look out for:
The development team doesn’t understand the Vision and Strategy
When people on the team do not understand the desired business and user outcomes that their work is laddering up to, there is likely no strategy or vision shaping the work, or no one is communicating these to the team. The decisions they make will not account for the larger picture, resulting in work being undone or redone regularly.
A team needs technical decisions that can be built upon, and without a clear strategy they will end up redoing work too often and wasting valuable resources. Moreover, for product and design, shortsighted decisions make it difficult to build towards a larger whole, forcing us to significantly refactor the user experience as we move through our roadmap.
Without a product manager there to develop and socialize the vision and strategy for the product, engineers and designers run the risk of blindly following defined scope without thinking about the broader needs of the user and usage context. Having the broader context guides the team towards providing the right journey for the user.
A lot of this comes down to communication. A good product manager will know how to get the development team to connect with the “why” behind what they are building. Unlike leadership, they are in constant contact with the team and deeply connected to the work they are doing, ensuring that the vision and strategy always remain top of mind. If an engineer knows the why, they can think critically about what they are coding towards and clarify gaps, risks and assumptions with the product manager and designer.
The wrong things are getting prioritized
We all ship features that miss the mark, but this should be a relatively rare occurrence. If you find the team shipping features that do not achieve the intended outcomes on a more-than-rare basis, chances are that you need a dedicated product manager in the mix to better manage the team’s priorities and validate features before they are built.
Product managers push the team to clarify any assumptions they are making about a feature and how users will engage with it, and will systematically test the riskier assumptions before a feature hits the backlog. This validation through user research and experimentation is key in reducing the risk of investing development resources on failing features.
Product managers also create prioritization frameworks that ensure that priorities are being set based on user and business value. A good prioritization framework is grounded in the future vision, asking what the key outcomes for the users and business are, and which features will support these outcomes. Understanding the vision helps with prioritization and saying no to tempting features that would not contribute to the outcomes.
Decisions are made arbitrarily
Prioritization frameworks are especially useful and effective when speaking with key stakeholders who might have strong opinions on what is most important to build next. Taking any idea or potential solution through a prioritization framework helps align it to strategic intents, and brings the team to a consensus on whether it is important to build now.
Without a product manager, realizing whether decisions are being made arbitrarily is often a chicken and egg problem. If decisions are reversed all the time, that’s a trailing indicator that decisions were made arbitrarily. However, the problem can also be identified earlier; if the person who made the decision cannot indicate why that decision was made over another one, that’s a leading sign they have not been thorough and objective in the decision making. Sometimes, it’s good for decisions to be made quickly, especially if the cost of reversing the decision is small. The product manager ensures no one is making quick decisions that are difficult to reverse. A great product manager is always looking a couple of steps ahead: “If we do A, and we were wrong, what would we have to do to go back and make it B, instead? How much effort would that be?”
Watch The Product Decision Stack, by Martin Eriksson.
Engineers are blocked
There are many ways engineers can get blocked. Blockers can include dependencies on other teams, missing designs or other assets, or having no clarity on the feature, to name a few common ones. Having a product manager becomes crucial in getting those blockers resolved swiftly and with limited distraction to engineers. A product manager generally has relationships across teams and roles. They can hone in on the blocker and work with others to unblock it. For example, a product manager can talk with other teams or push a designer to make a decision. Product managers tackle blockers of all shapes and sizes, so that engineers can focus on doing the work that only they can do. If you hear of engineering (or design!) work being blocked, or if you observe that the team’s velocity is lower than you would expect, chances are that a product manager would help get things back on track.
It’s unclear whether shipped software meets user needs
This happens all the time. You thought the “improved” signup flow would increase your conversion rate by 30% or the new widget would double referrals, but the features were shipped and the team moved right on to building the next thing–without stopping to measure impacts and use this data to inform what to build next. We see this happen with entire products too. Without a product manager, this can be tricky to spot, because no one is developing clarity on the most important outcomes and a hypothesis about how features will impact those outcomes. There shouldn’t be a debate about the success or failure of a feature after it’s been shipped. It should be mathematically and systematically assessed through product analytics. Even with that clarity, you can fall into the trap of thinking that just one more tweak on the feature will get you where you need and keep investing in a dud feature.
A great product manager not only increases the likelihood that what you build meets user needs and helps you reach your business goals, they make it abundantly clear when this isn’t happening so that course corrections can be made.
Parts of your product are unusable because you aren’t sunsetting features
Sunsetting features is hard and even established companies struggle with this. The team and stakeholders become attached to what they built (and believed in!) and the sunk cost fallacy is in full effect. The product’s users suffer as a result because they have to deal with the cognitive load of ignoring functionality they don’t need, to get to the functionality they do need. We recently worked with a company that had over 30 products and hundreds of features. Thanks to analytics, our product manager was able to show the company entire products that they needed to sunset because they simply were not being used. People on those teams objected, “but I think if we just add X, Y and Z people will start using it!”. They were proud of what they built and didn’t want it to go to waste. The end users suffered and they lost customers who opted for competitors’ more streamlined and less complicated user experiences
We have seen so many teams like this one succumb to the sunk cost fallacy, unwilling to pull the cord on work that has already been put in, even if the feature isn’t meeting its intended goals. Though not the most popular job function, a great product manager will make sure that features do not sit around, simply because they have been built. They set goals and paint a picture of what success looks like for the feature, and develop a decision tree that details the situation in which the feature will be removed entirely. They get stakeholders and the team to buy into that decision tree so that once the product is shipped, we can measure and follow the decision tree we created. The decision to sunset should be made as objectively as possible so that egos and politics are removed from the equation. Sunsetting features is something to celebrate–you learned something new about your users and have made a decision that will improve their experience. These are good things(!) and a product manager can help the team see that. Read more on the sunk cost fallacy.
You aren’t shipping software early, often, and incrementally
The risk of wasting resources on failing features increases the longer you wait to release the working software to users. We’ve seen teams put off shipping for a variety of reasons, none of them reason enough to accumulate unnecessary product risk. Common excuses include, “just shipping X will disappoint our users, so we should be sure to only ship when we have X, Y, and Z!” or “we don’t want to have to teach users about new things all the time” (agreed… but a good product is intuitive) or “shipping is time-consuming, if we only do it once a month/quarter/year then we save the team time to build more features”. On the surface, these might seem like good reasons to not ship software. But, most companies simply can not afford to accumulate product risk regularly and this is exactly what delayed shipping does.
A product manager is well aware of this reality and works hard to break features into thin slices of value that can be shipped to users in an iterative manner. They ensure that the right feedback loops are in place so that iterations are informed by quantitative and qualitative insights into how the earlier iteration is being used. They remove unnecessary processes and bottlenecks in the release process so that shipping features become a routine non-event for the team.
Nine times out of ten if you’re building software, you need a product manager. They are best equipped to prevent these problems from occurring. When others on the team take on these product management responsibilities (because somebody has to!), their other work suffers. Furthermore, they risk performing the product management duties improperly and cutting corners. We recommend discussing these signs with the software development team and having an open conversation about whether these problems are cropping up in your organization. The good news is that you now know the first step in addressing these issues—add a great product manager to the mix.
Discover more content on Product Management. Use our Content A-Z to access even more insights.
Comments
Join the community
Sign up for free to share your thoughts