AI writes code faster than ever, yet in review meetings we still cannot answer "what are the states of this feature," and when requirements change we discover half the flows were never thought through. This embarrassment is not a personal failing; it means the product architecture was never built properly. A methodology piece this week on Juejin spells it out concretely: one feature-list table and four diagrams (information architecture, feature architecture, business flow, and state machine) are enough to clarify the skeleton of any product. We have noticed this conversation matters even more in the AI era than before.

What this is

The article comes from Juejin author "怕浪猫" (Pà Làng Māo), Chapter 5 of a product-manager tutorial series. Its core argument: product architecture is "the structure that organizes every element of a product." Its value is not in the deliverable document but in forcing you to sort out the 200 features, 50 flow nodes, and 30 roles rattling around in your head.

The author provides an actionable template:

  • 1 table: a feature list / requirements matrix with six columns — ID, module, feature name, user role, priority, and dependencies. Module division takes two paths — by business domain (for complex B-end products) or by page entry (for C-end products).
  • Information architecture diagram: answers "what information exists in the product, and how are these information entities related?" — the foundation for database design.
  • Feature architecture diagram: a layered structure (base capability layer → content supply layer → operations layer → presentation layer) that answers "which features can be reused," preventing reinvention.
  • Business flow diagram: exhaustively maps every branch in the user's path, including exception branches. Without it, unexpected bugs surface post-launch.
  • State machine diagram: answers "what states does an object have, and how do they switch?" The article cuts off mid-explanation here.

Industry view

Supporters argue AI coding tools (Cursor, Copilot) have moved "writing code" off the critical path, but when dev asks "what are the states, what are the edge cases" during a PRD review, AI cannot help — those judgments must come from the product manager's architectural thinking. A senior product director told us in an interview: "The stronger AI gets, the more it exposes the product manager's短板."

Counterpoints deserve hearing. One indie developer argues that diagramming to this level of granularity is itself over-engineering; early-stage products pivot three times a day, and the cost of four diagrams far exceeds the return. The right move is to validate with low-fi prototypes first, then backfill architecture diagrams. Others point out this methodology depends heavily on a stable business domain — for SaaS (subscription software) and AIGC (AI-generated content) products, where boundaries keep shifting, dividing modules "by business domain" breaks down fast.

Impact on regular people

For enterprise IT: if your company is doing AI transformation or internal system refactoring, this is more worth prioritizing than "which large model to use" — unclear architecture just makes AI accelerate the chaos.

For individual careers: for product managers, business analysts, and solution consultants, "can you draw it clearly" is replacing "can you write it clearly" as the new hard currency.

For the consumer market: no direct impact in the short term, but you will get more stable, less buggy apps and SaaS tools sooner — provided the product managers behind them are taking diagrams seriously.