Share this article

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

What Skills an Effective Generalist Product Manager Needs

This post lists the key insights from this article, from Brandon Chu, GM Platform at Shopify.


You’ve probably seen this diagram before. It elegantly shows that product management is the intersection of a diverse skill set. Its simplicity has made it one of the most successful product management memes out there, and it’s done good things for the discipline.

However, there isn’t enough time on this Earth to learn everything you could about those three circles, so as helpful as this diagram is, it ends up impractical.

What would have been far more helpful was to know what actually comprises that intersection.

That intersection is what the author calls the Minimum Viable Product Manager (MVPM), and it defines a set of skills or knowledge that are useful to be an effective generalist product manager, one who can work on almost any problem.

To maintain some symmetry with the diagram, skills are divided into sections for each discipline. The article covers three key concepts/skills to focus on, and one that you really shouldn’t focus on. As much as possible, it’s in plain language and is written for someone who’s approaching any of the subjects cold.

Technology knowledge


1. The Stack

When engineers refer to ‘the stack’, they’re talking about the layers of technologies that are used to provide functionality to your product.

How does this make you a better PM? When engineers are discussing how to build something, terminology flies around the room. Knowing the stack means you can at least follow along, and over time you’ll begin to understand what depth in the stack they’re referring to. Generally, the more layers in the stack they need to touch, or the deeper the layer, the more complicated and risky a change will be. Knowing this may push you to re-consider a different way to solve the problem.

2. System Architecture

If the stack represents what technologies are being used, system architecture represents how those technologies are structured to work together to deliver the product.

Ask an engineer to draw you the architecture. You’ll get something like this:

“Why are there only two of the thing called triple store?”

How does this make you a better PM? Having an understanding of how each component in the system contributes to the whole helps you make better decisions and trade offs.

3. The Data Model and its APIs

A data model organizes information used by your product and standardizes how pieces of that information relate to one another. By ‘information’, we’re really talking about things like Users, Products, and Credit Cards, which collectively are called entities. These entities can relate to each other in certain, structured ways; for example a User can have many Products, but only one Credit Card.

If your feature needs to show which Users own a product in a list, that’s pretty easy since they live in the same component. But if you need to know which of those users have a credit card stored, then component A needs a connection to component B in order to share the data. That’s harder, and to accomplish it, they need an API.

APIs are built on top of the data model and represent how any two components talk to each other and exchange information about their underlying models. Most applications have Public APIs and Private APIs, which are usable by anyone on the internet, or just those you specify, respectively. Knowing your public APIs are critical to understanding how your product can interact with the outside world.

How does this make you a better PM? Knowing your data model expands your ability to know what information you can utilize to create better products, and how hard it may be to access that information. Knowing your APIs mean you understand what types of information partners and third party developers can get from your application, and therefore what types of integrations are possible.

4. Where you shouldn’t focus

Programming. If you find yourself coding as a PM, you may need to ask yourself if you’re actually doing high leverage work.

Business knowledge

1. Project Management

If you can’t run a project well you’re never going to be a good PM. Period.

Understand decision making at your company, and map out your stakeholders. These are often your customers, your boss, your team members’ bosses, and other PMs. Find a way to ensure that everyone is aware of the status and direction a project is going at a level contextual to what they care about

How does this make you a better product manager?   You’ll get more shit done with your team, and people will enjoy working with you because everyone hates a poorly managed project.

2. Modelling Impact

Things that aren’t measured rarely get done well. Every product should have quantitative goals that are tied to it’s ultimate success, basic things like user growth, feature adoption, revenue, etc.

The unit economics of a product and the assumptions that create them:

  • How much does it cost to acquire a new customer?
  • How much does it cost to serve the product?
  • How much does a conversion move the needle on your goal?

The forecasted impact and the assumptions that create them:

  • How much does this product move the needle over the next year? The next three?
  • How many people will we need to hire to enhance and support it?
  • How are market forces like cost reductions, inflation, and competition accounted for in the long term

How does this make you a better PM? The exercise of building a model for your product is a great way to test your instinctual assumptions and ensure that your product has enough potential to make it worth doing.

3. Gather & Analyze Data

Being able to independently gather data is vital to making quick decisions. 

How does this make you a better PM? When data is easily accessible to you and you’re comfortable getting it, you will use it more and it will enable you to be more iterative. 

4. Where you shouldn’t focus

Don’t waste your time making strategic business cases, 3 year plans, and other MBA artifacts. Understand the vision, find a problem worth solving to achieve it, build a hypothesis to solve it, and then validate it as quickly as you can with real customers. Rinse and repeat.

UX knowledge

1. Know the design patterns of your product

Most products develop design patterns over time, whether planned or not. Patterns are the consistent use of the same visual and interactive components in your product.

How does this make you a better PM? Plainly put, designing products on pattern is far easier and faster. They let you stand on the shoulders of design decisions your team made in the past, decisions that result in a product that’s easier for customers to use. 

2. Know how to execute user experience research

PMs are supposed to be the voice of the customer. If you don’t understand your users, you will never build great products. From interviewing a single person face to face, to quantitatively analyzing millions of user actions, understanding the basics of good research are imperative to your job.

How does this make you a better PM?  By consistently and frequently testing your product with customers, you can take away a lot of the guesswork (and risk) in product development.

3. Know how to prototype your ideas

Prototyping in this context means being able to create visual mockups that can effectively express your ideas. They need to be good enough so that you can:

  • Communicate a product concept clearly
  • Unblock a team when design is behind or absent

How does this make you a better PM?By prototyping and showing people what you’re thinking instead assuming they understand, you will get better feedback from your team on your ideas, and reduce the risk that mis-communication leads to wasted effort. 

4. Where you shouldn’t focus

Don’t focus on being a great visual designer. 

6 min​ read

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.

Comments