The Nuance of Better
What we’ve created isn’t good enough.The people on your team never really want to hear this. Yet it happens all the time when working on products of all shapes and sizes.
Over here, product management has some opinions about what problems your product should be solving, and how to best monetize what you’re shipping. Over there, engineering wants your products to work flawlessly on a functional level, no matter how they’ll be stressed by users. In that corner, the design team wants every flow and detail to be clean and simple, while also navigating the organization’s design systems. Oh, and since you’ve already shipped an early version as an experiment, some customers are sending fiery messages directly to your CEO about reallyneeds to happen.
After spending the past two years coaching and training in-house product teams with my partner Mary, what I’ve realized is this: If you want better design work from your team, it requires a regular examination of what better means and what needs to be better. There are thousands of team decisions that contribute to a good product, thousands more for a great one. Most teams struggle with the nuanced decisions around what makes a quality product, because they lack the vocabulary.
Every function of your organization has their own point of view about what quality looks like. But it’s rare that everyone gets a chance to share these perspectives, and align on a shared definition. As a result, we hear things like this: What we shipped isn’t good enough… We’ll know it’s right when we see it… This doesn’t hold a candle to the competitio Talk like this may be meant to drive a team, but the lack of specificity isn’t a motivator; it just allows more space for excuses. Determining and maintaining shared quality standards as a team is the best way to prevent ambiguity from swallowing everyone’s best efforts.
The standards that work are those that design holds jointly with their product partners, and that can evolve over time. We’ve found that the best way to help teams create these types of standards is through shared rituals. When we say ‘ritual’, we’re talking about a team moving through a series of behaviors in a specific order. Teams create rituals for two reasons: to support the behaviors they want to see from each other, and to respond to the needs of their organization. Over time, rituals can become routine, and core to how teams behave and respond as part of workplace culture.
The following ritual will help your team define what quality looks like for your products. We recommend using this activity with teams that will be working together for longer periods of time, and it’s helpful to to revisit it when new people join your team.
Ritual: What Does Quality Look Like for Our Team?
To prepare for this ritual, have a stack of index cards or sticky notes, as well as a whiteboard or a large sheet of paper on hand. Although this ritual works best with physical notes or paper, a remote team can use a shared document to achieve similar results. Set aside at least an hour and a half for this ritual, so your team isn’t rushed.
Hand out sticky notes or index cards to your team members. Have them individually write down three words that describe what they think quality should look like for their products. Some of the words that we see most frequently are:
If team members ask for formal definitions of the words, let them know that this activity is about how these words are defined by them individually, not by others on the team. Each of us has a different picture in our heads of what these words mean, and what our products look like when those qualities are present.
Ask each person on your team to share their quality words and explain why they chose them.
As a team, each person votes for three words that represent what quality looks like for your product. The entire team has to agree on those three words. If you’re facilitating this conversation, pay attention to the trade-offs the team makes as they narrow in on their chosen words. We don’t always agree on what these words mean, especially when the industry leans so heavily on certain companies and products as object examples. Talk about that, and write down what you discover.
Ask each person to take at least ten minutes to write down specific attributes they would want to see in their products, directly associated with the three words they agreed on. Product attributes are tangible examples that the team can reference as they make decisions about their product.
Make sure each of these attributes is written on an individual sticky note. Each attribute must be associated with a quality word. Use the following questions as prompts:
We say that our products are <quality word>. What specifically makes them that way?
This question helps team members identify what tangible attributes exist in their current product that meet the quality bar. Don’t overlook the basics here, as they are things that the team will need to preserve moving forward. Simple onboarding? Lightning-fast on mobile? Capture these details.
If we want our products to be more <quality word>, what do we need to see?
This is about what attributes team members could add or change to improve quality. They should be specific enough that team members can say definitively whether they did or didn’t put them into practice. For example: “Product users will be able to do their work faster in our app” sounds good, but it isn’t specific enough, because “faster” is relative. Instead, try: “Product users complete critical tasks 10% faster than our current baseline.”
At first, this specificity may feel overly prescriptive or limiting. Stick with it. Think of these attributes like building codes in construction. A building can have a thousand different features and functions, but the structure underneath needs clear and defined parameters to ensure that its systems work together and that its occupants are safe.
Set up the following diagram in a location that all of your team members can see. One at a time, each person shares one of the attributes they’ve identified. Place that attribute under the appropriate quality word in the diagram, considering whether the attribute is something that is yes/no or dynamic.
If an attribute is yes/no, then your team can prove that it’s present in your product. Some of these attributes are obvious, such as loading content from your API at a minimum latency, or making sure that your interfaces have no typos. Others will be contextual to the type of product that you run and what’s important to your team.
If an attribute is dynamic, then it’s an aspect of your product that’s relative. These attributes are where teams make the majority of their quality tradeoffs. The designer might be frustrated that the text in the search feature isn’t exactly adhering to their visual design system, while the rest of the team is concerned that the search results aren’t perceived as relevant by users. Your team would need to define what adherence to design system and relevance to user means, and which they want to prioritize in their work.
After everyone’s attributes are placed on the diagram, prioritize as a group which attributes the entire team can support, and then which ones require the attention of specific team members. This is the time to associate metrics to these attributes—it’s likely your team already has some in mind. That said, take care not to add in dozens of new attributes for your team. It can take a substantial amount of effort to maintain what’s working well in your product, let alone make simple improvements. At this point, we’ve seen that six to eight key attributes end up being 80% of the effort for teams.
When you’re done with this ritual, make sure to place the output of the ritual where everyone can reference it.
Quality Isn’t Achieved, It’s Proven Over Time
Within an hour or two of dialogue, most product teams can find common ground and create basic working definitions to explain which quality words matter to them and why. But from there, it can be hard for team members to be specific about what tangible attributes their products should actually demonstrate. And the difficulty increases when considering how quality evolves over time. Use this ritual to create a shared perspective as a team on what quality looks like for your product, and how you’ll prove it over time for your customers and your organization.
Get more team rituals like these in Turning People into Teams: Rituals and Routines That Redesign How We Work, available from Berrett-Koehler Press.
David Sherwin is a Fellow at frog, co-founder of Ask The Sherwins, LLC and co-author with Mary Sherwin of Turning People into Teams: Rituals and Routines That Redesign How We Work (Berrett Koehler, 2018).
We respect your privacy
We use Cookies to improve your experience on our website. They help us to improve site performance, present you relevant advertising and enable you to share content in social media. You may accept all Cookies, or choose to manage them individually. You can change your settings at any time by clicking Cookie Settings available in the footer of every page. For more information related to the Cookies, please visit our Cookie Policy.
Our Studios
