Product Management Advice From the Trenches
If you’ve read my blog for the last two months, you’ve probably noticed a pretty consistent theme: I’m a big believer in the strategic importance of product management in an early stage software company.
If you’ve missed out on my previous posts, don’t worry. You can click here to catch up. In that series, I also broke down the key role and components of a highly-effective PM division, and shared a Product Management case study (here and here) provided by the VP of Product from one of OpenView’s portfolio companies.
All of those posts addressed the fundamental concepts of Product Management and laid out how it can positively impact overall business strategy. They were intended to be more conceptual and instructional, and I hope they were at least somewhat helpful.
But now it’s time to offer some more practical, real world advice.
Over the next few weeks, I’ll share a series of interviews that I conducted with experienced product leaders in our portfolio — people who have made building and running a PM group their career and their passion.
First up is Kristy McKnight, the VP of Product Management at CentralDesktop. Kristy has served in similar roles for Intuit, Match.com, Networks In Motion, and TeleCommunications Systems, so she certainly understands the need for technology companies to build a well-aligned, highly focused Product Management team.
As a product leader coming into an organization without a Product Management function, what are the challenges?
There are quite a few, but the first is that you have to figure out what exactly you’re solving for. Until you know that, you don’t know what specific skill sets you need to hire in-house to achieve that goal. So, for me, the ideal way to begin is to start with the company aspirations, goals and objectives, and determine how the product fits in and needs to support them.
For example, one of our goals is to pursue a segment specific go-to-market strategy. Ultimately, that gave product management the goal of delivering the complete product that serves the specific needs of the target segment.
The next step in setting the PM function is to give it the appropriate ownership over the product and the outcomes of product decisions. That can be a tricky transition. In situations where you’re setting up a new PM function, the responsibility of product management tends to be shared between the CEO/CTO, marketing, engineering, and sales, typically in an ad-hoc manner. So the challenge when you get started with Product Management is showing those team members the benefit of passing ownership to the PM and having the trust that a formal PM function will improve the efficiency and performance of the overall operation.
What are some of the things that other functions need to let go to PM, without losing the collaborative aspect of product development?
Bug fixing is a big one. I went into one organization where engineering controlled the product development backlog. Their priority was very product-centric, and that drove the decision to fix every bug regardless of its nature. In reality, every bug didn’t need to be fixed. So I had to change that mindset to one that started with the product strategy, customer priorities and product roadmap. The roadmap then determines the priorities. The priorities then determine the priorities of bug fixing.
It’s not that there’s a massive resistance to Product Management. It’s that, a lot of times, other departments don’t fully understand the benefits that it can bring. And one of the key benefits it does bring is the holistic translation of company strategy into product strategy.
Isn’t another common problem the misalignment between sales, marketing, and product management? For example, a feature that could help close one customer may not be a feature that could be sold to others?
Absolutely. That comes back to how salespeople often operate and why it’s not an efficient way to run Product Management. For salespeople, what happens in their last two or three calls is what’s most important to them. But it’s on Product Management to keep everything in context and prioritize work on broader needs or larger opportunities.
For software companies, from the startup phase to the expansion phase, this tends to be a typical transition. At the startup phase, the priority is on revenue generation, regardless of customer segments. This puts sales in a strong position to drive the product backlog, and can often result in feature rich products that are not customer segment specific.
As the company enters the expansion phase, it starts to realize that building features for every customer is not scalable. That’s when product management becomes a critical function, and the center of balance shifts from sales to PM in determining the product features.
How do you organize Product Management from a structural and staffing standpoint?
It varies by situation. When I’ve had a single application in the past, I’ve broken it up by major feature groups and had people own individual components. With a single application, it’s really about breaking it up by feature group. You need to look at the application itself and identify major feature sets that can be completely or somewhat isolated. That allows for clearer objective setting and better allows you to measure success. Also, with a single product line, if there’s a global marketing component, then having someone focusing on the localization of the app has also worked very well for me.
But holistically how is a PM group structured? How do you approach the whole team?
Generally, from a structural perspective you’d have a product leader, a product manager (or a group of product managers) responsible for the requirements and figuring out the roadmap.
Then you have a team member responsible for user experience. The best way I’ve seen that work is to have someone in a small team who is both a designer and really good with interactive design. If you have two people on UX, the one with more experience should focus on research and a lot of work in the actual UX area, and the second position would be more of a visual designer.
Lastly, you need to have an analyst. It’s someone who can go through the data that you’re collecting and make sense of it. That way you don’t have everyone in the organization making their own assessments of what’s being presented in the data and creating mass confusion.
When I say ownership, I mean the pieces that the product managers are driving. So it’s not necessarily owning all the product decisions. The spirit of it isn’t that Product Management is making the decisions and everyone else be damned. But somebody has to drive the product from concept to launch and that’s what I mean by ownership. Someone has to own that process from start to finish. And it absolutely has to be participative and collaborative. That will make it much more refined and team-oriented.
That’ll do it for this post. In Part 2 of this Q&A, I’ll share Kristy’s thoughts on how best to recruit Product Management team members, the perfect profile of the various roles within that team, and how to retain your best employees.
Improving processes, adding more documentation and holding a bunch of training sessions won’t scale a product-led engine—it’s org design that matters.