Designing Effective Product Architecture Diagrams: From Abstract Thinking to Practical Steps

1. Abstract Thinking and Product Manager Capability

Abstract thinking extracts common essential aspects from concrete things while discarding non‑essential details, forming a core skill for product managers that differs from hard skills like documentation or Axure.

Many classic formulas and theories—Euler's formula, Maxwell's equations, E=mc², Aristotle's syllogism, Newton's laws, Darwin's evolution—exemplify high abstraction.

Conclusion: The more complex the thought, the simpler the representation, and vice versa.

Product architecture diagrams visualize a product manager’s high‑level abstract understanding of the product, its services, and business model, and should be planned early in the development process.

2. Design Thinking and Drawing of Product Architecture Diagrams

2.1 Why Draw

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

Support technical and operational output: The diagram guides roadmap breakdown, operational plans, and technical architecture proposals aligned with product direction.

Visualize for others: Provides a clear, simple view of product boundaries, development direction, and complexity for stakeholders unfamiliar with the product.

2.2 When to Draw

It is recommended to create the diagram before a complex project starts; skipping it often leads to repeated revisions. If the project is already underway without a diagram, start creating one immediately.

2.3 How to Draw

2.3.1 Diagram Types and Methods

(1) Technical & Functional Product Architecture Diagram

This simple diagram lists existing or planned product functions, abstracts them into modules, and shows relationships such as sub‑features or prerequisite features.

Technical details are often encapsulated within product modules, but important technologies (e.g., OCR) can be highlighted when needed.

(2) Service Architecture Diagram Based on Product, Technology, and Function

This diagram shows how a product’s functions combine with services to form a complete solution architecture, using layered models (bottom, middle, top) to express the structure.

Understanding common models—input‑process‑output, MVC, OSI seven‑layer, software layered architecture—helps in designing such diagrams.

Computer system: input‑compute‑output model

MVC framework: model‑view‑controller

Internet protocol stack: application, presentation, session, transport, network, data link, physical

Software system layers: data storage, data exchange, application support, application, presentation, user

(3) Ecosystem & Business Model Architecture Diagram

This diagram integrates technology, product, service, ecosystem, and business model layers, illustrating how they interrelate to form a comprehensive ecosystem architecture.

2.4 Review and Summary of Drawing Process

Identify the type of architecture diagram needed.

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

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

Produce a logical, clear diagram with explicit relationships.

Conclusion

Simple visual representations often conceal deep complexity; mastering abstraction allows you to express intricate systems in an easily understandable form, demonstrating true understanding of the product, service, ecosystem, and business model.

Source: http://www.woshipm.com/pmd/1065960.html