How to PM
My wife Karishma is a product manager. We actually met working together at New Relic - I was a software engineer and she was my PM. To date she is still the best PM I ever worked with.
The other day she wrote this excellent guide to how she PMs and then shared it with me. She doesn’t have a blog, and I love her approach to product management, so I thought I’d share her guide here.
How I PM (by Karishma Irani)
-
Anything that can help the product and user experience is my job (sales, support, docs, etc.).
-
Outcomes > Outputs (read Escaping the Build Trap).
-
Talk to customers. All the time. Especially first-time users as your product grows and becomes bulky. Always have ~5 customers you can slack or text message for instant feedback.
-
More intuition, data, and customer sentiment, less frameworks/process. If you can shorten (or skip) process to ship something faster, do it (and maybe come back to it after). Get out of your own way.
-
Rely on and enable engineers to invalidate terrible ideas and influence the product direction. Opinionated engineers that love building useful products for themselves is why I got into devtools.
-
Network to maintain a pulse check on how other teams in the org feel about the product – the best insights can come from anywhere.
-
Always have opinions. Be able to list the top things that are working and not working for the business at any given time. I have opinions about the font used for menus at restaurants.
-
Making mistakes, then acknowledging and fixing them, is superior to not doing anything at all.
-
Measure a good week in terms of how much you changed the product and impacted customer experience, not so much how many documents you wrote, slides you made, or meetings you attended.
-
Be direct, concise, and honest in your communication. Assume good intent. Accountability is good.
My thoughts
#1 is one of my favorites. The product role is loosely-defined compared to engineering or design. The solution to this lack of definition is to be helpful in every possible way. If a designer lacks context on a problem, work with them so they can create excellent designs. If the team is too inwardly focused, go talk to users and come back with new information, or set up a conversation between engineers and sales or marketing to give the team perspective on how the software is sold (#6). Teams will naturally silo, and the PM is often in the best position to break down those silos and build bridges.
Building on #6, one of the best aspects of working with Karishma is that she is always connecting people who should know each other, and in particular she was good about connecting teams who have a negative view of each other. Instead of just accepting that marketing doesn’t know how to talk about the product, Karishma will find a way to support marketing better.
#5 was another enjoyable aspect of working with Karishma. She really loves feedback from engineers and she creates an environment where engineers feel comfortable calling out a product decision that doesn’t make sense.
Karishma is right to be skeptical of processes and frameworks (#4). Most problems do not fall neatly into a process, and often processes and frameworks are misused by management.
#9 is very related to #2 and #4. PMs (and other roles) can fall into a trap of spending way too much time writing documents, creating slides, and attending every possible meeting. Remaining focused on improving the product and customer experience above all else does wonders for productivity and morale, and Karishma is great at calling out when a process or unnecessary request is getting in the way of doing good work.
While Karishma doesn’t mention this, one of the best, if not the best, aspects of working with her is that she is fun to work with. She’s energetic, she brings people together, and she has this incredible ability to improve even the most difficult work situation. She works hard and really cares about the outcome over bureaucracy and politics.