3 Problematic Product Manager Job Structures and How to Correct Them

0

The sweet spot of product management is in the middle of design, business and engineering. The reason for this has been widely discussed and detailed by many successful thinkers in the product management industry. The thinking essentially boils down to the fact that the product manager job adds the most value to the organization by sitting between cross functional areas in order to ensure that all these groups work together to drive the product vision and customer happiness. Think of it like this, in order for a product to be successful in market there are many pieces that all need to come together holistically and with a single vision in order for a product to be successful. This article details 3 of the most problematic violations of this product manager job structure, and how to fix them. Arms of product management

  1. Marketing
  2. Go to market
  3. Product vision
  4. Engineering/build
  5. Design
  6. Usability
  7. Data
  8. Voice of the customer
  9. Finance
  10. Operations

Because all of these functions need to work hand in hand with unified product goals it is the product manager’s job to make sure that this happens in a way that the product is successful, e.g. it makes money and customers like it. That’s the job.

However, the challenge I’ve seen in the organizations I’ve interviewed in, worked in, and researched, is that in response to the massive potential scope of the product manager job the role has been broken up into multiple roles. At first glance this makes sense, it seems impossible for one person to manage all these separate arms effectively. So what happens is that the product manager is responsible for components and other teams are stood up to manage other areas of this remit. But the difficulty comes in when the product manager doesn’t have view into these other functions. If the product manager isn’t able to look across and ensure that cross functional collaboration is happening to guide the product vision holistically to success, there will be problems in the product.

In this article we detail the three most common organizational mistakes that can arise with the product management role. The issues resulting from each of the three organizational structures is unique, but the advent of each of the problems is similar. An organization feels that a product manager should be responsible for ‘x’ and not ‘y’ and some other role should be responsible for ‘y’. But the fracturing of the product management purview creates siloes that hurt the product profitability and customer experience.

Product Manager Job Structure #1

Product Manager Job Structure Problem #1: too far from the business

The first dangerous product manager job structure happens when the business is too far away from the product management organization. While this isn’t the most common challenge covered here, it’s extremely dangerous.

This product manager job construct is more likely in the “new” world of agile product management, where an agile product manager is more likely to be close to design and engineering but can be far away from the more strategic planning and business development in the organization. An agile product manager is busy leading their teams by grooming the backlog, prioritizing work in flight, decomposing new work, and ensuring the team is catching dependencies early. With this execution focus on work in flight the product owner can start to lose the more strategic part of the job, which leaves a gap in strategic planning for the long term success of the product.

While it’s understandable that the agile product manager is focused more on the work in flight, it’s crucial that this role is also driving strategic planning for the long term success of the product. Nobody in the organization has a better understanding of the product needs than the boots on the ground working team, and this is a critical perspective to have influencing the long term strategy.

When strategic planning is happening at another level or elsewhere in the organization the problems manifest in the work that comes to the working team. The product manager will start to have less and less say in the work that is important, and will be seen more of a fulfillment engine for the needs of the business. This makes the the product manager job feel a bit more like tech operations, ensuring that the team builds what is requested, than a product manager job. This is dangerous not only because it means that the business is not leveraging the talent for strategic planning that the digital product manager they hired to do the job has, but also much more.

The problems

  1. Strategic direction — the business is where strategic planning for the company happens. Without integrated closeness between the business and product there will be a lack of insight and input to the direction of the company. Not being able to influence this strategy leaves out a critical product perspective resulting in the company moving in the wrong direction for the customer, and ultimately the business.
  2. Financial — the biggest problem with this product manager job structure is that when the product manager is far from the business, it means it’s far from the financial goals of the business. Thus, decisions made by the product team will be made without understanding the impact to the company’s bottom line. This lack of financial sense in the product cycle is dangerous in creating products that make money.
  3. Leadership visibility — from a career development perspective, the business is where much senior leadership and C-level executives are. Not being close to the business means that the product manager and the product team will have less access to the senior leaders that they want to impress. Also, the leadership will be disconnected from the work in progress and the struggles of the product development engine. This disconnect will hurt senior leadership’s ability to tune the engine and ensure that high quality products are being built.

How to fix this product manager job structure

When product management is clicking with design and engineering but struggling to get upstream to hear and influence the strategic product planning in the organization, the first step is to make sure that leadership understands that this is a gap that will manifest itself in the product and product profitability. Be clear that in order for overall product success, product management needs to be included in the conversations determining the overall product roadmap.

After senior leadership buys into including the full product organization in the strategic discussions they will likely ask you how it can be accomplished. The first step is to identify where in the organization strategic product related conversations are being had and include the product organization in these. It’s possible that conversations are happening in lots of different places and different groups, and are not being centrally discussed and prioritized according to similar metrics. If so, then there needs to be a more central discussion on the business and product priorities so the groups can weigh in and discuss all the initiatives that can drive the long term success of the company’s products.

Once there’s a central conversation to discuss the list of potential strategic initiatives, a single forum has been created to discuss the opportunity costs of taking some initiatives and not others. The critical final step to this is that there needs to be a few jointly agreed metrics that are comparable across initiatives in order to truly create a level playing field. It can be as basic as a scale from 1–5 for build effort required, expected revenue, cost save potential, and customer satisfaction impact. It doesn’t need to be complicated, but it needs to be agreed to and accepted by leadership decision makers.

By mapping the impact across each initiative in a meeting or meeting series, driven from the various product and business organizations, all working together jointly in the strategic planning of the organization, you will have solved the problem with product management not being included in this strategic planning and as such gaps will close in your product cycle.

Product Manager Job Structure #2

Product Manager Job Structure Problem #2: too far from design and data

In this context I am using design and data in the broad sense including UX, voice of the customer, web analytics and the broad set of data and design functions. Between design and data the goal is understanding the customer and design the product for the needs of the customer.

What can happen structurally is that the design and data functions get a bit too far from the product manager. When data is scattered or design isn’t integrated into the phases of the product strategy and delivery cycle there is substantial danger.

This structure is common when accountability for data and design functions are not clearly defined. If it’s not clear who is responsible for doing the design work or pulling the data gaps will appear. It’s also common for gaps to appear when data or design are being used, but it’s being shared in a separate design or data specific stream directly with senior leadership and is not making it into the product development cycle. Data and design output does little good if it’s not ending up being integrated to the product cycle.

The problems

  1. No vision — without strong data, data analysis, design and usability support the product will lack vision. A product manager can create a vision but it will be loose and lack the support it needs because the data and design feeds that vision statement in such a critical way.
  2. Misguided vision — without the right access to customer data the vision determined by the product manager will likely be misguided. Understanding the customer comes from poring over customer data streams for hours and connecting the dots around how customers are currently using the product and how it can be better. Without data the vision will push in the wrong direction.
  3. Poor usability — not having design close to the product delivery cycle will lead to decision making without usability support. It’s not always clear which questions to defer to usability for, and when that support isn’t there throughout the process the usability of the overall product will suffer.
  4. Lack of customer understanding — one of the most egregious downsides is the fact that without a close relationship to design and customer data there will be a lack of understanding from the product team about how customers are using the products, and no line of sight into who your customers are. In order to build a great product it’s absolutely critical to understand your customer set deeply, whether you’re building a credit card or a pair or shoes or an app. As a product person, you need to live and breathe customer data, and not being close to data or design means that line of sight is murky or broken.

How to fix this product manager job structure

As product managers, we expect to have access to data and design in our roles. We expect to have the ability to pull and get as much data as we want and need, and to have the support we need to do advanced interpretation if necessary. In this day and age data needs to be infused throughout the language of the product and business and design organizations. Data is the foundation of nearly every conversation across the company.

In terms of adding data fluency to the repertoire of your organization the first step is making sure that the data is getting out there. Reports are a great place to start. However, getting data is only the beginning. Once you have data it needs to be developed from the ugly data pulls to consumable charts and graphs from which insights can be gained. Companies often get stuck in different stages of their data fluency journey. If you’re stuck with useless daily data reports with little to no interpretation then you’re likely in an organization that needs to push through to the next stage, actually using data to gain insights and make decisions. We’ll have a more detailed post on how to assess your companies data fluency from the product manager viewpoint and how to drive change in a separate post. But, at a high level you will need to continue on the path towards reducing the daily reports of useless data and focus more on fewer reports with genuine insights and the decisions being made based on those insights.

For building closeness with design it’s a matter of having the right people in the organization and getting them integrated into your product development cycle. The first step is obvious, if you’re having trouble with usability and you don’t have a large enough set of usability designers in your group then you have a personnel problem. However, if the personnel is there then it’s more of making sure that they are getting integrated in the cycle in the right place. Often, design is included more high level at the strategy phase but is not involved after build begins. One simple way to ensure that design gets more integrated is to include them in sprint demos. This will allow them to see if the design vision is being executed as they expected, but it also allows them to see how it’s being built to provide feedback about changes as they’re seeing it in real code, which may bring up new changes.

With these tips you’ll be able to infuse data into your organization and bring design and usability closer to your product. This will mean happier customers, more revenue and better product quality. That sounds good, right?

Product Manager Job Structure #3

Product Manager Job Structure Problem #3: too far from engineering

This product management organizational structure is most common in old world companies still running waterfall methods. Basically, what happens is the “business” is still in the habit of writing absurdly detailed “requirements” and shipping them off to be built by engineers. Then it takes several months while the engineering team builds the product to the requirement set. The engineers may come back with some questions, but ultimately they are relying on the requirements to detail what needs to be built and their direction is to build exactly what is requested.

The problems

  1. Takes a long time — because there is little discussion with the engineering team before build begins, the business generally writes requirements with little understanding of the engineering impact. Thus, projects take longer and cost more than originally intended.
  2. What you get back is wrong — there’s so much room for interpretation with a list of requirements that misunderstandings are bound to happen. In many agile training courses they perform an exercise where you are forced to describe a shape or impact to someone else and then they draw what you’ve described, to hilarious results. Human communication is just too difficult to get right on the first shot.
  3. What you get back is incomplete — while the team is plugging away working they are not focused on the overall business need and they don’t have that vision driving them as they work. Thus, frequently there will be mistakes because something small that may have been implied in the requirements wasn’t built, or because there were minor gaps in the requirements. It’s quite common to get back a product that is missing core elements.
  4. Lots of defects — frankly, when I’ve seen this old world where the business delivers requirements it always come with a timeline that requires a massive engineering push to hit the date. This structure of picking a date ends up pushing engineers to pull all nighters near delivery dates and just “get it done” which ends up meaning sloppy, defect ridden code.

How to fix this product manager job structure

The first thing to do is recognize that this old world structure of building products doesn’t work in this new age of technology that requires getting to market quickly. This needs to be acknowledged not at the engineering and product management level, but at the CEO level. Fixing this problem right means everyone all the way up needs to be on board because it requires massive change. Chances are, the C-level managers will be on board because this organizational structure usually has massive tech waste because of the length of development time, and high defect rates make it an inefficient process to manage.

Once the whole group recognizes the need to change, step 2 is to build communication and trust between the teams. This is a core tenet of agile and the most crucial step to start driving change at the team level. A new process does nothing if the teams are fighting and hate each other. Have team building between the business teams and engineering. Have them co-located, have them take roles across the wall and invest in improving collaboration. Then, have that collaboration start going throughout the entire build process. Make sure that engineers are sharing their work every two weeks. Even if it feels awkward, and even if they’re not sharing much. Build that communication.

As the communication starts to build you’re on your way to catching defects and ensuring better efficiency with your product build cycle. The next step is to try to build process around this from the ground up. What has the communication uncovered? Does the engineering team want to be included in the strategy conversations that take place upstream? If so, start including a few of your all star engineers in those early conversations and see how it goes. Do the product managers want to be included in the ongoing engineering conversations or do they care more about having bi-weekly demos to check in on the progress to make sure everyone’s on the same page? Let them try some new things and then implement processes around what’s working.

This may seem overly simplistic, but in reality this change is incredibly hard and it’s a lot easier to write than to do in reality. These changes are massive and they have to be done in the right way for teams to be willing to adopt change. You’ll need to make the decision about what works for your organization. But, the key from what I’ve seen is communication and openness to collaboration and change. If you can build that and work towards change that the teams all agree on then the organization can move swiftly in the right direction. If you aren’t there with the communication, you cannot yet jump to later steps. In my experience it just doesn’t work. If your teams are truly not collaborating then focus energy on getting collaboration going. Collaboration is the key to solving this challenge.

The three dangerous product manager job structures detailed in this article can end up with prolonged losses and decreased use of your products in market. If you see these structures in your company or in a company you are interviewing with beware. It’s a challenging road to fix, and while it’s certainly possible each of them take significant leadership support and time for organizational fixes to take hold.

Share.

About Author

Co-founder of productmanagerclub.com, ex-Audible (Amazon), currently living in Dubai leading product transformation with TribalScale. Product manager with 6+ years in eCommerce, FinTech, and digital media.

Leave A Reply