Image for post
Image for post

Our First Product Architecture

Connecting Problems, Business Goals, Research, & More

Ben Berkompas
Apr 30, 2016 · 7 min read

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.

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.”

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).

Image for post
Image for post
The “map” visualization helps us think in terms of contingencies and where everything fits, but I knew right away it wouldn’t be maintainable and it wouldn’t scale as we moved forward
Image for post
Image for post
This diagram helped me establish a bit more hierarchy with Activities, Workflows, and Tasks but it wasn’t very maintainable
Image for post
Image for post
We ended up with this diagram. It’s very similar to a story map but is skewed toward the functionality itself, whereas a true story map would give more weight to the users’ intentions and goals. Those intentions and goals are captured in the underlying pages, not so much in the diagram itself.

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.

Image for post
Image for post

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
Image for post
Image for post
Having a consistent structure has really helped us capture the right information

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.

Image for post
Image for post
Color-coding was the obvious answer for showing what’s done. Gray means it’s not on the roadmap, yellow means we’ve written the problem and outcome statements, and green means the feature has been developed (in its first iteration).

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.

Home Depot QuoteCenter

Quoting. Simplified.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store