How to learn product management
Table of Contents
For the last few months since the StackPath acquisition, I have been shedding all the administrative tasks of a CEO of a small startup and focusing more and more of my time on product.
This has been initially scoped to integrating Server Density monitoring into the StackPath platform but has been broadening to multiple products across the platform.
I am used to shifting between many different tasks and responsibilities so focusing entirely on product has been a new experience for me. As a result, I have been spending as much time as possible learning about what it means to do product management.
Learning something new is a great time to write about the experience. There are valuable insights that can be shared from a beginner mindset. Once you “know” something, you think about problems in a different way.
So this post is a collection of the resources I’ve found useful in learning about running product engineering ~6 months into the role.
Books for product managers #
- Death by Meeting – the book that has had the most impact on me about how to run teams.
- High Growth Handbook – the chapter on building both executive teams and a product management organisation have been most relevant. Read my review.
- Principles: Life and Work – lacking some practical advice for actual implementation, this is an interesting look at how to productise your own principles into an operating system for your own life, and work. Read my review.
- The Lean Product Playbook – a great framework to really get into building a product that addresses customer needs, and ultimately achieves product/market fit. Read my review.
- Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams – I found this book to be quite good at understanding ideal team structures and management approaches, but less helpful on the actual day to day of how a product manager should approach their role. It’s worth a read for someone getting into product management for the first time, or someone who is in the process of building a product management team structure. Read my review.
Product management podcasts #
I have yet to find a good podcast that is just about product management, so here are some specific episodes from more general podcasts that I’d recommend listening to.
- Masters of Scale: Marissa Mayer – I find this podcast series very difficult to listen to because it is incredibly over-produced, but this one made me do further research into how Google runs product management and so was valuable in that sense!
- The A16Z podcast as a whole is worth listening to, but specifically related to product I would suggest High Growth in Product (and tech) which is a podcast interview with Elad Gil of the High Growth Handbook mentioned above. Also listen to The Basics of Growth Part 1 and Part 2.
Events for product managers #
Generally I don’t find attending conferences to be a good use of time. The travel, disruption to routine and low signal to noise ratio of talks means I’d usually much rather watch the videos after. However, I have found these to be worth the time:
- Mind the Product Conference is the main conference but I attended only the Leadership Forum, which was worth it because of the small number of attendees.
- Every industry has their own niche conference which is worth attending just to understand the overall landscape. For monitoring, it’s Monitorama. And for SaaS in general, it’s SaaStr. Be very picky and very specific.
Product management blogs #
Where specific articles but not the whole blog is useful, they’re listed in the next section. These blogs are worth subscribing to in their entirety.
- 25iq – not a product specific blog but it covers product, startups, pricing, unit cost models and finance which are all very useful in a startup environment.
- Andrew Chen
- Steven Sinofsky
- Silicon Valley Product Group and in particular, Product vs IT Mindset, Moving from an IT to a Product Organisation, The VP Product Role.
- Stratechery – one of the small number of publications I pay for. Not product specific but focused on business strategy of the tech industry.
Articles for product managers #
- Turn Customer Input into Innovation – how to actually ask questions and discuss product questions with customers in order to get useful responses.
- A Career Cold Start Algorithm – a simple way to learn from the experts when joining a new team, company or project.
- Preparing for a Google product management interview – worth skimming to understand how Google hires for product management.
- Google goes globe-trotting – an old article but with such a famous product management training program, this is worth reading to understand how it all started. Interesting to see how many of the products mentioned have since been shut down!
- This is why I never hire product managers – an interesting take on why you don’t want people who have had past product management experience.
- Good Product Manager / Bad Product Manager – a great breakdown of how to think about what product management should be doing.
- How to build an enduring, multi-billion dollar business – create a 10x product + recast incumbent cost structures.
- Why Amazon is eating the world – I found this analysis of how Amazon has rebuilt its internal systems as individual products to be a useful way of thinking about feedback loops. Internal corporate tools tend to be significantly less polished than if they were to be used by external, paying customers…why? Surely you want your internal tools to be best in class? That can be a competitive differentiator in itself.
- Why Software Development Requires Servant Leaders – how to think about where the product manager and project manager roles fit into engineering management.
- Practical Time Management
- Advice for a new executive – focused on CTO/VPE roles but still relevant to think about how to operate in a new executive role.
- How to hire a product manager – also covers what the role actually is.
- I have also written a couple of posts related to product: Easy to use and beautiful design are no longer differentiators, How to prioritise what features to build and Rewriting, refactoring, rearchitecting – when is the right time?
Product management videos and talks #
- Customer Obsession – from ProductTank San Francisco, this talk outlines: the balancing act of delighting customers in hard-to-copy margin-enhancing ways; how “customer obsession” helped Netflix to create a highly personalized experience; and the principles of customer obsession through a case study — “Should Netflix send a free trial reminder to its customers at the end of their four-week trial?”
- Mastering the problem space for product/market fit – this is a framework covering the universal conditions and patterns that have to hold true to achieve product/market fit. Each layer in the pyramid is a key hypothesis that you need to get right in order to build the next layer and ultimately achieve product/market fit.
Good quotes on product management #
Some select quotes from the linked content above that’s worth highlighting by itself.
In the 10+ years since AWS’s debut, Amazon has been systematically rebuilding each of its internal tools as an externally consumable service. A recent example is AWS’s Amazon Connect — a self-service, cloud-based contact center platform that is based on the same technology used in Amazon’s own call centers. Again, the “extra revenue” here is great — but the real value is in honing Amazon’s internal tools.
If Amazon Connect is a complete commercial failure, Amazon’s management will have a quantifiable indicator (revenue, or lack thereof) that suggests their internal tools are significantly lagging behind the competition. Amazon has replaced useless, time-intensive bureaucracy like internal surveys and audits with a feedback loop that generates cash when it works — and quickly identifies problems when it doesn’t. They say that money earned is a reasonable approximation of the value you’re creating for the world, and Amazon has figured out a way to measure its own value in dozens of previously invisible areas.
^ Why Amazon is eating the world
Perhaps most importantly, the product manager is the voice of the customer inside the business, and thus must be passionate about customers and the specific problems they’re trying to solve. This doesn’t mean the product manager should become a full-time researcher or a full-time designer, but they do need to make time for this important work. Getting out to talk to customers, testing the product, and getting feedback firsthand, as well as working closely with internal and external UX designers and researchers, are all part of this process.
Many books emphasize the first two points—corporate strategy and culture setting. However, you will find that in practice you have little time in a high-growth, rapidly scaling company to think deeply about those points until you hire a strong executive team and manage your own time properly.
There’s no point in defining what to build if you don’t know how it will get built. This doesn’t mean a product manager needs to be able to code, but understanding the technology stack — and most importantly, the level of effort involved — is crucial to making the right decisions.
Another lesson that I learned from Brian Chesky—one way to think about when to upgrade executives—is that a really great executive is about six to twelve months ahead of the curve. They’re already planning for and acting on things that are going to be important six to twelve months in the future. A decent executive is delivering in real time, now to one to three months in advance.
The trick to creating a great product team is to think of them as the product. This is not an objectification but rather a thought exercise. After all, they are the product that creates the product. Without them, there is no product. Amazing teams make amazing products. Seen from this perspective, the task of how to hire, onboard, train, and develop them becomes another product design problem. The approach that successful leaders take to creating great product is the same approach they take to creating great product teams.
Often the hardest part of the communication is communicating the “why” behind the product road map, prioritization, and sequencing. Part of this will be creating a framework that establishes why some things are prioritized higher than others—and it’s important that all other functions buy into this framework.
Out of the goals will come the specific features for development. Like a ripple effect with the vision at the center, the objectives or goals are generated and they in turn generate the features that support those goals. Never start with features. Even if your business or product is based on a “feature concept,” ask yourself what the bigger problem is and why it needs solving. Any feature shouldn’t be considered, prioritized, or delivered in a vacuum. Without a vision to guide the product creation, a project can quickly become a collection of cool solutions lacking a core problem to guide them. Features need to be directly tied to the product or organization’s strategic goals.
For example, if you as the designer/manager discover that you as the worker can’t do something well, you need to fire yourself as the worker and get a good replacement
If you are not evolving your organizational design, it might be an indicator that your product strategy is getting stale. In our experience, most rigid organizational structures are built to create processes for predictability, not successful outcomes.
As GV’s Ken Norton says, “I like to start with the problem. Smart people are very solution-oriented, so smart people like to talk about what the solution is going to look like to the problem. But successful people think about the problem. Before I talk about this product, or this feature, or this device I’m going to build, I must understand the problem at a deep level. Then success is easy to articulate, because you know what it’s like when that problem is solved.”
“By-and-large” is the level at which you need to understand most things in order to make effective decisions. Whenever a big-picture “by-and-large” statement is made and someone replies “Not always,” my instinctual reaction is that we are probably about to dive into the weeds—i.e., into a discussion of the exceptions rather than the rule, and in the process we will lose sight of the rule.