Our First Product Architecture
Connecting Problems, Business Goals, Research, & More
Building products is tough. The questions seem endless, and every time someone new gets involved they bring a unique perspective, a new set of assumptions, and another style of working. While a diversity of skills and varied perspectives can seriously strengthen a team, there are certain things that any product team needs to agree on.
- The problem(s) we’re solving
- What a successful outcome would look like
- The business goals we’re trying to impact
When each member of a team has a different idea of what problem the team is collectively solving, what success looks like, or if they are unable to connect what they’re doing with what the business is trying to do, the team is bound to struggle. Good collaboration requires mutual clarity on these important points.
Our Situation
We were several months into building the next version of our flagship product. The team was beginning to gel and various features were taking shape, but there were some major problems.
Even amongst the team, we didn’t have a common understanding of how our product hung together, what problems it was supposed to solve, what the key workflows were, and where those workflows started and stopped. Our backlog was flat and didn’t provide us with the “big picture,” which hindered our planning, our active work, and made eventual gaps in our product’s experience inevitable. None of us could easily articulate how the functionality we were building related to the business’ goals. When an interesting idea was presented it was difficult to know whether it really fit within our product and, if so, where it fit. Design decisions were being made, then forgotten, resulting in a lot of churn.
This quote from Chris Dannen summarizes our situation pretty well.
As a new product or service comes to fruition, ideas, people, and transactions proliferate quickly, which means you need more people to pitch in and help. The more individuals get involved, the easier it is for them to individually lose sight of the whole innovation effort.
An inability to see the big picture seemed to be our root problem and it was gradually spiraling into other problems.
From the very beginning of the project, our director had been asking for an “outline” of the product in terms of the problems it would solve, and how it would solve them. We all needed this perspective. The question was how could we describe our product this way?
Our Solution
Ironically, with as many methods as we have for mapping out user flows, technical architecture, and visualizing business metrics, I’ve run across very few methods to visualize an actual product in terms of its basic structure and functionality.
We have a maxim around here — “Visualization is the key to success.” In other words, the process of expressing an idea visually takes it from a mere idea to a more concrete concept; it forces us to clarify our thinking and really probe an idea’s merit.
Visualization is the key to success.
I knew we needed to visualize our product, and I knew that a feature list or prototype wouldn’t suffice. We needed something different.
The Product Architecture
Paul Adams introduced me to the concept of product architecture in his popular article, “The Dribbblisation of Design.”
After the mission and vision is the product architecture. Not the technical architecture, rather the components of your product and how they relate to one another. The system….
A product architecture is not an information architecture. It is not a set of pages that link to one another, or something that shows modals and describes what buttons do. A prototype will always serve this purpose better. It is a level deeper than that. It is the structure. The building blocks. It shows the objects in the system, and the relationships between them.
This was exactly what we needed. The concept made perfect sense to me and I was really excited to see how other product teams were doing this.
I found almost zero examples.
Out of nearly 7 million results in Google, the first pages were full of technical papers, dictionary definitions, and companies offering architectural services. Great…
Starting From Scratch
As Stephen Covey says, “Begin with the end in mind.” I didn’t know how to visualize our product, but I knew my desired outcome so I started with a list of what I wanted to achieve.
- Everyone knows, and can explain, how their work fits into the whole
- The organization has a shared understanding of how the product supports business, user, and technical goals
- Designs are produced that account for entire workflows (instead of loose components and isolated tasks)
- It’s clear which ideas fit the architecture and which don’t (so we can better decide what to do with them)
- Design decisions are recorded in the context of the product architecture
- It’s evident which parts of the product are done and which aren’t
To The Drawing Board
Now that I knew what problems I was trying to solve and what my desired outcome was, it was time to do what I always do and get some ideas on paper. Drawing inspiration from Ryan Singer, Jeff Patton, Jeff Gothelf, and Indi Young, I sketched a variety of concepts, reviewed them with our product manager, and eventually landed on a sort of story map (with some differences).
Adding A Second Layer
Paul’s article shows a few examples of how a product architecture can be visualized, but it pretty much stops there. I wanted our team to be able to drill down into each area of the product and get more details, e.g. see what problem we’re trying to solve, or the research we used to inform our design. This visualization was just the first layer, a “visual index,” if you will.
I ended up building the whole thing in Confluence using their Gliffy integration, so it was relatively easy to create a hierarchy of pages that mirrored the hierarchy of the visualization, with each node linking to its corresponding page.
Next, the hard part — making those pages meaningful.
Time To Write
I decided that each page needed the following:
- A problem statement
- A description of our desired outcome
- A list of relevant business goals, and how each area of the product relates to those goals
- An area to record design decisions and attach sketches
- A place to link to relevant user research
At first we were hesitant to go back and write up problem statements and describe outcomes for things we had already built. It felt a lot like the typical design process Jeff Gothelf describes in his book, Lean UX.
Too often… our design process starts when someone has a feature idea, and we end up working backward to try to justify the feature.
We decided that, even if we hadn’t been clear about problems and outcomes up until this point and had built things without that context, it was worthwhile to start working this way now. Since then, we’ve made sure to do this work ahead of active development.
Show What’s Done
Our team’s product manager liked the structure and rigor that the product architecture brought to our design process, but he wanted it to also show how much of the work was complete.
How It’s Working Today
All things considered, our product architecture has been a glowing success. We reference our problem statements when preparing for our biweekly acceptance meetings, and they’re a part of the presentation we make to the organization after each sprint. During our sprints we go here to log our design decisions, concepts and reference them during weekly design reviews. Our team’s product manager uses the product architecture as a reference for roadmap planning, and other teams have used it as a way to get familiar with the structure of our product.
Our UX Architect had this to say:
Our product architecture is a new experiment for us that has been remarkably effective in correlating our product stories to the users’ journey. I don’t know how much the leadership is looking at it, but they should be often. We refer to it constantly; it’s instrumental in justifying our course and defending our decisions.
It’s been a 5 month process to reach this point. There is plenty left to do, but our team is benefiting a lot from having a shared perspective on the problems we’re trying to solve and this has resulted in a new level of collaboration and teamwork as we tackle some really tough challenges.
