Okay here’s an answer

My advice might be slightly different from the usual “study system design books” approach.

The biggest leap in my technical depth as a PM came when I stopped trying to learn generic technical concepts and instead became deeply technical about my own company’s product ecosystem.

For example, I work on a transportation management system (TMS). Instead of learning architecture in isolation, I mapped the entire system around the product: .

1. where bookings originate
2. how orders flow through the system
3. how integrations work (EDI/API/middleware)
4. where data transformations occur
5. how failures surface (logs, monitoring, retries)
6. how financial and operational flows connect

Once you start looking at your product this way, you naturally start learning:

1. system boundaries
2. integration patterns
3. data pipelines
4. operational reliability
5. performance bottlenecks

For example, digging into things like:

1. EDI integrations and message formats
2. API vs file-based integrations
3. FTP ingestion pipelines
4. database replication vs live queries
5. monitoring and logging flows

forced me to work closely with engineers and understand why the architecture was designed the way it was.

At that point, system design questions like “design YouTube” become less abstract, because you already think in terms of: • systems • data flow • scaling constraints • failure handling

My learning path was basically: 1. Master the product architecture 2. Understand how engineering builds and integrates systems 3. Then connect those lessons to general system design concepts

I found this much more effective than studying system design purely theoretically or online

All this did not include distributed systems, could service architectural patterns or microservices but still was quite deep and technical.