What product managers should know about software architecture

Software architecture lays out what goes where and how it’s all connected.

While software architecture is designed by systems architects and maintained by engineers, there are some arguments for product managers knowing the basics of software architecture.

Improved communication between product managers and engineers, better product road mapping, and useful insight into time and budget are some of the reasons why a product manager should know a bit about this subject.

Here is our team’s perspective on what product managers should know about software architecture.

Within a system, there are two types of product updates.

1. An update that changes the behavior of a function (on click:do this)
2. An update that changes the structure of the system (both elements and the relationships between them)

In the product world, time is always scarce. There’s never enough time to do everything you want to, so product managers typically push for the changes they care about. That means structural changes are unpopular since they don’t change external behavior.

In other words, if product managers can’t see the change, they don’t care about it as much.

However, software architecture is all about change. If engineers anticipate maintaining a program, there must be structural (nonvisible to product managers) changes. When these structural changes occur, they’re acting on a belief about how a system may change in the future.

Here’s a common analogy:

You want to install granite countertops (build a new feature into your application). Unfortunately, your existing cupboards are only rated for laminate, and can’t support the weight of the new granite.

In order to make granite countertops happen, you need to spend a month reinforcing the underlying structure.

You could have built granite-supporting countertops from the start, but that would waste money and time if you never put in granite.

Non-visible ≠ less valuable.

There is a range of architectural designs, with two limits on either side: monolithic and microservices.

A monolithic architecture is a single “stack,” where your front end, back end, and database share one server to suit all of the application needs.

With microservices, there are many servers (or serverless functions) that serve a particular purpose.
For example, let’s imagine we want to make a video streaming platform.

We will likely start with one server that will process logins and video streams. That means if there are too many people streaming video at once it could slow down the login workflow!

Since we don’t want users to have a slow login experience, we break our monolithic server into two dedicated services: one for processing video streams and one for everything else (logging in, liking, commenting, etc.). This divided structure is microservices.

There are drawbacks to monoliths and microservices, but you should be able to understand why your software architect selected one over another.

Think back to Conway’s law. It doesn’t make sense to have more microservices than teams maintaining them. For small teams, monoliths are much more beneficial.

When solving for speed and function, it’s helpful to understand these technical tradeoffs.

Ideally, when planning product updates and optimization initiatives, your architect should be involved.

Since they know the current and future state of the architecture, they can give you instant feedback on the feasibility, timeline, and budget of any update which can be a massive time-saver for product managers.