By Brandon ChuFollow
GM, Platform @shopify. Still a PM at ❤️
Its simplicity has made it one of the most successful product management memes out there, and it’s done good things for the discipline.
Long ago, as a young PM padawan, it helped me realize that I needed to structure my learning for breadth. What it didn’t tell me, however, was where to focus — I started trying to learn everything, and in hindsight that was a mistake.
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 I call 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.
MVPM in no way implies that you need to achieve mastery of its skills to be effective, which is both impractical and counterproductive for someone starting out. Instead, view it as a syllabus of sorts for the course in product management that doesn’t exist.
I write this for my younger self, for new product managers, and for more experienced PMs still looking to level up. To maintain some symmetry with the diagram, skills are divided into sections for each discipline. I cover 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.
When engineers refer to ‘the stack’, they’re talking about the layers of technologies that are used to provide functionality to your product (i.e. make the thing work). From the moment a customer loads your landing page to when they delete their account, the technologies in the stack handle everything.
Fastest way to learn — Ask an engineer to take you through the stack at a high level. Write down the names of each technology. Quick Googling of those terms will teach you some of the high level benefits and trade-offs of each technology chosen, and how they work in harmony together. Stay at a high level because you can fall into the rabbit hole easily (add “trade offs + benefits + vs” to your search query)
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.
If the stack represents what technologies are being used, system architecture represents how those technologies are structured to work together to deliver the product. Whereas the stack is mostly about raw technical capability, the architecture of a product incorporates the customer’s intended behaviour in its design.
Fastest way to learn — Ask an engineer to draw you the architecture. You’ll get something like this:
First, don’t panic. Ask them to walk you through what each component (box) in the system does. Some will handle internet requests, some will house the ‘business logic’, others still will hold the data that is saved (cylinders).
Second, believe it or not, this is very useful for you.
How does this make you a better PM?— When you understand the architecture, you start to think of your product like a system, which is generally how engineers will as well. Having an understanding of how each component in the system contributes to the whole helps you make better decisions and trade offs.
Generally, the components in the system that have the most connections are the most complicated to change because so many others rely on them for data or functionality. The more components you have to change in order to complete your build, the more dependencies you have, and the harder the project will be to execute.
In larger companies, the number of components you touch is often synonymous with the number of teams/groups you need to interact with, and the more alignment you’ll need to gain to execute a project.
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.
The data model is closely related to the system architecture in that certain entities ‘live’ in certain components. Your Users model may live in component A and so might the Products data, but because of its sensitivity, Credit Cards live in component B. 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 (application programming interface).
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. Importantly, APIs also let you talk to external components. When you call an Uber from Google maps, the Google maps app is talking to a component from Uber. 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.
Fastest way to learn — You should focus first on gaining an understanding of your Public APIs. They’re usually easy to find, and often live on your website’s developer docs. When you see them, you’ll see code and that may or may not freak you out depending on your background, but if the documentation is half-way decent, that should be irrelevant and you should be able to read it fine. The beauty of studying your APIs is that they often represent most of your underlying data model, so you get two birds with one stone.
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. The extensibility of software is one of it’s most valuable properties, and being able to work well with other products (that your customers are potentially using everyday) is quickly becoming table stakes.
Programming. Don’t get me wrong, I love programming and it does help you be better, but unless it’s a highly technical product, you just don’t need it to be an effective PM. If you find yourself coding as a PM, you may need to ask yourself if you’re actually doing high leverage work, or you’re not sure what else you should be doing. That being said, I think it’s a very worthwhile and fun experience to have built at least one app and shipped it to a production environment.
1. Project Management（项目管理）
Boring, I know. I hate it too, but it is really important. If you can’t run a project well you’re never going to be a good PM. Period.
Fastest way to learn — This one is hard. To be an effective project manager takes a lot of experience and time. You can read up all you want, but at the end of the day it’s a human behaviour problem. It takes time to learn about the spectrum of personalities you’ll end up working with, and any advice you’ll find on how to approach it is often subjective to your personality, too.
That being said, there are some software specific things you can invest in to accelerate your learning curve:
1.Understand the basics of product development so that you can empathize with your team. Learn about version control (Git), collaborative programming (GitHub), Quality Assurance processes, and at a high level how and when code gets deployed to users in your product.
2.Learn about the common problems that plague software teams, and the processes others have developed to try and solve them. You’ll come across things like agile, scrum and kanban. There is value in learning the philosophies behind their approaches, whether your company uses them or not.
3.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 (you’ll have to find that out too).
How does this make you a better PM? — You’ll get more shit done with your team, and people will enjoy working with you because everyone hates a poorly managed project.
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.
When your team is debating the highest leverage thing you could build next, it’s important that you can develop a model of how the product will move the dial on those metrics.
Fastest way to learn — It’s time to get your spreadsheet on. A good model clearly shows two things:
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. It makes your job easier too; by enabling you to justify projects in a way that resonates with your stakeholders, and by easily enabling you to compare the opportunity cost with other projects you could be doing.
Being able to independently gather data is vital to making quick decisions. For all but the most involved analyses, relying on someone else to get data for you is not only an inefficient use of their time, but it also doesn’t lead to insights, because anyone who’s been an analyst before knows that insights come through iterative exploration of data, not some perfect report you dream up.
It also reduces your ability to make data-informed decisions when they matter. Almost everyday, a decision about how a product should behave in a certain scenario will pop up, and having data to support a decision makes it easy for you and your team to feel confident in the right direction.
Fastest way to learn — Your goal is data independence . Whether you need to write SQL queries or use a drag and drop interface depends on the data infrastructure at your company. Regardless of what it is, you need to invest in learning the tools available to you. Google them.
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. Whether you’re considering what to build next, or you’re seeing how your launch is doing, you will build a reflex to use data as an important input into your decision making — and better products will result.
Take this from someone with a business degree - don’t waste your time making strategic business cases, 3 year plans, and other MBA artifacts. I won’t go as far as to call it bullshit, but it’s not the way to succeed in software. 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.