Sketch Founder and CEO John Krewson Talks Product Leadership Roles:
To build products faster, and to get the most from each iteration of your development, organizations have to put the right people in the right roles. (Also, and I’ll get into this more below, those people have to reside outside of IT.) We still see plenty of confusion about what a product manager does, and how that differs from a product owner.
Anything labeled “product” should support the growth of an app or a piece of technology, whether that piece of tech is intended for internal users (employees) or external stakeholders (customers).
How can large and small organizations nominate the right people to tighten feedback loops and develop better applications?
Let’s kick this off with a baseball analogy.
Mozeliak vs. La Russa
We’re based in St. Louis, so I’m going to frame this discussion by way of the Cardinals.
A few years ago, I saw John Mozeliak speak at a conference. As the then-GM, he talked about how his role differed from the then-manager, Tony La Russa. He put it pretty plainly. His responsibility wasn’t the team. His responsibility was the product of baseball.
His focus wasn’t necessarily on wins vs. losses, except to understand the strategic value of a win or the strategic cost of a loss. Yes, wins and losses matter equally to both guys, but Mozeliak cared about wins because of what it meant for the bottom line of the Cardinals brand. His focus: The strategic value of getting to the playoffs, while still understanding the fundamentals of baseball.
The season and the business of it (how much to pay for a new shortstop, etc.) was/is that role’s territory. On game day, though? That’s 100% La Russa’s job*. They’re both in charge of how well the team does, but they’re responsible for two entirely different aspects of the business.
In my little analogy: Mozeliak is our product manager, and La Russa is the product owner. One deals directly with the team. The other one is always elbow-deep in strategy.
When Is a Product Owner Also a Product Manager? Is that a Thing?
Sometimes, having one person wear both hats is a necessity. When or why do you draw this distinction? It’s a question of scale.
Having these two roles segregated is relevant when you reach a certain number of teams. If you have a single team (whether that’s because you work for a smaller organization, or you’re a member of a small team within a big one), the product manager is the product owner. It doesn’t make sense to draw a distinction.
Two things are important in that scenario. One, establishing the authority of product ownership and, two, the discipline of product management.
Once you reach a certain level of scale, and if you are following this path of organization, then the differences start to become a little bit more clear. And, more importantly, necessary.
The Microsoft Office Example
In our Sketch trainings, I like to use Office as an example. It’s hard to imagine a software product where scale matters more, right?
Let’s say you’re the product manager responsible for looking at the present/future of Microsoft Office 365. You will be analyzing an entirely different set of milestones than what the product owner should be looking at.
You’re obsessed with all of the customer-facing metrics like:
- Pricing
- Market trends
- New target markets
- …and so on
Because the market (and the product itself) is huge, this simply can’t be the same person who is dealing with teams of teams of developers.
The Office product manager is playing a bigger game, making decisions to win against competitive forces like pricing trends, competitors’ features, and mergers and acquisitions in the market.
Product owners optimize and prioritize features based on the pricing decisions and user targets defined by the product manager. In this use case, assume there’s a product owner focused on Word, another focused on Excel, and another on PowerPoint. When there is that much actual software development going on, those roles should be separated.
That doesn’t mean, even within larger enterprise environments, that they are.
Let’s All Say This Together: IT Isn’t Product
Large companies still try to wedge product development into IT. Which is massively problematic. IT shouldn’t be building products, but that doesn’t stop large companies from shoving anything related to development to IT anyway. There’s still this overarching opinion that if it “deals with technology,” it should belong to IT.
But IT is an initialism that was created decades ago. It stands for Information Technology and is responsible for information systems like Outlook, SAP, and telephony. IT oversees different sets of responsibilities, follows other performance metrics, and requires a very different mindset.
Product technology focuses on the aspect of your business that your users and stakeholders (whether they’re internal or external) interact with. It’s an entirely different discipline, funding model, and so on. Product technology requires a different mentality than “I need to do this as cheaply as possible.” IT is always identified as a cost center. When you’re responsible for that (or any) cost center, you’re going to regard product management resources as a luxury.
But, if what you’re working on is the same thing that’s generating profits (in other words, your profit center instead of your cost center), then your focus will naturally be on benefits and features for your customers.
Product managers should be your conduit to and from your customers and your user base. Product managers are on the lookout for what you should be working on next. Of course, IT can make stuff. But without dedicated product management and ownership (even if that’s one person), your products are never really going to align with what your customers want and need.
The long and short of it looks like this:
- Product management navigates the strategic direction of your product.
- Product ownership guides the implementation of that direction.
- Product owners work directly with product development teams to prioritize features iteratively, and maximize the amount of feedback and margin to come out of the equation.
Product Management Is a Discipline
The ongoing debate about where the product manager’s role ends and the product owner’s begins isn’t as important as having a designated product role. Dedicated product management and ownership are vital for your process and to sustain modern software development standards, let alone exceed them.
Where does your organization sit on the “needs vs. has” scale of a product manager? Scaling and optimizing the role can be challenging. Let us know how we can help.
*This is where it gets…kinda weird. The new trend in managing baseball teams has the “front office” manager (Mozeliak) playing a much more tactical role in the day-to-day, inning-to-inning decisions of the games. In our world, we’d call that micromanagement. We’ll see where this goes!
