Learning to Call BS
Learning to Call BS

    « Home
    / Posts
      
      2021-02-27

How do you become a more effective product manager (PM)? Many will say you need to learn to code. Some will point to design. Others will argue SQL is the key. Each is partially right, but missing the underlying point [1]. 

PMs don't need to code.
PMs don't need to design.
PMs don't need to write SQL.

PMs need to understand each enough to call BS. 

What does it mean to call BS? It is the art of challenging constraints. And it can happen at any stage in the product development process. 

If a sales rep tells you a feature is absolutely critical, can you access the data to see if it's true? Even better, can you ask the right question to determine what data to look for? This highlights the difference between being able to write SQL and knowing what kind of data you need in the first place.

If an engineer tells you something can't be done, can you walk through the system with them to understand why? Can you provide more context that changes the constraints of the problem? You aren't writing the actual code. You are equipping them with the information they need to solve the problem. 

There are countless examples but you get the point

The best way to learn to call BS is through observation and iteration. First you need to observe how others think. When an engineer or designer makes a decision, ask them why. Don't stop at the surface-level answer. Dig for more but make it clear it's because you want to learn, not because you want to change their mind. Identify the assumptions they are making. Figure out which are valid, and which could be challenged. But don't try to change the past. You are in observation mode. 

The next time a decision is being made, reflect on your newfound knowledge, and think of a question that can push others to challenge the assumptions that support their logic. If a certain feature is hard to build , ask how they would build it and where it would break. You may be able to provide additional context (e.g. the customer doesn't care about an edge case they are worried about). Or you may be swiftly shut down. That's okay! You will undoubtedly learn something new for the next time. Iterate. 

Over time you will build the muscle that tells you when to push and how hard. At that point, it's your duty to start teaching others how you think, so they can call BS on you. 



[1] To be clear, learning to code is valuable. Learning to design is valuable. Learning to write SQL is valuable. But none are required to be a product manager. And none of those skills (in isolation) is going to be the thing that sets you apart. That doesn't mean you shouldn't learn them. 


