Understanding the Product!

Why is it important to understand the system architecture as a Product Manager:

First things first, having a good grip on the architecture will help you have good leverage over IT. You’ll know which development is a code change, and which one is a parameter change. That way, you don’t have to rely on IT and agree with whatever they say: you’ll broadly have a better knowledge of the scope of the change. You’ll be able to negotiate better with IT.

Secondly, as a Product Manager (PM), knowing what you can build is as important as knowing what you can’t build: It helps you deprioritize unrealisable things. Makes you take calls quickly if you know what you can’t do.

Thirdly, comprehensive knowledge of one system will help you understand a similar (but newer) system quicker, and adapt easily. The underlying logic of these systems is gonna remain the same irrespective of the system - at least for a similar product.

Above all, the system architecture & knowing its constraints will help you draft a better BRD; both IT and Business will be in sync regarding the Product.

Understanding the Product: Through Testing!

The most interesting phase in the life cycle of the product (at least to me) is testing; this is when you extrapolate your theoretical knowledge and aggregate considerable practical knowledge about the product.

Yes, you can do as much research as possible about the product that you want to build while doing competition benchmarking and preparing requirement documents. But, the theoretical knowledge you accumulated will be utterly useless and fade away like a dewdrop from your memory unless your product reaches the testing phase, and you apply that knowledge while testing.

Only by testing and fixing bugs, your understanding of the product broadens, enabling you to handle customer queries after the launch.

Glossary:

BRD - Business Requirement Document.

PM - Product Manager.

IT - Information Technology (who doesn't know this!).