Why & How should PMs understand Technology

Vikram Goyal
Agile Insider
Published in
5 min readApr 28, 2021

#2. It improves the quality of your day-dreaming

Image by computhink

There was a deathly silence in the room.

It had been three weeks since our engineering team had started work on a project involving a third party integration. After three weeks, the team realized that we had made an incorrect assumption about how the service worked.

The error was not small. Significant changes would need to be made to the backend. The effort would delay the project by atleast two weeks.

I was silently blaming the engineers for not being diligent enough. Probably, they were blaming me for not giving them enough time to research.

We finally accepted reality and began planning the next steps. The team decided to spend some time understanding all scenarios before starting again.

The storm passed.

We delivered the project. However, it required lot of rework and we were significantly behind our original timeline.

As we did the retrospective, one thing became clear — I had made some assumptions. These made their way to the design. The tech team believed those assumptions to be true and began working.

Main Issue: I didn’t spent time to understand the complexities associated with the project. Had I involved the tech team early on, we would have been in a much better position.

The lesson learned was clear — Understanding technology is vital for success as a Product Manager.

In the subsequent paragraphs, I highlight some questions a beginner might have and attempt to answer them.

1. Why should I understand Technology?

Understanding technology helps you in the following ways:

  1. Helps build trust in your team: Engineers love PMs who try to understand their challenges and collaboratively work on resolving them.
  2. Better quality of ideas: Since you know what’s possible and what’s not, your ideas are grounded in reality.
  3. Get better with scoping down a project: If you understand what’s adding more technical complexity, you can make better trade-offs. Making trade-offs is a very important skill to deliver things on time.
  4. Become more efficient: Your PRDs and specification documents are more comprehensive. Since you are collaborating well with the tech lead/EM, most of the important technical considerations are taken care of in advance.
  5. Identify the complexities associated with a project: You better understand the complexities associated with a project. This helps you appreciate risks involved and plan mitigation strategies. Very complex projects generally need a POC first before starting full scale implementation. (I learnt this the hard way)

2. How much Technology do I need to know?

Only a high-level understanding of technology is required.

You should be able to answer the following questions:

  • What are the different systems that comprise your application? (popularly referred to as tech stack)
  • What is the role of each of these systems?
  • What are the main risks associated with each system? How are these risks mitigated?
  • Which system is managed by which team?
  • How do these systems communicate with each other? (For Example: APIs)

Pro TipYou do not need to know coding in order to answer these questions. So, don’t use that as an excuse.

3. How do I get started with understanding the tech?

To get started, you need to catch hold of an engineer who understands the system and is willing to help you out.

Once you identify them, set up a meeting and ask them to explain how the damn thing works behind the scenes!

The questions mentioned above can be used as a starting point.

By the end of the meeting, you should have an architecture diagram on paper. This will probably contain labelled rectangles joined to each other by arrows.

You might not understand everything. That’s okay. Focus on understanding the terms used and what was the role they played. In due course of time, your understanding will become better.

Pro Tip: The best way to understand is to try explaining the architecture yourself to somebody else in your team (whose not an engineer).

4. How do I deepen my understanding after starting?

Just one sitting with an engineer won’t give you the complete picture. Understanding technology is hard and would require diligence from you.

The following practices can be used to solidify your understanding.

Use every new project as a learning opportunity

  • Involve the tech team as soon as you decide to prioritize a certain feature.
  • Understand from them, 1)what all layers would be affected? (frontend, backend, infrastructure etc) 2) How much dev effort would be involved in each layer?
  • Understand the technical challenges involved in building the feature.

This will give you a lot of the clarity on the technical architecture, the systems involved and what adds complexity. (The more layers a project touches, larger is the complication)

Learn from Technical Outages

Production Issues and technical outages are another good opportunity to understand the technical architecture better.

If the issue impacted your focus area, sit down with the engineer to understand the specifics — 1)which system was affected? 2)what was the reason? 3)What can we do to prevent it from happening again?

Repeating this exercise will help you develop clarity around your system and the weakest links in the chain.

Maybe, you would also want to prioritize making the those weak systems more robust?

5. What else should I keep in mind?

As you begin this journey of learning, I would request you to keep the following things in mind.

  1. Don’t be afraid of asking questions: No matter how dumb these are, always go ahead and ask them. The more you ask, the more clarity you get.
  2. Visual representation helps you understand things much faster: While talking to an engineer, if things are going above your head, ask them to explain by drawing the stuff on paper.
  3. Engineers love PMs who try to understand their language and challenges: So, don’t brush aside their concerns. Work with them to identify the challenges they foresee and the ways to resolve them.
  4. Don’t tell developers ‘how to implement things’ with your newfound knowledge: This pisses them off and you come across as arrogant.

Given the myriad benefits of understanding technology, you shouldn’t have second thoughts around starting this journey. While its easy to get started, the challenge is to keep the momentum going.

However, be rest assured that this will be an extremely rewarding journey. Besides becoming a better PM, you will also become the darling of your engineering team. :)

--

--

Vikram Goyal
Agile Insider

Currently PM@Airmeet — building a kick-ass product for conducting remote events and conferences.