MVPM: Minimum Viable Product Manager
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.
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.
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 (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.
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. 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.
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.
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.
4. Where you shouldn’t focus
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:
- 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.
- 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.
- 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.
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.
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.
3. Gather & Analyze Data
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.
4. Where you shouldn’t focus
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.
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. All text on buttons are font-size 25px, all forms must be no more than 3 fields, every time an error happens we will make an explosion sound and send the user an email with the details — these are all patterns.
Knowing your product’s patterns are critical in understanding how users map your product in their minds, and how they can effectively be given new features over time. If you usually give users a green button saying “Add New Feature” when you launch something, and this time you switch to an orange button that says “Blow your mind”, you will confuse the shit out of people.
As a product grows, consistent use of patterns becomes even more important because they enable teams to work independently of each other but still build a product that feels cohesive.
Design patterns are also usually developed in harmony with technical patterns, like style guides and components, which are basically libraries of re-useable code that speed up teams because they don’t have to re-design or re-implement the same functionality again.
Fastest way to learn — Talk to your designer, they should know these patterns cold and (hopefully) be able to give you links to a style guide. Also talk to your front-end engineers, they can equivalently give you links to a pattern library.
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. If you ever need to break existing patterns - to be clear there sometimes good reasons to do so - be prepared with very good reasons why it’s necessary for the long term health of the product.
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.
Fastest way to learn — Effective research is a very big field, so instead of sending you into the rabbit hole, I recommend you focus on understand the following:
- Understand Sample Size and how to calculate statistical significance
- How to normalize your sample and why that’s important
- How to ask unbiased, non-leading questions in surveys and interviews
- How to synthesize results and avoid bad conclusions
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. Before a project even starts, you should be testing to validate that the problem you think you’re trying to solve really is one. While you’re designing and building, you should be testing that the product’s design is easy to use and is likely to solve the customer problem. After launching, you should be validating that the problem was solved for the customers you wanted to solve it for.
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
It is incredibly difficult to communicate a product experience verbally or in writing. A prototype, something people can see and preferably interact with (you can do this without code), is 10x more effective.
There are two reasons for this: first, it forces the articulation of the product in terms of what customers will actually interact with, and second, because humans naturally think visually, a prototype levels the playing field so that everyone on the team can speak the same language and give their points of view effectively.
Unblock a team when design is behind or absent
In most projects, it is important that the product’s design is ahead of development. Designers try to “stay ahead of the devs” because the switching costs for developers is much higher once they start building the product in a particular direction.
Because so much of product design is iterative and done in parallel with the build, when there’s a setback (e.g. user research says the design is not effective) design can quickly fall behind. It’s in those situations that a PM must be able to roll up her sleeves and be a “design intern” for the lead designer, helping to push pixels and ship mockups so the engineers can continue the build.
Fastest way to learn — I won’t spend time justifying this, but just start using Sketch, it’s like MS paint and Photoshop had a baby and it’s awesome.
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. Also, it’s nice to be able to actually produce something tangible once in a while.
4. Where you shouldn’t focus
Don’t focus on being a great visual designer. Your ability to make a slick looking interface is redundant and disempowering to someone who’s spent a career learning the deep craft that is product design. Unless you’re design savant (to be clear there are some), you also probably just think you’re good, and you actually suck.
MVPM
I don’t want to trivialize learning all this stuff. It’s not easy, and it takes a lot of time, so tackle it bit by bit and enjoy what you’re learning. I hope this helps you be a little more efficient in your quest to be a great, if minimally viable, product manager.
Here are some other posts you might like:
