The Root and Soul of Product Design: Why Business is the Only Answer

Original

In the world of product management, it's easy to get lost in the craft. We obsess over the perfect interaction, the seamless user experience, the cleverness of a new feature. We become skilled artisans, polishing our work day in and day out. But there is a simple, fundamental question we must constantly ask ourselves: Why are we building this in the first place?

Imagine you’re an architect tasked with designing a building. Would you start drawing blueprints and ordering materials without consulting the client, without looking at the geological survey, without considering the city’s zoning laws? Of course not. The building’s purpose (is it a home, a shopping mall, or a factory?), its budget, and the potential for future expansion—these are the foundational elements that dictate its structure, materials, and style.

In this analogy, the "business" is the client who brings us the requirements, as well as the "land" and "city plan" upon which we must build. The "product" we design is the "building" that will ultimately be constructed. The building's foundation must be firmly anchored in the land, and its blueprints must precisely serve the client's intent.

This brings me to the core idea I want to explore with you today, an unbreakable truth in the field of product design: Business architecture dictates product architecture, and business direction steers product direction. Without this root and soul, even the most exquisitely designed product is like a river without a source or a tree without roots. It will inevitably become an abandoned, derelict structure that serves no one.

I. The Foundation and the Blueprint: Business Architecture as the One True North

Many product managers, especially early in their careers, make the mistake of treating "requirements" and "the business" as one and the same. The business department says, "I need feature A," and we go off to map out the user flow for feature A. Then they say, "I want button B," and we start designing the interaction for button B. When we work this way, we are, at best, "requirement translators," not true "product architects."

To become an architect, the first thing you must learn to read isn't a list of scattered requirements, but the complete master blueprint: the business architecture.

So, what is business architecture?

Put simply, business architecture is the instruction manual for how a company operates and creates value. It encompasses:

• Strategic Goals: Where is the company headed? Does it aim to be the lowest-cost provider in the industry or the leader in premium service?
• Organizational Structure: What are the different departments, what are their responsibilities, and how do they collaborate?
• Business Processes: To get something done (e.g., from receiving an order to a customer signing for delivery), what steps, people, and systems are involved?
• Core Capabilities: What is the company's secret sauce? Is it a powerful logistics network or a world-class data analytics team?

Product architecture, then, is the structure of the software system designed to support this entire operational model. It includes the division of functional modules, the flow of data, technology choices, and so on. The sole purpose of a product's architecture is to enable the business architecture to run more efficiently, more stably, and at a lower cost—and even to help it evolve.

Let's look at an example.

Imagine a traditional brick-and-mortar retail company, let's call it "Cornerstone Retail." Its business architecture is straightforward: the purchasing department buys goods, the stores sell them, and the finance department manages the money. Now, Cornerstone's strategic goal has changed. It wants to transform into a fully integrated online-and-offline "new retail" company.

This strategic shift means its entire business architecture must be rebuilt:

• New Business Processes: It needs an online store, order processing, warehouse picking, and logistics delivery.
• Organizational Changes: It may need to create new departments for e-commerce, logistics, and online customer service.
• Upgraded Core Capabilities: It must now develop skills in online customer acquisition, membership management, and targeted digital marketing.

As the product manager, what happens if you fail to grasp this new business blueprint?

You might think, "They just need an online shop." So you design a standalone e-commerce website. But after launch, problems erupt everywhere. Online order information can't sync with the inventory systems of the physical stores, leading to customers placing orders for out-of-stock items. The online and offline membership programs are separate systems, so points and coupons aren't interchangeable, creating a terrible customer experience. The finance team has to manually reconcile accounts between two different systems, leading to headaches and errors.

This "e-commerce website," though it may be feature-rich and beautifully designed, is a failed product. It is disconnected from the company's core business architecture. Instead of supporting the business, it has created more chaos and silos.

What is the right way to do it?

You should design an integrated "New Retail Product Matrix" based on the new business architecture. The product architecture of this matrix might look like this:

1. A Unified "Product Center": Manages all product information for both online and offline channels, ensuring prices and descriptions are consistent.
2. A Unified "Inventory Center": Syncs inventory across all stores and warehouses in real-time, enabling shared stock.
3. A Unified "Order Center": Processes all orders, whether they come from the website, a mobile app, or a physical store, in one central place.
4. A Unified "Member Center": Consolidates all customer data, allowing for a seamless loyalty program across all channels.

See? In this architecture, each module is like a precision-engineered building block, perfectly fitting together to support the company's grand "integrated retail" structure. This design wasn't imagined out of thin air; it was "translated" directly from the business architecture blueprint. The layers and collaborations of the business come first, followed by the modularization and interface design of the product.

So, before you even think about opening Figma or drawing a wireframe, lift your head up and make sure you completely understand the company's business architecture. That is the very ground upon which you build.

II. The Ruler and the Compass: Using Business Goals to Measure Your Design

Once we have a firm grasp of the overall business architecture, we move into the specifics of product design. Here, we face countless choices. How should the page be laid out? What should the user flow be? Is this feature truly necessary?

The answers to these questions are not determined by a product manager's personal taste or even by the feedback from a single user. The one and only standard for judging all design decisions should be the core business objective the product is meant to serve. The business objective is the ruler in your hand and the compass that shows you the way.

Let's take the "contract management system" example from the original article and dive deeper.

Imagine the legal and sales departments come to you, asking for a new contract management system. During the requirements meeting, they get into a heated debate over a core workflow: "Should the contract approval process start only *after* all terms have been negotiated offline and the final version is uploaded for a formal online sign-off? Or should the entire process, from the very first draft, happen online with multiple rounds of edits, comments, and approvals?"

As the PM, you might see the merit in both approaches. Option A is clean; the online system only contains final, executed documents. Option B is transparent; every change is tracked, providing a full audit trail. How do you decide?

This is the moment to pull out your "ruler"—the business objective. You need to ask yourself and the key stakeholders one critical question: "What is the single most important goal we need to achieve by implementing this system right now?"

Scenario 1: The Core Objective is "Accelerating Sales Cycles."

The company's sales team is frequently losing deals because the contract approval process is too slow. In this context, speed is everything. Every design detail should serve the need for "fast."

• Approval Workflow: Option B (fully online from the start) would be too cumbersome, as back-and-forth edits would drag out the timeline. Option A (offline negotiation, online final approval) is likely more efficient. You could enhance this by providing standard contract templates that sales can generate with one click, drastically shortening the prep time.
• Feature Focus: The product's killer features would be a deep integration with the CRM system—allowing contracts to be auto-populated with customer data—and a robust mobile approval function, so managers can sign off from anywhere.
• Design Principle: Simplicity and clarity. Minimize unnecessary fields and steps.

Scenario 2: The Core Objective is "Strengthening Corporate Risk Control."

The company has recently suffered significant losses due to contractual loopholes. Management and the legal team demand that risk be minimized at all costs. In this context, rigor and compliance are paramount.

• Approval Workflow: Option B (fully online from the start) now becomes the only logical choice. Every revision, every comment, and every version must be meticulously tracked in the system for future audits.
• Feature Focus: The core features would be strict version control, granular permission management (who can view, edit, and approve), and mandatory checks for key clauses. The system might even integrate AI to automatically flag potentially risky language.
• Design Principle: Rigor and traceability. Sacrificing some flexibility for absolute security.

As you can see, for the very same "contract management system," the core business objective leads to two vastly different products with different features, workflows, and design philosophies.

When you find yourself in a disagreement, whether internally or with business stakeholders, don't get trapped in a subjective debate of "I like A" versus "You like B." Put the business objective on the table and ask, "Which of these solutions gets us closer to our goal of 'sales efficiency' or 'risk control'?" When framed this way, the path forward often becomes clear. The business objective is the ultimate measure that brings rationality to every decision.

III. The Telescope and the Adjustable Wrench: Designing Today for the Business of Tomorrow

One of the most painful experiences for a product manager is to work tirelessly for months, finally launch a product, and present it to the business team, only to hear them say, "This isn't what we need anymore. Our process has changed."

This awkward reality of being "obsolete on arrival" stems from focusing only on the needs of "today" while forgetting that business is a living, breathing thing that constantly evolves. The time it takes us to gather requirements, design, develop, test, and deploy can be weeks or months. During that time, the market changes, customers change, and the company's strategy and processes may adjust accordingly.

A competent product design satisfies the needs of the present. An excellent product design not only satisfies the present but also has the flexibility and extensibility to embrace and support the business needs of the "future." You need a magnifying glass to see the details of today, but you also need a telescope to see where the business is headed.

How do we design for tomorrow? This isn't about predicting the future with perfect accuracy. It's about building "elasticity" into your product's architecture from day one. It’s like when you’re renovating a house, you install extra electrical outlets in the walls. You may not need them now, but you're prepared for when you buy new appliances later. In product design, this "pre-wiring" means building a flexible architecture with high cohesion and low coupling.

Specifically, here's how you can do it:

1. Modularization and Service-Oriented Architecture: Break down a complex system into independent, self-contained service modules. In our retail example, "Product," "Order," and "Member" were all separate services. If the business later decides to expand into "livestream shopping," you don't need to rebuild the entire system. You can simply develop a new "Livestreaming" module and have it communicate with the existing services.
2. Configuration over Hard-coding: For parts of the business that change frequently, don't lock the logic into the code. Make it configurable. A classic example is an approval workflow. Today, a contract might need three approvers. Tomorrow, based on the contract value, it might need five, or require a parallel review. If you design a "workflow engine," a business user can configure these rules themselves, like building with LEGOs, without needing to file a new development request every time.
3. Open APIs (Application Programming Interfaces): A modern business is not an island. Its systems need to communicate constantly. Designing clean, stable, and secure APIs from the start means your product has the built-in capability to connect with any future system, whether internal or external. This provides limitless potential for business expansion.

The key to using your "telescope" effectively is to maintain a constant dialogue with business leaders. Understand their vision for the next year, or even the next three. The questions you ask should evolve from "What do you need right now?" to "What changes do you see on the horizon?" and "If we build this, what will that enable you to do next?"

When you design for today with the future in mind, your product transforms from a rigid tool into a living partner that can grow and adapt right alongside the business.

Conclusion: The Leap from Craftsman to Co-Creator

Let's return to our original analogy. The growth of a product manager is a journey from being a "craftsman," who only cares if the bricks are laid straight, to becoming an "architect," who understands the client's vision and can plan the entire structure's function and future.

The most critical part of this transformation is shifting your focus from isolated features to the holistic business landscape. It's about elevating your purpose from "completing requirements" to "creating business value."

Always remember:

• Business architecture is your starting point and your foundation.
• Business objectives are your ruler and your compass.
• Business direction is your telescope and your guiding star.

When we truly see ourselves as partners to the business—when we discuss strategy, map out processes, and plan for the future together with our business colleagues—we cease to be passive order-takers. We become active co-creators of value. Every feature we design and every sprint we run will no longer be just lines of code, but strong, reliable gears that power the massive engine of the business.

To all of us on this product journey, let this be our shared commitment. Let's look up at the sky while keeping our feet firmly on the ground, and use our wisdom and hard work to build products that truly solve problems and create lasting value.