Thoughts on Abstraction, Complexity, and Designing Product Architecture Diagrams

Article Structure:

Reflections on abstraction and complexity in product manager capabilities.

Design considerations and drawing methods for product architecture diagrams.

1. Reflections on Abstraction and Complexity for a Product Manager's Personal Ability

In daily work, you might joke with a female programmer that you can abstract everything except her, highlighting the importance of abstraction in product thinking.

Abstraction means extracting common aspects, essential properties, and relationships from concrete things while discarding non‑essential details.

Abstract thinking is a crucial soft skill in a personal capability model; unlike hard skills such as documentation or Axure, it is cultivated through practice and time, and underlies many advanced theories and deep thinking.

Classic examples of highly abstract concepts include Euler's formula, Maxwell's equations, E=mc², Aristotle's syllogism, Newton's three laws, and Darwin's theory of evolution.

Conclusion: The more complex the thinking, the simpler the form, and vice versa.

An architecture diagram is a visual representation of a product manager's high‑level abstraction of the product, services, and business model, and should be planned early in product development.

2. Design Thinking and Drawing Methods for Product Architecture Diagrams

2.1 Why Draw Them

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

Support technical and operational output: Once the diagram is defined, project milestones (RoadMap) can be broken down clearly, and team members can produce operational plans and technical system architecture proposals aligned with the product direction.

Visualize the product architecture for others: Provides a concise view of the product’s scope, boundaries, and development direction, useful for presentations, planning, or summarizing projects.

2.2 When to Draw Them

Recommended before a complex project starts: Skipping the diagram and jumping straight to prototypes, PRDs, or kick‑offs often leads to repeated changes and rework.

But it’s never too late: Even if a project is halfway through, you can start creating the diagram now following the steps below.

2.3 How to Draw Them

2.3.1 Types and Drawing Methods

(1) Technology & Feature‑Based Product Architecture Diagram

This simple functional diagram lists existing or planned product features, abstracts them into categories, and shows module structures and relationships (e.g., sub‑features belonging to larger ones, prerequisite dependencies).

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

(2) Product‑Technology‑Service Service Architecture Diagram

Example: Alibaba Cloud Internet Finance solution architecture, which abstracts core functions and products, divides them into layers (bottom, middle, top), and shows the complete solution.

Understanding common models and frameworks (e.g., input‑process‑output, MVC, OSI seven‑layer model, layered software architecture) helps in designing such diagrams.

Computer system: input‑compute‑output model.

MVC: model‑view‑controller.

Internet: 7‑layer protocol stack.

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

(3) Function‑Technology‑Product‑Service Ecosystem & Business Model Diagram

Functions rely on technology, products on functions, services on products, and the ecosystem/business model on all of them.

This diagram illustrates how technology, product, and service components together form an ecosystem or business model.

2.4 Review and Summary of Drawing an Architecture Diagram

Identify the type of diagram you need.

Confirm the elements (technology, product, service).

For simple architectures, define relationships such as contain, support, parallel; for complex ones, reference appropriate models, layer them, and then apply simple relationship rules.

Produce a logical structure with clear relationships.

Conclusion

Simple representations often hide great complexity, which is transferred to the thinking layer. As Einstein said, if you cannot express a complex concept in the simplest way, you have not fully understood it. When a simple prototype or flowchart can convey a product, service, ecosystem, or business model, you truly grasp the subject.

More recommended reading:

Application Architecture: Separating Business Logic from Technical Details

Architecture Design – Summary of Architecture Knowledge System

Collection: Data Backup Technology Knowledge Overview

Architect's Growth Path (4) – Architecture Knowledge System (Methods)

Architect's Growth Path (3) – How to Become an Architect (Methods)

Architect's Growth Path (2) – Essential Skills for Architects (Goals)

Architect's Growth Path (1) – What Is an Architect

Click "Read Original" for free access to a large collection of documents.