Mastering B2B Product Design: Core Principles for Scalable Solutions

Background

Every product evolves to meet user needs, solve pain points, and create value. Common classification methods include toC vs toB, client types (wap, app, web), demand types (social, transaction, content, tools, games), and many sub‑domains.

NetEase Yanxuan, a new consumer brand, combines consumer and e‑commerce traits, requiring both toC transaction features and a supporting toB product matrix. While toB needs are clearer, complex systems can hide design pitfalls.

Product Design Process

The product design lifecycle consists of four iterative stages: product definition, product design, product development, and product operation.

Product Definition : Clarify user, scenario, and value.

Product Design : Break down user tasks and paths, then define architecture, features, content, and interaction.

Product Development : Implement and validate the design.

Product Operation : Post‑launch marketing, promotion, and feedback loops.

The design phase is crucial; its quality determines the product’s future direction, and all team members can heavily influence it.

Design Principles for B2B Products

1. Define clear system boundaries and service ownership

Limited product matrices make boundaries obvious, but complex business domains create overlapping responsibilities, leading to duplicated development and higher maintenance costs. Example: the “binding warehouse” relationship originally scoped to procurement later spread across multiple systems, causing inconsistent definitions and redundant storage.

2. Guard system interaction order when interfaces proliferate

Early stages often prioritize “just work” over design. As scale grows, isolated issues amplify, requiring universal rules to regulate inter‑system calls and tiered controls for violations. Example: inventory systems handling order status changes can encounter “accidents” without standardized call protocols, especially under reverse orders, after‑sales, or multi‑channel sales.

3. Abstract functionality into reusable object‑oriented rules

Simply digitizing a process is insufficient; abstracting common functions into a rule engine yields extensible capabilities. Example: during Wuhan lockdown, the system needed to block non‑essential orders. By abstracting “order blocking” into pre‑conditions, a rule engine, and decision actions, the same mechanism can serve various scenarios like carrier failures or emergency recalls.

Process abstraction = pre‑conditions + rule engine + decision actions

Conclusion

Beyond the three principles discussed, many other guidelines apply across B2B and product domains. Continuous reflection on underlying logic and methodology helps distill repeatable solutions.

Methodology emerges from understanding “底层逻辑” (underlying logic); mastering it enables adaptation to new changes.