I often have a conversation like this with engineering team:
There are two lessons in this conversation.
1. Always explain why and problem before describing the solution.
Whenever you, product manager, describe a problem, be sure to describe why it is a problem for customers. Without understanding why, engineering team has to guess as to why the problem is important and what pain they are trying to address. Not knowing the exact reason why it is considered as a problem, the team is forced to make educated guess as to what simplification would be okay for customers. More often than not, these simplifications are changing the nature of the problem so as to the solution no longer works for customers.
2. Not doing anything is about the worst thing when you know something is wrong.
Not communicating why leads to paralysis of decision making. Not making a decision means not doing anything. This is especially bad when you know there is a problem. When you know something is wrong, inaction is about the worst thing that you can do because it guarantees that you are going to disappoint customers by maintaining status quo. Even if it is a wrong decision, it's better to make that decision fast, learn from it, and make the correction.
If you do this fast enough, odds are in your favor that you and your team will choose the right solution soon enough. But if you are not making decisions fast, then whole bets are off.
Make sure you are enabling your team to make decisions often and fast. Even if it's the wrong one, having the fast and frequent decision making beats decision paralysis.
A: So what happened with X? The piece that we discussed the other day?
B: No update. There was a discussion and that was about it.
A: Didn't we agree that we will do Y to get more data?
B: But we weren't sure whether it's really needed. We didn't think customer was asking for Y. It was not clear to us.
A: We just lost a few days. When we realize there is something wrong, we have to do something. Anything.
There are two lessons in this conversation.
1. Always explain why and problem before describing the solution.
Whenever you, product manager, describe a problem, be sure to describe why it is a problem for customers. Without understanding why, engineering team has to guess as to why the problem is important and what pain they are trying to address. Not knowing the exact reason why it is considered as a problem, the team is forced to make educated guess as to what simplification would be okay for customers. More often than not, these simplifications are changing the nature of the problem so as to the solution no longer works for customers.
2. Not doing anything is about the worst thing when you know something is wrong.
Not communicating why leads to paralysis of decision making. Not making a decision means not doing anything. This is especially bad when you know there is a problem. When you know something is wrong, inaction is about the worst thing that you can do because it guarantees that you are going to disappoint customers by maintaining status quo. Even if it is a wrong decision, it's better to make that decision fast, learn from it, and make the correction.
If you do this fast enough, odds are in your favor that you and your team will choose the right solution soon enough. But if you are not making decisions fast, then whole bets are off.
Make sure you are enabling your team to make decisions often and fast. Even if it's the wrong one, having the fast and frequent decision making beats decision paralysis.
No comments:
Post a Comment