Skip to main content

Another way to be technical as a PM

 


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: 

  1. Question states 
  2. Formulate hypothesis 
  3. Design experiment 
  4. Gather data 
  5. 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". 

Popular posts from this blog

Fogg Behavior Model

Have you ever wondered why you do certain things? Why are some behaviors easy and joy to do while other not so? And your customers - have you ever struggled to understand their behavior?
BJ Fogg, from Stanford University, has created simple and powerful behavioral model for persuasive product design.


Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions. But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

7 steps of Product Discovery

Before building a product - how do you know what product to build? While building a product - how do you know what features are the most valuable? After you've built a product - how do you know if to tune stuff or add a new one?