Why “technically dangerous” PMs help engineers?
Product Managers are often told to let engineers determine the how. The “what and why “ should be the focus of product managers. The lines are becoming increasingly blurry.
Start-ups require their first engineering hires to possess product thinking to make sound technical decisions. Developers are encouraged to sit in user interviews to build empathy with their customers and wear that “product management” hat.
By the same token, product managers possessing technical knowledge can put themselves in the engineers’ shoes. They can comprehend why certain dependencies need to be shipped first — even though it offers less value to users upfront. They won’t get defensive when engineers ask for certain nuisances in their stories.
1. Shield the team from panic attacks
Critical bugs get escalated to the product managers. When the user panicked that the data “disappeared” because the information wasn’t displayed in the user interface, there are a few things you can do to realistically assess the level of severity.
- Query the database to verify that the data is still there
- Open the Chrome Devtools to see if there is an error status code indicating the user is not authorized to access data
Being able to do the first-level troubleshooting would help you calm them down — rather than treating every bug as an emergency.
2. Justify “why it is built that way”
You will often get suggestions similar to “why can’t you do how {insert another application} does it?”. With an understanding of the product architecture, you are less likely to stutter in your answer. Even better, you can translate the constraints in layman terms that non-technical stakeholders can understand.
Here is an example. A table with a large amount of data makes it slow to process data. Users had complained that any part of the apps that rely on that table experienced performance issues. Since support understands that constraint, you can build on that to explain why enhancements that depend on that table need careful consideration.
3. Advocate for your engineers
Rewrite and refactoring take time away from building features — which are typically how stakeholders measure progress. How do you convince stakeholders that the investment is worthwhile?
If engineers are asked to explain the benefits, you will likely get a list of jargons and lose the audience. Furthermore, they get excited about using the latest technologies for reasons that are very different from the business.
With a certain degree of technical understanding, you can connect the dots and describe how the decision aligns with each department’s priorities. For example, investing time to update infrastructure will reduce support tickets due to downtime while your CFO will see a decrease in server cost with autoscaling.
4. Extract insights to define what is good enough
“Can you make this flexible and scalable?” These vague requests are one of the top engineers’ pet peeves. If a Product Manager can put themselves in the engineers’ shoes and present data that makes it a confined problem, the engineers won’t need to consider all the variables or scenarios under the sun.
Say an engineer asks you “How likely would a user {insert edge cases}?” You can run queries to find out the probabilities of this from happening. You make evidence-based decisions on the effort engineers should put in to meet every single users’ needs.
5. Save engineers’ time from reading documentations
It is rare to find software that doesn’t rely on 3rd party applications. For example, most companies rely on Stripe for their payment gateway. Integration with other social media is another common example.
If you can follow the API documentation and get an API key, you can test making a few requests and verify how to pass data to your application. Rather than having the engineers read the API documentations from top to bottom, you can direct them to specific requests or examples relevant to the requirements.
6. Emphasize with challenges engineers face
A PM who is far removed from the developers’ day-to-day may find it hard to comprehend the following scenarios:
- Why can’t engineers just rollback a broken release to undo the damage? (The possible answer is the previous release also include some important last-minute fixes)
- Why are engineers “held back” from deploying their code from broken tests or built?
Just like there are business operations, engineers have their processes as well. Engineers get a dopamine hit when their code is pushed to production. But to make that happen, there are several steps they need to go through.
Summary
Product Managers who can roll up their sleeves and take off the load of engineers will earn their respect. Engineers who consider users’ value are product managers’ dream counterparts.
Related Articles
How to Avoid these Developer Pet Peeves
How to Pick Up Technical Knowledge Without Learning How To Code
