Previously, I went over a few items I found notable in Part 1, which was about Lessons from Top Tech Companies. It discussed how some of the major tech companies are doing product management, a bit about what product management is, and a bit about what it's not. Additionally, there were some lessons about what successful product managment is and is not, especially at different company sizes.

Part 2 delves a bit more into the different roles involved in a well-functioning product team, and what those roles do.

The Right People

Principles of Strong Product Teams

A product manager is not what's described in a certified scrum product owner class. That type of role tends to escalate a lot to the CEO and ends up being more like a backlog administrator (not a real role). A product manager is also not someone who gathers all stakeholders for decisions. That end up being more merely a roadmap administrator.

The Product Manager

One key roles of a PM is to have deep knowledge of your customer, the data, the business and stakeholders, and of the market and the industry. It's also important for the PM to know what gets built (the backlog), and what's going to be worth building. For the latter, they should be ready to provide some evidence and justification to engineers. With respect to the users, a PM ought to have knowledge both qualitative (why the users will use a product or part of the product) and quantitative (what the users are doing).

A PM will be curious about new technology, creative when it comes to solutions, and persistent (especially in communicating to people). Some product managers may have an MBA, but it's not necessarily, and it's not even necessarily a net benefit ^[1].

Product ownership is only a subset of product management. A product manager's starting point is to become an expert in customers. Then, to establish a relationship with stakeholders to become an undisputed expert in the product and the industry. There's a lot of relationship nurturing along the way.

Product management is NOT project management. There may be moments of it that resemble project management, but those are a fraction.

It will help a product manager to know about programming, and to know some business accounting and finance.

Designers

Designers are table stakes for a company that servers end users, and it's basically the same story for B2B companies. Designers should be part of product teams, not an 'internal agency'.

Touchpoints between the Product Manager and the Designer include things like: 'How will customers learn about the product?' 'How will users interact at different times of day?' 'Are there other things competing for their attention?' 'What does a 1-month vs 1-year customer look like?' 'How will a user share this experience with others?

A designer's canvases are prototypes.

Product managers should not try to do wireframes themselves. Nor should they leave it to engineers to fill in the blanks. PMs need to include the designer in most customer facing conversations and user testing. Ideally, the designer will sit with the PM, and the PM will stay out of the designer's way.

Engineers

If you were an engineer or studied computer science, you're probably in good shape for being able to have a good, credible relationship with engineers. That's good, because this is the most important relationship.

A product manager should stay out of the engineers' way regarding implementation. The job is to make them missionaries by NOT sheltering them from customer pain or business problems.

There should be > 0 engineers who want to help in discovery.

Product Marketing Managers

PMMs work on differentiation, acquisition, finding and managing channels. They are not full time members of the product team. DO NOT allow product marketing to become your (Product Manager) full time job.

Also be aware of the old, non-functional way of interacting with PMMs. A PMM would define the products (without a PMs discovery tools and methods) and hand off to a backlog manager. This is not that.

Supporting Roles

If you're at a small startup, you could be covering all of the supporting roles. They're things like user researchers (sometimes a designer may cover this). Or Data analyst (aka Business Intelligence). Or test automation engineers. Note that it's not recommended to have neither engineers who unit test nor QA.

Leader Roles

If the product looks like it was designed by a collection of agencies, you're missing a principal designer. If projects are getting stuck because PMs don't understand the implications of their decisions, you're missing a Head of Product or Principal PM. If there's a lot of tech debt, you're missing a VP of engineering or a CTO.

Head of Product

This role does team development, product vision, execution, and product culture. That means that everyone understands the importance of continuous rapid testing and learning, and they value designers and engineers.

The trajectory of a PM can go through a phase of being a Group Product Manager, which can involve coordinating between product managers and some people management. This is often at a similar level of responsibility with Senior PM, and can lead into a VP of Product role. On the other hand, a Principal Product Manager may be at a similar level of responsibility as VP Product, but with less emphasis on people management

Head of Tech (VP / CTO)

They're responsible for architecture, engineering, quality, site operations, site security, release management, and delivery management.

If a tech org reports through the CIO, that's a warning sign, because engineers benefit from focusing on those same items a CTO does, which are not as much in the CIO's purview.

The CTO should be allowing engineers to participate in discovery.

Product Managers do well to relate to the Head of Tech, this goes along with the themes of evangelism and "missionaries over mercenaries"

Delivery Manager

This is not about whip-cracking, but about impediment-removal. A delivery manager may also hold the title 'Scrummaster'². The role shows up in organizations of 5-10 product teams.

Principles of Structure Product Teams

The theme here is that there are often tradeoffs between autonomy and leverage. For example:

Autonomy should be weighted very heavily against leverage. There's a special consideration for 'platform' teams which may work with some of those foundational items listed above.

A short list of the principles:

1. Alignment with investment strategy, don't succumb to the sunk-cost fallacy
2. Minimize dependencies
3. Ownership and autonomy
4. Maximize leverage
5. Product vision and strategy
6. Team size should be 1 PM, 1 designer, and 2-10 engineers
7. Alignment with architecture
   • (design a team around their competencies)
8. Alignment with the business
9. Structure is a moving target

Thought-food:

1. Some of the definition of these roles has come from what they don't do. Are there scenarios where it's appropriate to break those guidelines?
2. Are there notably successful organizations that get along without one or more of the essential roles? Why might that be?
3. Think about some of the incentives for different folks in each part of the org when it comes to product work, and how they might be at cross-purposes. For example, a PMM might be less inclined than a PM to embrace discovery work because a PMM might have more contact with sales folks who'd really like to have something to sell yesterday to get commissions. In contrast, a PM is seeking a longer-term product-market fit.

¹I'm thinking about a ribbonfarm post by Venkat Rao, part of which read: "An MBA may well have excellent statistics skills, domain knowledge of an industry and visibility into lots of opportunities. But to make the mind-shift into entrepreneurship, he has to learn to see MBAs still jungle-gymming in the old economy with contempt instead of reverence; their priorities as perverse instead of appropriate; their suits as empty."

²I'm trying to save most of my commentary for a future post contrasting to Basecamp's Shape Up. But despite having worked with Scrummasters, I still find this to be one of the cringiest job titles in existence. It's a title based on a particular implementation of Agile principles. That implementation is in turn based on a sports metaphor. Agile principles will probably outlast scrum, and we don't have many other role titles based on sports, so I think the preference should be for 'delivery manager'.