The Need for Product Architecture
In this article, we're going to discuss what Product Architecture is, why you need it, and how to go about it at a high level.
The term Architecture implies requirements on design and structure. We are not talking about Software Architecture or Building Architecture here though.
What Product Architecture is Not
To build anything new, you must have a design. This is easy to grasp for physical objects. To build a house, you must have a design. There are many different designs to build a house, but not all are equal.
Design is generally viewed as visual design, such as the user interface in the case of software. I have used the term Product Architecture to avoid confusion. I do not wish to confuse the interface or experience design with the current topic. Interface and experience design is an element of the Product Process, but it is not the core.
Product Architecture is not engineering either. Engineering's purpose is to deliver a functioning product that meets the specified requirements.
What Product Architecture Is
Product Architecture is the design process that builds the best product. What is the best product?
The best product maximizes the value realized by a business and it's customers.
There are many different ways you could achieve the best product. There is only one best product. As with many mathemetical formulae, the best product is often indeterminate. We cannot know for sure we've acheived the best product.
We have to start with what we do know. Products are created by businesses and thus limited by business capabilities to produce them. Products realize value by meeting an unmet need at a lower cost than the price someone will pay. Products must solve at least one customer problem better than other solutions available on the market.
Product Architecture uses standard inputs to specify the best product output. Using what we know, we can define the inputs as:
- The market needs
- The market conditions
- The business objectives
- The business capabilities
The output of Product Architecture is the product solution design. This is not referring to the physical or interface design, though those may be parts of the solution.
Product Management versus Architecture
You might be thinking, wait, aren't you talking about Product Management? The short answer is no.
I often observe the Product Manager role presented in terms as necessary skills. I hear it described as a blend of Business, Technology, and UX / Design. I also have observed the use of terms such as "Product CEO" or "Product Owner." If you ask around, you'll likely get many different answers.
Here are some useful references on Product Management:
- Quora Question: What is Product Management?
- Quora Question: How can I become an effective Product Manager?
- Aha.io's Blog: The Future of Product Management
I find the definitions of Product Management I have encountered to be unsatisfying. The reason being is that they tend to lump together many different roles under the same title. They do not distill the true ingredients even if they identify many of the skills and responsibilities involved.
Management as a term implies a process. Management does not imply design. Yet design and development is a necessary part of Product Management. Product Management is somewhat of a catch-all term.
I'm distilling design and defining it as Product Architecture as a subset of Product Management function.
Without Product Architecture
You might be thinking without Product Architecture, things are working. Products are designed, built, and sold every day. Why should we change?
The simplest visual illustration I can think of is shown here.
Is everything connected? Yes.
Does everything work? Yes.
Did it evolve naturally? Yes.
Does it have good design? No.
The lack of design in Product Architecture does not manifest itself physically like in the network cable nightmare because it is abstract. You can still design, build, and sell products every day.
The symptoms are visible in other aspects. Feature bloat. Lack of product market fit. Poor product ecosystems. Failure to innovate.
Good Product Architecture helps to guard against these problems. Like a network cable, good Product Architecture connects the endpoints of Product functionality and market need in a systematic fashion. When something is out of place, it's much easier to spot. When a new connection is to be made, there is less effort.
The Process of Product Architecture
In every industry, there are design processes. Design processes vary, though they generally follow three phases.
(1) Problem definition,
(2) problem analysis,
(3) and solution design.
Engineering disciplines have many well-defined, generally accepted design processes. Physical design and manufacturing have very mature design processes. Software design, though it is still evolving, has many mature design processes. The problems solved in the mature design process are often very complex.
Engineering disciplines work with quantifiable inputs and outputs in the design process. Product Architecture is different because the inputs are not generally quantifiable. The 4 inputs outlined above are abstract and often complex. The inputs change rapidly as markets evolve, technology evolves, and businesses themselves evolve.
Abstract and complex inputs make objective analysis difficult. To achieve solution design, the approach must have a way to solve the problem in spite of the inputs.
Product Architecture deals with abstract, non-constant inputs when solving for market problems. To solve abstract problems, you must have an abstract approach.
When invented, semiconductors provided a new way to solve numeric problems with electrons. Semiconductors quickly evolved to the point solving vast quantities of numeric problems. A new approach was needed to harness the power of the microchip. Abstraction became the solution and software was born.
[Abstraction] works by establishing a level of complexity on which a person interacts with the system, suppressing the more complex details below the current level. The programmer works with an idealized interface (usually well defined) and can add additional levels of functionality that would otherwise be too complex to handle.
Abstraction is the key to the Product Architecture. Abstraction in Product Architecture translates abstract inputs and then renders a measurable output. Abstraction suppresses complexity so that Product Architects can focus on levels of functionality.
Abstraction layers provide a path for designing a solution. Layers normalize the inputs to realize a stable output in spite of complex and abstract variables.
I call the use of Abstraction layers in the Product Architecture context the Product Framework. The full treatise on the Product Framework I am saving for another post.