Steve Johnson on PM roles & responsibilities, strong product cultures, and killing feature factories

Product State Q&A

Steve Johnson is the CEO of Product Growth Leaders, the author of ‘Turn Ideas into Products, and former VP of Product / founding instructor at Pragmatic Institute.
Medium / LinkedIn

EC: It’s 2023 and there’s still much debate and misunderstanding around product management roles. Why is this, and how would you settle it once and for all if you could? 

SJ: Back in the early 1980s, most companies had a very clear job description for those who performed business planning for a single product.

The title: Product Manager.

Now jump to the late 1980s. In his seminal tech marketing book ‘Crossing the Chasm,’ Geoffrey Moore recommended two separate product management titles:

A Product Manager is responsible for ensuring that a product gets created, tested, and shipped on schedule and meeting specifications. It is a highly internally-focused job, bridging the marketing and development organizations and requiring a high degree of technical competence and project management experience.

A Product Marketing Manager is responsible for bringing the product to the marketplace and to the distribution organization. It is a highly externally-focused job.

In 1995, Ken Schwaber and Jeff Sutherland formalized the Scrum development methodology.

And with it came yet another product management title: Product Owner.

The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. Scrum teams should have one Product Owner.

The challenge here is twofold:

1) The Product Owner role is what developers want from a product manager—without regard to what other departments need.

And,

2) Few product owners are empowered to be ‘the voice of the customer.’ They are internally focused with little experience with actual customers. They have become what we used to call a Business Analyst.

When organizations implemented agile development methods, formerly business-focused product managers became technology-focused Product Owners.

Nowadays, we often see the product marketing manager filling the strategic void left when traditional product managers become Technical Product Owners.

There are three necessary roles in product management: Product strategy, product planning, and product growth. In smaller companies, all three roles are performed by one person—which can be a struggle to balance the long-term and the short-term. As teams grow larger, we see these three roles assigned to three people.

• A product strategy person is typically senior. They have business skills and explore new markets for existing products and new products for existing markets. They evaluate metrics to determine which products need additional investment and which need to be retired. 

• Product planning managers work closely with designers and developers to solve a specific problem. Their primary tools are personas, stories, and backlogs. These product professionals develop a deep understanding of the product and its technical capabilities; they achieve this by working with the product, by discussing it with customers and colleagues, and by keeping current on the industry. For a product planning manager, the product almost becomes their personal hobby.

• Product growth managers, often called Product Marketing Managers, are focused on markets, either vertical or geographic. They use their market expertise to empower product management, marketing, and sales with the requirements and language of their market, and they serve as the chief liaison from the market to the company. The product growth manager focuses on sales enablement and go-to-market planning so that when the product is delivered, there are people who want to buy it.

Here's the big distinction to make:

Product professionals are (or should be) focused on identifying, articulating, and prioritizing problems for customers. They evaluate areas of friction for those who buy and use the product and then work with solutions teams, such as development and marketing, to solve those problems.

For example, if a significant number of customers complain about a capability (or the lack of one), a product professional creates a requirement or problem story for the engineering team to address.

Or, if potential buyers are befuddled by the myriad packages and options available, the product professional works with the marketing team to simplify the purchasing process. 

Product professionals are focused on problems, not solutions — and focused on markets, not individual customers.

EC: What is essential to have a good product management culture and an effective product management process / operations?

SJ: There are four things that lead to a strong product management culture.

1. Ongoing collaboration meetings with product professionals

When was the last time your product management team met to discuss product management? Product professionals rarely gather to discuss their challenges, processes, and methods. Instead, they work together primarily in support of other departments, such as planning for sales training or marketing events.

Product managers need to engage with one another frequently to talk about their successes and failures and how they can improve their outcomes. 

2. Frequent, direct contact with customers without a sales or support objective

It’s amazing how few product managers have direct customer experience. And amazing how few realize that this is a problem.

They rely on secondhand information—primarily feedback from salespeople as a surrogate for customers. They are often surprised to learn they should connect with a customer once a week and that many product professionals have a bonus plan tied to customer contact.

If product management is focused on identifying, articulating, and prioritizing problems for customers, how can a product manager represent the customer if they don't know the customers? 

3. Standard processes and common tools 

One aspect of professionalism is standard processes and common tools. Stakeholders are confused when each product manager uses a different format for roadmaps or business proposals. They spend too much time trying to figure out the format before they can understand the information. Few product management teams take training classes together and adapt those methods to get the best results for their products and services. 

4. Use a product management framework 

Learning is at the core of product management, yet few product managers have a process for learning, articulating, prioritizing, and planning.

The Quartz Open Framework was created to guide product management through a logical process from idea to market, supported by continual learning. As a process framework, Quartz defines both the necessary steps and how to order them, turning innovation into a choreographed dance. Learn at every step and adjust your plans accordingly.

Learn more about the Quartz Open Framework at www.QuartzOpen.com.

In terms of process, this is how ProductOps can benefit your product teams:

Successful product teams need standard tools, a common language, and ongoing coaching on product management best practices. ProductOps adapts industry practices to create an organizational ‘playbook’ of methods that are customized to the special needs of the business.

By examining what works (and what doesn’t) across all product teams, ProductOps identifies successful approaches and helps each team adopt the organization’s best practices.

·      Define roles and responsibilities. Let’s have a single definition for each title and what they do. For instance, who should do win/loss interviews, analysis, and reporting? ProductOps can either coach teams in the best practices or perform certain capabilities (such as win-loss analysis) as a service.

·      Standardize methods and artifacts. What templates do we use? How should we prioritize business opportunities? What’s the best approach for backlog grooming? ProductOps builds a ‘product playbook’ of standard templates and tools adapted to the special needs of your business.

·      Wrangle corporate and product data. With so much operational data available, how can a new product manager make sense of it all? ProductOps can be the expert on data that’s available and how it can provide insights to product decisions.

·      Guide and curate market and customer research. How do we set up customer interviews? Where do we store and share our insights? How can we execute experiments such as A/B tests?

·      Evaluate and manage departmental tools. What roadmapping tool is best? Where do we store product information? Which is our preferred video conferencing tool? Do we use Teams or Slack, and how are those organized and maintained? Instead of multiple duplicate tools, ProductOps identifies departmental needs, evaluates available tools, and makes a selection for everyone. ProductOps then manages the tool and trains team members on its use.

EC: ‘Feature factory’ thinking has been largely criticized, but it is still a widespread problem. What should product leaders do to eliminate this in their teams? 

SJ: There are a number of problems with the feature factory mindset.

First, customers rarely know what they want or how to describe it.

Secondly, the mindset implies that any feature request will be accepted and put into the product immediately.

Yet, with a limited pool of technical resources, there are always more feature requests than resources to fulfill them all. As a result, product managers or product owners are forced to build some features and reject others—which invariably irritates customers and their salespeople. 

A solution is to reject all feature specifications and request explanations of problems to solve. The ‘problem story’ approach ensures that requests are for problems, not features. 

If you’ve ever talked with a developer, they don’t want to build features blindly. They are problem solvers. Give them problems to solve. The creators of the Agile Manifesto were so passionate about building the right product and features that they called it out in the phrase, ‘customer collaboration over contract negotiation.’

Agile teams talk to their customers to determine what problems to solve. Companies with the best outcomes empower their teams to solve problems. The customer and the salespeople are almost always wrong about what feature they want. Give an engineer a problem to solve, and they will amaze you with their ingenuity.

For product professionals:

• Focus on problems in every aspect of your work.

• Describe markets and problems in all your business documents.

• Put problems, not features, on your roadmap.

• Don’t write epics about features; write epics about problems.