Product Manager Skills: Abstract Thinking and Designing Product Architecture Diagrams

1. Reflections on Abstract Thinking and Complexity for Product Managers

In daily work, a playful remark about abstracting everything except a person highlights the concept of abstraction: extracting common essential aspects from concrete things while discarding non‑essential details.

Abstract thinking is a soft skill distinct from hard skills like documentation or prototyping; it is cultivated through practice and is foundational to many advanced theories and formulas such as Euler's formula, Maxwell's equations, and the law of conservation of energy.

The key insight is: the more complex the thought, the simpler the expression, and vice versa.

For product managers, an architecture diagram is a high‑level visual representation of the product, its services, and business model, serving as a crucial planning artifact at the start of development.

2. Design Considerations and Drawing of Product Architecture Diagrams

2.1 Why Draw

Clarify product direction: Helps answer questions about where the product should go in the next six months, how to phase requirements, dependencies, competition, and future scalability.

Support technical and operational output: The diagram enables clear decomposition of the roadmap and guides the creation of operational plans and technical system architecture.

Visualize for others: Provides a simple view of product boundaries and development direction, useful for presentations and onboarding.

2.2 When to Draw

Ideally create the diagram before a complex project begins; skipping it often leads to repeated revisions and wasted effort. If the project is already underway, start drawing now to gain the benefits.

2.3 How to Draw

2.3.1 Classification and Methods

(1) Technology & Feature‑Based Product Architecture Diagram

This simple diagram abstracts and groups product functions, showing module relationships such as dependencies and hierarchical inclusion.

(2) Product‑Technology‑Service Service Architecture Diagram

This diagram builds on product functions to illustrate a complete solution architecture, using layered models (bottom, middle, top) to express the hierarchy.

Understanding common models—such as input‑process‑output, MVC, OSI layers, and layered software architecture—helps in constructing these diagrams.

(3) Ecosystem & Business Model Architecture Diagram

This comprehensive diagram integrates technology, product, service, ecosystem, and business model layers, showing how each component builds upon the previous.

2.4 Review and Summary of Drawing Steps

Identify the type of architecture diagram needed.

Confirm the elements to include (technology, product, service).

Define relationships: simple diagrams use inclusion, support, parallel; complex diagrams incorporate appropriate models and layered relationships.

Produce a logical, relationship‑clear diagram.

3. Final Thoughts

Simple representations often hide deep complexity; mastering abstraction allows you to convey intricate products, services, ecosystems, and business models with clear, concise visuals, demonstrating true understanding.