There are many good things about having technical knowledge as a product manager. However, we also face many struggle uniquely to technical product manager.
You can understand the technical jargon that the engineers use. You can ask the right question or at least phrase it in the right way when speaking with an engineer. You understand the challenge of building something with ambiguous input and therefore aim to helps the engineer who works with you.
Many companies even outrightly seek candidates who have prior experience in development or a computer science degree.
But truthfully, many struggles are unique to a technical product manager than a product manager. The following are my 3 biggest takeaway after transiting from being an engineering lead to a technical product manager.
1. Expected to help in software development
Most software projects get delayed. Sometimes dues to development while most due to other unforeseen circumstances like the change of requirement, unclear specification or delay in design or testing.
As a former engineer, you have the tendencies to jump in and help. You think that you can help work on the simplest ticket and leave the heavy lifting to the engineering team. The people who hire you feel the same too. The C-Level executive knew you have the expertise. They expect you to work on development since every requirement is drafted. If not, why would they hire a “Technical Product Manager” for?
Except, it most often NOT the case. What looks like a simple ticket turns out to be an unclear specification. What you have built requires changes. Since you are the “developers” who wrote it, you know it best to change it. What would take up less than 2 hours now drag longer to a few days.
You start paying more attention to coding and less time on gathering requirements. The founder or CEO takes over to draft requirements. Except, the requirement is too vague and ambiguous. Neither the engineering team nor you could understand. You have to re-take over the drafting of requirements again. Now, you end up with a half bake feature and half bake requirements. Did you manage to help the engineering team at all?
If you are not a former engineer, this will never happen. You can be disciplined and not step into development. But can you set the same expectation with your upper management?
2. Internal Tech Support in every other area
Your strength in understanding layman problems and translate into action plans for the engineer is also your weakness. When you see the operation in other areas is doing inefficient work, you jump in to offer help. You suggest integration tools to slack, email or even other useful Zaiper’s zaps. They don’t understand how to do it, so being kind, you help them set up on their computer.
Soon, the words spread. Everyone looks to schedule time with you so that you can help them with their problem. Tools that you suggested reached a threshold or limit. Instead of just reading the email and subscribe to the paid plan, they ping you for help. They want to continue using it but not willing to pay. They claim that they don’t use often but still want you to fix it. They refuse to go back to paper, pens, and excel. They think that you know how to fix it because you wrote some code for X. They expect you to write some creative hack for them too.
After a few times, you start wondering how you get into this mess? If you are a product manager who is not as tech-savvy, this will not happen.
From managing accounts in Google Suites, settings up campaigns in Mailchimp to updating items in Zendesk. You will most likely have to be the internal support until the team grows larger for a specialist.
3. Being seek more on feasibility vs reason
As a product manager, you want to be behind the product decision. You want to be the person to answer “Why should we build this” or “Why should we remove this”.
However, because you have the technical know-how people approach you differently. They, mostly the C-Level asked, “How long it take to build this?” or “Is it possible to build this?”. They seek you on the “HOW” than the “WHY” on the product decision.
I feel that this is the largest struggle that most technical product managers face. You want to be answering the “WHY” than the “HOW”. Even if a feature is not difficult or doesn’t take many man-hours, you want to assess it by the “WHY” first.
When you are being hired as a technical product manager, remember that “WHY” win “HOW”. Ensure that the expectation is set right on hiring. Ensure that you are here to help with the “WHY”.
Some company seeks a technical product manager to do product management AND development work. Most companies understand the difference and look for a product manager with technical knowledge to help build better software.
However, circumstances changes and due to the know-how of a technical product manager, it can very often be driven to the direction of technical expertise.
I find that due to the unique background, the expectation of you and another product manager can be different. If you are an existing technical product manager, do check back often and ensure that you are here to drive the “WHY”. If you are interviewing for a technical product manager, do set the expectation during interviews.
Thanks for reading! If you like it, subscribe 👇👇
In the day, I am a technical product lead. At night, I am a maker, engineer, and designer. I enjoy learning and building new things about tech, products, and startup. You can find me on Twitter or on my blog.