The “knowledge curse” dilemma of Product Managers with engineering background: Getting Tech Leads to implement customer requirements without telling them how to do it
You used to be an engineer on the implementation end of customer requirements and now you are a Product Manager, you have crossed to the “other side”: marketing. You now have to get Tech Leads to implement customer requirements; you are no longer in a tech implementation role.
You tell the Tech Lead the customer requirements (e.g. ”error message is not specific enough and customer needs to know where it comes from”) and the way you think they should be implemented (e.g. “you should use a random generated ID to lock to the machine”). Tech Leads pushes back saying: “I don’t think this is the right thing to do”.
You end up talking about details which to you are obvious and for them they are not. You start to get annoyed. You used to be that engineer working on this very problem, you know this product inside out and to you it is obvious what the solution is. You KNOW that this is the right solution yet why won’t the Teach Lead take it on?
The Engineering Instinct (and what happened)
Being an engineer before you started in product management means that when you think about a problem, you also naturally think about the solution and how to go about implementing the solution. It was your job to do this…
You rightly told the Teach Lead the problem the customer has with X product and what is the desired outcome. The pushback started when you also started talking to them about how s/he should solve this problem to bring about the outcome the customer needs. It’s natural you think this way, it’s been your job for years to use this very problem solving skill you have. And, without realising, you got emotionally engaged and began pushing on the tech details on how the Tech Lead should be doing it and… unfortunately that is not your job anymore, it’s his/her job.
You used to be that engineer who resolved these issues, you might even be an expert in this particular field, and to you it is natural when you think about a problem to also think about how you’d go about solving it. Try not to feel bad about this. It was your Engineering Instinct that kicked in.
Why was the Tech Lead pushing back (despite your tech solution being absolutely correct)?
It could be for several reasons:
1. The Knowledge Curse:
You might not have given them enough details about what the problem was (or none at all!) or what was the desired outcome, but you spent most of the conversation telling the Tech Lead about what you think “should” be done (HOW s/he “should” solve this problem).
This is the most common scenario. The reason the Team Lead pushed back on your suggested way to solve it is because they did not have the same information about the context/problem/desired outcome/project limitations (because you didn’t necessarily realise they don’t have this information) for them to reach the same conclusions as you. So to them, your idea did not fit the problem/limitation they have been told exists.
2. The (lack of) Updated Information
They might know more about the tech details of what would work than you. Your information of what might work could be out of date, yet you might think you still know all the technical details behind the product.
3. “It’s my job to do this”
They might simply not like to take on someone else’s suggestion, because it is from someone else and they feel it is their job to come up with something original. They might want that feel good factor when they find the right solution.
What can you do next time?
When talking to the Tech Lead to tell them what the customer requirements are, it is best to stick to:
- The problem the customer has: e.g. “At present the system is not able to identify a single machine the error comes from. Once we release, we can’t change this feature”
- The desired outcome of the customer: e.g. “We need the system to provide a specific error message for each problem so we can tell which machine the problem comes from. We also need something that will be able to resolve after release.”
- Any other limitations/context of project: e.g. customer would like to get an URL to resolve error and a link to the specific machine, as this fits with their error ticketing system.
My suggestion would be to refrain from saying what they “should” do about this problem: “you should use a random generated ID to lock to the machine” unless they ask if you have any suggestions.
What you could say is: “I don’t know if using a random generated ID to lock to the machine, would work, but I am sure you will be able to find this out better than I can.”
I know you were only trying to help the Team Lead as the solution was so obvious to you, and finding the solution feels so, so, so good and you are such a natural at finding solutions. In this situation, the job of the Product Manager ends at bringing the requirements (problem, desired outcome and context/limitations of project) from the customer to the Team Lead. It is then up to the Team Lead to find the right solution to this problem and to feel good about coming up with great solutions.
It doesn’t mean you can’t share your ideas; in fact I would encourage you that next time you sense the engineer instinct in you wanting to put forward solutions to ask the Team Lead if they would value any suggestions. Who knows? You both might feel good about finding a joint solution.
