Know thy assumptions
One of the things that I’ve found useful as a product manager is being conscious of statements and claims - if I am making an assumption or stating a fact. The former is what I think is true and the latter is true because I have evidence to back that. That knowledge of difference between a fact and assumption could very well be the difference between the success and failure of a strategy you are executing or a feature you are shipping.
How to get better at differentiating assumptions from facts?
All of us have biases, one of the most prevalent is the confirmation bias - “Confirmation bias is our tendency to cherry-pick information that confirms our existing beliefs or ideas. Confirmation bias explains why two people with opposing views on a topic can see the same evidence and come away feeling validated by it.”. If we keep our beliefs to ourselves and only tell the team what is the next thing we need to do, there is a high likelihood that it will fail. It is important to be open about the beliefs and the evidence because of which we recommend Plan A or B or C, and be willing for that beliefs to be challenged. The following two things have helped me in my career to validate(or differentiate) my assumptions vs the facts.
Write. Writing is a great tool to clarify your thoughts and tease out the assumptions you made. Do not write bullet points, write a script. Imagine you are talking to a person (your manager) or an audience (your engineering team) and write down what you would say to them about the strategy that you have in mind or the problem that you want your team to solve. Mull over it, do not send the draft to anyone. Sleep on it, take a couple of days, reread it, rewrite it and restructure it. When you feel that this is in a good enough shape, then you have your v1. The trick to knowing you have reached v1 is when you are satisfied that if your skip level manager reads it, he will understand and back your plan. Once you have the v1, move to the next step 👇🏽
Peer review. Peer review is effective because you are not afraid of judgement (if you send your first draft to your manager, you might feel that they will not promote you because of your all-over-the-place thinking). This is where you should leverage your peers. You will be surprised at the many things you assumed while writing this and the many gaping holes(and leaps) in your page. Send them the link to the version 1 of your document (not draft, but v1). Let them add comments on your assumptions - acronyms that you thought everyone understood, the leap you made from user research to problem definition, the lack of evidence for the business impact of solving the problem etc.