Here are the resources/readings/inspirations which have had the biggest impact on me roughly in decreasing quality. I’ll keep updating it as I discover new ones – please don’t hesitate to let me know your thoughts/suggestions in the comments!
Reminder: Experience is King
Product management is a messy process with all the biases, emotions, and hidden incentives, to be expected when humans collaborate on anything. Experience is the only way to learn how to navigate this. Readings like the below can help accelerate and cement some of this learning, but remember that each situation is different, and maintain a critical eye about how much this advice applies to your situation – don’t expect any silver bullets!
“Inspired: How to Create Tech Products Customers Love”, by Marty Cagan
A modern, comprehensive, well written book from industry veteran Marty Cagan. I particularly enjoyed the number of real world examples he took from the industry, reflecting on the roles PMs had in key product successes/failures of their companies. He also had some good thoughts on the distinction between B2C and B2B product management, and the areas you need to emphasize more on based on that (eg more data focus for B2C, more sales focus for B2B)
I think this book is a great one to start with, and will get you lots of food for thought, follow-up reading, companies/people to check out, etc.
If you want to get a peek before jumping in, my Kindle highlights from the book are available here.
“Good PM, Bad PM”, by Ben Horowitz and David Weiden
This piece does a great job of explaining the scope and responsibilities of the role in a few pages, by giving examples of good and bad PM behaviour. As with Inspired, it makes it clear that this is a very demanding role and the buck stops with the PM for the success of the product. I find it helpful – if a little daunting – to have the negative case spelled out: what the “Bad PM” does. This makes it much more actionable because you can notice instances of what the Bad PM does being done where you work and reflect on it: for instance: “Bad product managers talk about how future products will be great, but the current products are weak.” or “Bad product managers aren’t savvy or confident enough to distinguish between interest and commitment to buy.”
Note that this piece has had its share of critics for the “CEO of the product” analogy, which many feel justifies PMs putting a product need above the needs of the business, and being blind for instance to engineers moving to another more impactful product for the business. It’s a fair concern and worth avoiding the “CEO of the product” description for that reason.
PMing in 1 tweet
Spot on:
Two useful feature prioritisation frameworks
The process of deciding what to prioritise is a lot messier and more nuanced than what all the feature prioritisation frameworks out there suggest. No framework will provide you with a quick solution to your big prioritisation questions (nor should you want them to, this is a process you need to own and refine, and involve all stakeholders in) but they can help ask interesting questions and frame discussions.
Anyway, here are two that I have found particularly useful:
- The Intercom Feature Audit framework: A common-sense audit method that is worth always considering: frequency of interaction with the features being considered, and impact of the improvement if the feature is delivered. From this can stem a lot of useful research into the most common user workflows and their detailed instrumentation to measure frequency and feature adoption.
- Adam Nash’s framework on feature prioritisation: categorises features into 4 well-argued buckets: top metric movers, customer requests, delight, and strategic. I particularly agree with the importance of tailoring to different timeframes of requirements: from the long term strategic / R&D investments all the way to the short term requests and user delight features which are important from a customer relationship and morale perspective.
The Intercom ebook also has some good (quite simple) advice on how to understand
- The Jobs to be Done framework applied to Intercom
- Ask your customers “Would you like a (Calendar/TimeTracker/Gantt Chart)?” and they’ll reply “Yes”. It’s a one-way “something for nothing” offer; why wouldn’t they? They haven’t had to make a tradeoff between competing priorities. This leads to customers saying they want stuff that they don’t really want.
- Asking your customers “Would you rather that we made the product much faster, or that we added more labelling features?” and you’ll get a different answer. Everyone values speed. So when planning new features it’s important to understand the tradeoffs at play.
Personal Learnings
A few things I’ve found myself reflecting on:
- It’s important, particularly for very technical / deep tech products, to make product management engineering’s concern, not just the PM’s concerns. There are a number of deeply technical considerations that PMs will likely not be able to make the best decisions on – empower engineering to take these decisions and help them communicate them, sell them, etc. Required watching from Steve Jobs on the difference when product/eng vs sales/marketing runs a company.
- If you don’t have the final product name – introduce codenames. Renaming from a non-codename title is a lot harder than from a codename. is a lot of wasted time and effort
- Always overcommunicate on the status of things – act like the owner. If people have to wonder if you’re on it you’re not being clear enough
- Probably the most important thing on the job is the relationship with engineering. If you trust them and they trust you everything is so much easier. Develop empathy for “the craft”, understand what is being done at lower levels
Writing a fake future Press Release / Blog post for your product launch
This approach is quite well known and used now, credited to Amazon’s product management teams. I agree it’s very effective to get execs, product, eng and marketing on the same page on what we will be shipping, what the headline customer benefits are, and how it fits into the arc of recent development efforts (often something you detail a bit in the blogpost as context)
- Heading – Name the product in a way the reader (i.e. your target customers) will understand.
- Sub-Heading – Describe who the market for the product is and what benefit they get. One sentence only underneath the title.
- Summary – Give a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.
- Problem – Describe the problem your product solves.
- Solution – Describe how your product elegantly solves the problem.
- Quote from You – A quote from a spokesperson in your company.
- How to Get Started – Describe how easy it is to get started.
- Customer Quote – Provide a quote from a hypothetical customer that describes how they experienced the benefit.
- Closing and Call to Action – Wrap it up and give pointers where the reader should go next.
What to do on the first 30 days on the job
This is a good list I wish I’d read before starting in new roles. It’s true that as a new PM on a team you have a good opportunity to interview everyone and get a good feel for what’s working and what’s not. You’re new so people will be very patient.
Public Roadmaps Hall of Fame
Publishing and maintaining roadmap that looks beyond the next couple of sprints and shows useful information to customers is very hard to do.
It is always evolving: you learn about new customer requirements or problems to solve, and you learn more about how to solve certain problems and when they will be tackled. There is also a valid concern that you shouldn’t be fixing features and delivery dates too far in the future as you will lose agility (ability to reprioritise from new information).
Nevertheless, your customers (particularly in B2B) will ask for a roadmap and it is a great way to communicate that you have heard most of their requests, and there are also a lot of things you’re working on that they didn’t know you needed. As much as possible you need to be set that these are not promises or commitments, just the latest view on priorities.
Publicly you have the added worry that features/development themes need to be very clearly written to avoid misinterpretation (something you can correct if roadmaps are always presented, eg as part of a quarterly catchup with a customer). Here are a few companies who maintain impressive product roadmaps:
- Front’s Trello roadmap. Kanban-style, showing ideas, planned, in development and recently shipped (including which version it was in). They also seem to have a fair amount of engagement by enabling voting on cards.
- Unreal’s Trello roadmap. Similar to Front’s, without the voting.
- Unity Roadmap. Bundling features into future releases, but without fixing dates.
Founder Mentality
From Naval: People with “founder mentality” can’t rest once a problem or opportunity is identified. They take on personal responsibility without complaint, learn and recruit skills as needed, and deliver results despite politics. There is unlimited global demand for founder mentality.
How the job feels
- It’s a tough job, well portrayed by this stream of consciousness.
- Good post from a longtime Spotify PM on the imposter’s dilemma you feel early on in your career explaining your job to engineers/designers, and why this discipline is growing
Other stuff
- Useful leading indicator of Product market fit ask your users how disappointed they would be if they had to stop using your product tomorrow – First Round Post
- How to interview a PM – the ultimate guide
Meta-resources
- The 10 Books Every Product Manager Should Read – from a long time Asana PM
- 74 Articles and Books that will Make you a Great Product Manager – from a Slack PM
Other PMs’ learnings
- Alex Roe’s product management learnings he was at Google Photos, Search, and now an enterprise PM.
Useful tools / resources
- Canny track feedback from users publicly, enable voting on features
I leave you with an all-too relatable meme:
Ernest Oppetit 
[…] Until next time I can talk about the same on a podcast in English, my PM resources & Career Advice pages are actually probably more complete and actionable […]
LikeLike