30 Product Management One-Liners

A collection of product management wisdom accumulated through 11 years in business:

1. When you start working on a product, make sure you develop a deep understanding of business goals. The next task is to figure out how to leverage design and technology to meet those goals.
2. Define/clarify a product vision before jumping to features. Until you have a clear vision, chances are you’ll waste time doing unimportant work.
3. Build your own opinion about the industry and domain you’re working in. Attend conferences, listen to podcasts, subscribe to industry newsletters.
4. Know how exactly does your product create value. Make sure you explain it to every person on the team (e.g. as a part of onboarding).
5. Whenever possible, look for direct access to end-users or customers buying the product (rather than relying on a middle man).
6. Use the product you manage. Get into the user’s shoes as often as possible to understand their pains.
7. Appreciate the feedback, especially if you don’t like it. There’s no such thing as “bad user/customer feedback”.
8. Expose issues as early as possible. If you see the team is working on a wrong initiative, stop it and replan (even if you need to persuade a client).
9. When something goes wrong, make sure to pro-actively get to stakeholders with a full explanation to what happened and why, but also prepare to outline one or more ways to address the problem.
10. If you need to change someone’s mind, support your message with data and, ideally, user feedback.
11. Provide the team with “why are we doing this”. Don’t dictate how things have to be done. Nothing is more demotivating to engineering teams than context-free “just build this feature cuz I said so” ticket.
12. Co-creation: make sure you work side by side with designers and engineers on the product. In the best functioning teams, the pitching happens from product, design, research, and engineering.
13. Always validate your assumptions, especially those you consider to be obvious.
14. When you decide to add a new feature, think of what can be simplified or removed. “Complexity tax” is a costly one.
15. Every task, including “refactoring” or “design polishing” should be linked to your product’s big goals. If you can’t connect it, why do you do it?
16. Over-communicate. As Jeff Weiner, CEO of Linkedin, once said: “If you want to get your point across, especially to a broader audience, you need to repeat yourself so often, you get sick of hearing yourself say it. And only then will people begin to internalize what you’re saying.”
17. Start each piece of documentation with a one-pager (problem, data, scope, success metric). If you can’t fit it into one page, you haven’t got a clear enough view of the problem yet. Keep working on it.
18. Document everything that you are building and not building (at least try!).
19. Aim to have a maximum of two sources of product documentation — one for strategic info (roadmap), and another for tactical (backlog). Link them.
20. Don’t ever promise ETAs or estimates on the spot without talking with the team.
21. Underpromise, overdeliver. In other words, success is deliverables minus expectations (don’t ever go negative).
22. Plan at least 10–15% of the team’s capacity for eliminating technical debt and initiatives research. The ROI of this work is always positive.
23. Deadlines happen. Focus on how to deliver maximum value with the time you have (usually there are nice-to-have items to simplify or postpone).
24. There will never be enough data. Make your best bet in conditions of uncertainty, but think of how to try things at a smaller scale.
25. Your development team will never be big enough. Focus and prioritise.
26. Focus on your product work and leave project management to PMs. Otherwise, process-related tasks will usurp all your available time.
27. Agree with the team on the Definition of Done, but make sure you personally try the new functionality before releasing it.
28. Know your product’s technical stack. Get an understanding of its database schema. It will save a lot of time and nerves in architectural discussions.
29. Accept full responsibility for failures. Share praise for wins with the team.
30. If you work on an enterprise product, you’ll inevitably be asked to develop a one-off feature based on a super-important customer request. Track resources spent on these features and platform-wide adoption. Then turn them into improvements that work for a broader audience.

To be continued…??