 |
The previous article described what does it mean to be technical as a PM and how to become one. You don't need to know how to code or have a computer science degree to be a PM. You might just need to learn how your product is being built, learn the language of developers and be mindful about the limits of your knowledge.
There is another way to be "technical" as a PM
Sometimes, when an employer drops the word "technical" into a vacancy, what they are looking for is someone with a technical mindset.
What is the technical mindset?
Technical mindset is a scientific mindset in disguise. It's a data-informed, evidence-based, iterative process of working.
Roughly it consists of the following stages:
- Question states
- Formulate hypothesis
- Design experiment
- Gather data
- Learn
Question states
Scientists are driven to understand the world around so their favourite question is "why?" Unsurprisingly, that's the most often used question for good PMs.
- Why do you do that?
- Why do you do that this way?
- Why would we do that and not something else?
- Why did I start this call at 9 and now it's dark outside and I missed my lunch?
Good PMs always question the status quo. They seek to understand the root causes and inner motivations.
Formulate hypothesis
To change something one first need to know why the change is needed and what kind of result is expected. A hypothesis might be expressed in multiple forms. In essence, it's like saying: right now the world is like that, but it could be like this if we do the following...
Our conversion to checkout is currently 10%. We might increase conversion if we change the "checkout" button colour from grey to green.
The important constraint of a hypothesis: it needs to be testable. A good hypothesis is such that could be proven or disproven by experimentation.
Design experiment
There are numerous ways to test a hypothesis. Experienced PMs know how to select the best methods in given circumstances. The best experiments are such that could be easily repeated by other people. it's a good practice to describe the experiment: what you are going to do and what you hope to have as a result.
Gather data
Having your hypothesis and an experiment lined out (and you might try several experiments to validate the same hypothesis) you now need to execute your research and gather data. Best PMs always keep raw data and their interpretations separately so then anyone might analyze the data themselves and maybe come to other conclusions.
Learn
At the end of the cycle, PM would synthesise all data, compare the results with the hypothesis and draw conclusions. Learning happens in any case! If you confirmed the hypothesis - good, if you didn't - even better. The desired outcome is not a proven hypothesis but learning. To conclude a cycle, PM could recommend doing one of the following:
- Modify the hypothesis
- Design a different experiment
- Drop the hypothesis
- Turn the hypothesis into a delivery item
And then you come back to step one and repeat the whole process all over. Obviously, it's a rough framework that one can modify it for their particular circumstances. However, if a product team follows these principles no one can deny them being "technical".