The Product-Minded Engineer

Chapter 9. Product Architecture

In software, we rarely have meaningful requirements. Even if we do, the only measure of success that matters is whether our solution solves the customer’s shifting idea of what their problem is.

Jeff Atwood

Functional requirements are the set of goals for the affordances of our product that do what users want. Chapter 8 was all about fulfilling functional requirements, though we didn’t call them that at the time.

If that’s all we think about, we end up with the software equivalent of a Potemkin village—a nice interface that doesn’t work. So when we think about Nonfunctional requirements (NFRs), we consider key attributes that engineers design for, including cost, scalability, latency, throughput, data consistency, elasticity, and availability. And don’t forget privacy and security, though those are not covered here.

NFRs are a means to an end rather than enabling user goals in and of themselves, and sometimes represent things users only notice when they’re not working.

I love this topic because it’s the most engineeringly subject in the book, and yet it still benefits from product thinking. Designing a system architecture for these factors is a pure synthesis of user-centric and system-centric thinking, and it’s also the area that Product Managers and other roles are least likely to be able to help design.

This synthesis is sometimes dubbed product architecture—system design in the context of users and business constraints. I like the term because ...