18 Things I wish I could tell myself as a starting Product Manager

This is a list of things I wish I could have told myself when I starting off as a Product Manager years ago. As many others rolling into the job, I didn’t know what I was getting into. I’ve often caught myself thinking that it would have been very valuable knowing some of these things up front. Someone should have told them to me the first day on the job, as a cheat sheet to shortcut some of the harder learned lessons. You probably can’t shortcut some of those lessons, but hopefully they help you as I think they would have helped me.

• Lesson 1: Products are a reflection of the structure of the organisation in which they were built. This is known as Conways law. Watch out for products that feel like they are stuck. It’s because their organisational structure is too.
• Lesson 2: Focus on outcomes. Output can be important, but nothing is as useless as doing efficiently what should not be done at all. Almost all forms of roadmap trick you to work on output.
• Lesson 3: combine different layers of insights. Quantitative insights only are too limiting. Qualitative insights only are too limiting. Learn to combine both and thrive.
• Lesson 4: Product management can be unintuitive. It often feels like you are not making progress. One of the annoying things is that enabling people feels very different to, say, finishing up some piece of code and seeing it go live in production. That doesn’t mean your work is not valuable, you are still making progress.
• Lesson 5: Frameworks are a useful tool, but not more. Frameworks such as Scrum are limiting. There are many people stuck on this. They start looking at a framework as more than a means to an end. Outcome is the only thing that matters.
• Lesson 6: Read books from product thought leaders. Start with the book inspired. If not everything makes sense the first time, read it again after a few months.
• Lesson 7: listen to engineers, but not always. Engineers will always tell you that you need to refactor. While they can be right, your job is to remind people about outcomes.
• Lesson 8: Make sure not to fall into the trap of YAGNI — you ain’t gonna need it. Basically, don’t build or overengineer features with the team you won’t need anyway.
• Lesson 9: There is a limited lifetime to user stories and features. It’s good to be prepared but preparing too much will result in a backlog with things you are not going to cover and ultimately will be irrelevant some months or even weeks down the line.
• Lesson 10: Sequential focus brings exponential return. Juggling 100 things at the same time is hard and makes you feel that you’re doing none of them well. You should still have focus time, even though your main job is to enable people in the team which means you are maximising their focus time.
• Lesson 11: Do the hard things first. Postponing that important decision will not make it go away. Engineers or stakeholders, or whoever you’re working with, will remind you. By then, you might have lost time.
• Lesson 12: Your backlog size and ‘window of attention’ is fixed. Many people will fight you on this because they don’t see the total number of features on your plate like you do.
• Lesson 13: You will always miss some things when working on a feature. Always. This is why refinement sessions or at least talking to engineers is so crucial. Typically, the sooner you get them involved in the process, the better.
• Lesson 14: You will find out that there are roughly two tracks you work on. discovery and delivery. (This is called 2-track agile or dual track agile) Discovery is about understanding, validating, and refining what you want to build. Delivery is about building what you ‘discovered’.
• Lesson 15: Don’t give in to the pressure of just releasing features. Don’t become a feature factory. Understand that Invalidating an idea is also valuable. The faster you invalidate ideas, the more you can focus on initiatives that can actually drive outcome.
• Lesson 16: Most roadmaps are useless. A lot of roadmaps are just a useless collection of items on an imaginary timeline. The best framework for roadmapping I’ve seen is GIST. This is because it tries to reflect reality better and focus on outcomes. Churchill’s quote on democracy feels relevant here. He said democracy is the worst form of government, except for all the others. Similarly, GIST is the worst roadmapping system, except for all the others.
• Lesson 17: Most features don’t have any impact. They literally don’t move any meaningful KPI. If you didn’t know this yet, it’s called the inconvenient truth of product management and another good reason to read inspired.
• Lesson 18: A good idea is most often not a good reason to build something. If you are convinced you have a good idea, it gives you the lowest possible non-zero confidence. If your colleagues get excited it’s still extremely low. Testing with users is the only way to find out. The faster you do this, the less money you waste.

What’s Next?

If you want to get more insights like these on all things product, follow me on twitter here.