Listen Now

Listen to this podcast on your favorite platform Spotify, Apple, Google, or Simplecast.

Episode Summary

Though we might want to believe that the product brief can be the one document that will tell us exactly what to build, the reality can be quite different. David and Mary Sherwin explain how the product brief can be a tool for alignment and consensus about what you’re going to build and what success looks like if you get it right. From their experience consulting and coaching product and service design teams, large and small, they’ve found that the most successful teams collaborate to make sure everyone is being honest about their assumptions.

Episode Notes

David and Mary Sherwin from Ask the Sherwins explain how the product brief can be a tool for alignment and consensus about what you’re going to build, what success looks like if you get it right, and how we can improve this stage in the design lifecycle.

• Ask the Sherwins
• Ask the Sherwins on Twitter
• David on Twitter
• David on LinkedIn
• Mary on Twitter
• Mary on LinkedIn
• Creative Workshop
• Turning People into Teams

By Design is a show about the process of designing exceptional digital experiences. In each episode, our host, Josh Brewer, dives deep into a specific stage of the design lifecycle with an industry leader. Our hope is that hearing their insight can help us shape a better future for design.

If you’re interested in improving the design process at your organization, see how Abstract can help.

Transcript

Josh: Welcome to By Design a show about the process of designing exceptional digital experiences. I'm your host Josh Brewer. And in this series, we will look at the different stages in the lifecycle of designing digital products. Each week. We'll hear from experts with an intimate understanding of what particular stage, what has, and hasn't worked for them. And how we might all apply these insights in order to shape a better future for design.

One of the more critical and sometimes contentious steps in the design process is the product brief. The product brief can be a tool for alignment and consensus about what you're going to build and what success looks like if you get it right. It can be a record of your initial assumptions and hypothesis, what you intend to learn and validate before you formalize an initiative.

And even though we might want to believe that the brief can be this one document that will tell us exactly what to build, the reality is quite different and I've seen everything from no brief at all, which happens a lot in smaller startup environments too. If there isn't a customer problem identified.

Then it's just marching orders, which tends to happen a lot at what John Maeda calls end ups or large established businesses. So to say that David and Mary Sherwin know a few things about product briefs would be an understatement. They are the co-founders of Ask the Sherwin's a consulting and training firm that helps organizations develop capabilities they need. For better product design and stronger cross-functional teamwork. They've coached product and service design teams and trained organizations, large and small. Their experience has taught them that before it is anything else. The brief is a way of mitigating risk. They see the most successful teams collaborate to make sure the brief has all the right starting assumptions.And if they're honest about how priorities might change, then the product brief moves further away from being a pitch. I asked David and Mary to tell us about their backgrounds to get us started.

David: So, howdy I'm David Sherwin. I've been doing product and service design for about, Oh my gosh. Over 20 years. And, uh, about five years ago, Mary and I had stepped away from our jobs working in-house and consulting with design teams to do coaching and advising work for teams, really focused on how to improve product design process and help build teams that do new capabilities around product design. And we've also been doing a lot of training and helping developing training programs for teams. And it's been really focused on improving our cross-functional team collaboration.

Josh: That's awesome.

Mary: And I'm Mary Sherwin, the taller of the two Sherwin's. My background, as David said, is content strategy. And also I come from education. And I'm usually on the other side of the fence. So David is the capital D designer and I'm the capital P person who has to deal with designer. So we really have kind of two halves of the same coin with that. But since we're also teaching in the classroom, we have the ability to see where designers are really beginning within an academic context and where they end up from a professional context.

David: And I think it's worth noting that some folks in the design community know us through our books. So we wrote a Creative Workshop and, uh, our most recent book, which is focused on team collaboration, it's called Turning People into Teams. So some folks end up reading those books and then reaching out to us to have us work more closely with their teams.

Josh: And as someone who has had the privilege of working with, with you both, I can attest to your skill, your compassion, and your honest to God empathy for not only designers, but all the folks who are involved in the design process. And I know through conversations over the years, the, the passion that you both have for helping teams really figure out how to be the most effective that they can in service of the customer. And that's one of the reasons why I was so excited to talk to you both today. All right. Do you have a hobby or a practice or a passion outside of this?

Mary: Ooh, I have this one. I play video games. I am an avid avid gamer. And you know, for many years I sort of felt like I had to justify that I was really into video games and I would find all these ways to talk about video games and how they're so informative of the design process. And now I'm at the point in my life where I'm like, this is what I do it. Especially last year gaming got me through, it gave me clear purposes.

It gave me clear goals. I always knew what I was doing. It was always there when I needed it. And you know, it may be frivolous and shallow, but Hey, you know what, it's 2021 and I am still here. So, uh, but yeah, video games all the way.

Josh:  That's awesome. Having played a significant amount of Minecraft Dungeons with my son in the last year and not being a gamer, I actually really resonate with that.

[00:05:14] And, and, uh, I'm glad that you're proud of claiming that title at this point. How about you, David?

David: Uh, for me every day, if I just have to play a little music, I might be just a few minutes. But for me, it's kind of how I transitioned from focusing on work, to kind of processing what happened with the day what's going on in the world.

Definitely helped me get through 2020 and moving into 2021 feeling like that's something that's sort of like, okay, it's part of just the, like how you, how you work through what's happening.

Josh: That's awesome. Another creative outlet that is not necessarily coupled to design, but, uh, equally creative and challenging in its own right. So really fun to hear that from both of you. Thank you for sharing. You know, we're talking about the design lifecycle here on, on this podcast. And when I say product brief, I'm curious for the two of you, what immediately comes to mind.

David: Oh, there's so many cliches. I mean, it's really like the one it's like the one document that will tell us what to build. You know, it's like the thing where we figured it all out and like everything's laid out in perfect detail and it's kind of an illusion at this point. It's kind of like the thing where people are just like, I just want like the assumptions, we have highest confidence in. I want the data that tells me that this is the right thing.

We'll figure it all out and then we'll know exactly what to do. And as I think anyone who works in product development for a period of time, you know, that that's just not true.

Mary: I think for me, the brief sort of has this reputation of, it's almost like it's almost like the Ark of the Covenant and Raiders of the Lost Ark, right?

So like people think that if they look too closely at it, that it's going to melt their faces off. And I think it really sort of speaks to the way that the brief, instead of being, you know, a gate has sort of become a gatekeeper.

Josh: Right.

Mary: And, uh, everybody needs something different out of it.

David: Yeah, the reality I think we see is that at least inside organizations are talking about like, it's the gatekeeper and that like the cost of entry.

So every organization kind of has its own flavor and it has some kind of stuff that's in it that doesn't have a customer problem or any like evidence around what the customer problem is. It's really just marching orders.

Josh: And arguably marching orders based on somebody's opinion.

Mary: Yeah. And we already have those. Those are called JIRA tickets. I kid, I kid I kid, but no, I mean, JIRA, we learn, I mean like JIRA at all that we've worked with teams that have sort of been trying to revise how their briefs work. And given, given certain circumstances, there are some aspects of a company that really just want a brief to be like a ticket.

You know, it's like checkbox, checkbox, checkbox, and the brief is really the only place that you can hold experimentation. It's really the only place that you can hold these big unknowns and to sort of templatize that out. Oh, it's kind of, that's sad. You know, it's cutting off so much of the potential of your product.

Josh: Both of you, the answers are, are really triggering a handful of, uh, thoughts and questions for me. One of them is around the timing of where the brief arrives in the lifecycle of designing a product. I'm curious, does the brief start the process? Is it a summation of the early phase that then leads to another phase?

Where, where do you guys feel like is most effective and then where do you see it actually in practice, uh, landing in that lifecycle.

David: Oh, but this, we feel like this is the question that comes up with every company in every project ever. So I think I'd step back and frame it really openly and say, okay, If a company says, Hey, we need a brief and we don't know the audience well, and we don't quite know what problems to focus on.

The brief is probably going to be more based in research and sort of like finding a product to test.

Josh: Totally.

David: So the brief, the shape or the format of the brief is going to be really different than like, when we say like the product brief, which is like, we know the audience, we know the problems. We might not have a product yet. But we have some hypothesis, then the brief is going to have that type of shape and that's going to bound what goes in the brief and what types of activities the team is going to come up with.

Josh: Makes total sense. And I'm hearing that a brief can be most effective when it's framing the problems that you're looking to solve and then identifying any data, any information that you have that helps you form a conclusion, uh, or even potentially how you'll go about testing that hypothesis.

Mary: Yeah, I would, I would agree with that. I think though, the, the super secret to, you know, sort of an, A minus, like an, A, you know, brief is acknowledging the metrics you don't have, uh, figuring out what data you don't have yet. What's the missing part in the middle that says like, okay, the brief, before it is anything else is a way of mitigating risk.

Josh: Absolutely.

Mary: You know, just a team sitting down and coming up with what has to go in the brief. You already know that you're using those factors to make decisions. You've prioritized that this kind of audience data is important. That you know, this kind of journey is important or this type of return is important.

Because if you weren't prioritizing this inputs, you wouldn't need to be a, put them in the brief, but priorities are going to change. And if the brief is honest about how those priorities might change, that sort of moves a brief a little bit further away from being like a pitch. Hey, this is a cool idea. Let's try it too. We're not really sure what this space is. But we need to look without this automatic guarantee of a productization of whatever comes out of that brief. And I think that briefs are sort of missing that space.

David: Yeah. Designers and sometimes, uh, designers are on a track where the briefs that they need are relevant to that track. So if you're on a track where it's just like you're with a scrum team and your goal is to ship stuff with the team, you're going to have briefs that are focused around, like, here's the context, here's what we know about the problem. There's some data, what is success look like? Hey, we have a bunch of ideas.

What should we do with those ideas? If you're unlucky, it's just like, we have one idea and we know it's going to work, which generally doesn't work. Depending on where you've worked in the types of product priorities you've worked on, it can be really different. The process that you're going to go through and the stuff that you really need to be confident in what you're going to give to a team and be like, Hey, let's try this.

Josh: Thank you for sharing that. Both of you. There's something that really stands out to me in this moment. And Mary, I think you, you were alluding to a brief is not a living document. A brief is set in stone. And what I'm hearing, both of you reflect is the brief, depending on where you are in the process, what the, the requirements are, who the customer is, what the need of the business is, right.

Arguably that document needs to have the ability to breathe a little bit. It needs to too much like us as designers, uh, take in new information and be able to like change our opinion, change a decision based on new information. That's come forward. How often, if, if ever, have you seen teams? Work with a brief in that way.

David: So I would say last year we worked with a couple of teams that they viewed the product cycle is at the beginning. We have some ideas or things that could be in our backlog. We want to carry into a brief, the brief would get kind of built by the cross-functional team. They'd like all collaborate to make sure it had all the right starting assumptions.

They might do some research or look at data dashboards, talk to customers. And then from there, say like, these are the designs that we want to test. Let's keep using this format. If we say, this is what we think success should be. Let's use that same framework. When we share results with our stakeholders in the company.

Josh: That's amazing.

David: And then they take that and they like aggregate that knowledge and they put it in a place where everyone can see, like when we did this project, this is what we thought would happen. And this was the result. This is what we learned. And this is what we're going to do to change our prioritization of what's going to come next.

You know, those, I would say that's like a good or a mature set of best practices, but I feel like it took some time of saying first, like, what does it feel like to collaborate on the brief? Oh, wait to have a good briefing. You need good inputs, right? Let's go find that, figure out how to bring in his input.

So it was kind of like building those bits of the process over time. It's like, look, we said, we're going to do this thing. And this is what would happen. This is what really happened. These are the consequences or the unintended consequences. This is what we're doing to iterate on the feature. And it makes it really easy to discuss what you've learned and give the illuminated, all the stuff that happened while folks were away working on all their other things they needed to do.

Mary: I was very lucky early in my career. I, I worked on a product team where our PM actually would print out the brief and put it up in our workspace. So every time we were, you know, doing any kind of contribution and it was, it was irritating at first, it was just kind of like everything that we were doing, there was a print.

It was just like, print it out, put it on the board, print it out, put it on the board. And. Then I realized after a while that every stage, every time something was completed, every time something was put up on that board, you had to look at that brief. You had to make sure you were accomplishing what you had set out to do.

And that at any point, if the work that you were putting up was deviating from that brief, not only did you have something really tangible to look at, but you had something to point to when you talked about it to another person and somebody was like, why would you do that? Like, we're not writing brief anymore.

And I went, ah, like in the Zen moment, are we not always writing the brief, but that. You know, like you said that some people felt like this was the brief period it's done. And then other people were like, no, this is sort of this guiding light. And you know, sometimes we have to shift, we have to change positions to make sure that we're really delivering not only what was asked, but what's actually the best for our users.

And the brief might not really know the land that we have to explore. And so we just sort of need to touch base every so often, but yeah, we've encountered a lot of teams that sort of just memory hole, the brief, you know, it's like, have you checked the brief? Just go and check it.

David: Yeah. There's this saying in user research that a research plan, rarely survives contacts. With people that once you start talking with people, you immediately have to revise the plan, the guide, whatever, whatever activities you're going to do, because there's just things you didn't know until you started talking to people. And I think the same principle applies to when you put together a product brief, it's like it rarely survives contacts with both the team that's going to be working on it.

You know, if one person goes away and says, I figured it all out. You know, like everybody's going to contribute new assumptions and questions to improve it, but then once you get something in front of customers, your view of the problem and your view of like, what you think are the quote unquote solutions are really going to change.

And so we do encourage teams to do what Mary was describing and just be able to step back and be like, You know, like your view of the problem's going to change, the more that you learn about how you're trying to intervene. Um, another new best practice we've seen over the past few years that has been kind of critical to improve.

The writing of briefs has been to sketch out the actual user journey in terms of like the specific steps or going through, even if it's just like a flow chart with words, you don't have to show screens and then saying like, this is what we think is going on and what we think people are doing. And just looking at data and being like, is this, is this really happening?

Like really agreeing on the problems that exist in that journey and saying like, okay, so if we're going to do it, what are we adding to this? And are we making it easier or better or not? And even just doing that before you write the brief, completely changes everybody's perspective and it changes the hypothesis.

Cause the team might be like, Whoa, we thought we had to build the thing right here. But there's so many other things we could do to try to like move the needle. On this feature, or just try to like add something. It doesn't mean I don't even need to be a feature. It might be something really simple that helps us like solve for these problems.

And so we've seen teams achieve a lot more flexibility around doing that. And designers often bring that practice in because they're already doing it as part of the design process. They're just moving it from downstream after the brief, up to before the brief and sometimes in a workshop to just be like, this is what's really happening.

Cause usually the whole team doesn't have that picture in their heads until it's completely sketched out.

Josh: That's amazing. And I'm, I'm really, I'm really picking up on a couple of key themes in, in both of your responses that the more that the documentation and insights data and anything that you are in the process of generating and observing, if that's done in a way that is observable, uh, to others that's accessible and both allows you to hold yourself accountable, but also allows other people to participate, to come in to the process and understand how you're evolving. Um, that to me absolutely sounds like a best practice. And I think, um, not only with the brief, I mean, this is something that in design in general, I'd say in the last five plus years, it's become critical that more and more folks in the company are able to engage with and access this information because they bring very unique, um, and sometimes critical insights. Uh, but if there's no way to participate in that, if there's no place where you're able to engage with that, I think it makes it harder and harder. And I love this notion of the brief being uh, you know, your best assertion at that moment in time and incorporating almost as a basic principle of the brief that it will evolve as we evaluate constantly, as we're moving through here. There's a, there's a cadence that I'm hearing in, in, uh, both of your responses that I think becomes very healthy, not just for the design team, but I'd argue for the, the organization as a whole, as a result.

David: Yeah. So I think the words I'd use to describe what you're talking about is like, I'm always looking for what the threshold of proof is. And so last year we worked with a couple of startups and when you're a startup, the threshold of proof is usually around like, do people find value in this area? Are they going to use, are they going to pay for it?

[00:20:31] But when we work with companies that are huge and they have big products with millions of users, the threshold of proof to release something into the wild is really different than the way you do it. And the number of people that you would put the product into their hands to say they respond is different.

And so the brief might have a point of view about like what success looks like in terms of those thresholds of proof, where you might have to discover it. And so when you have stakeholders, like, ah, I don't want to give you a blank check to work on this. You have to be like, well, in the end, we're looking for this proof to get to this goal.

Absolutely. If we don't get this proof, we'll do something different. And if that's not in place a PM or a business leader might look at it and be like, Hmm. You know, like I'm looking for something where we can like get some early feedback.

Josh: Right.

David: I want some signal that was improve. And so I feel like knowing how to work with the team to factor that into your brief and have a point of view is really helpful.

Josh: That's awesome.

Mary: I also think that having, I mean, the brief can't the brief can't usurp, the timeline. And I think that's a really important aspect of the freedom that may or may not exist in the brief, which is that yes, we need people's opinions and we need people's inputs. And we need people to be able to say, like, I think we're going down the wrong path, but there is a time and a place for that. And we need to make sure that we're all in agreement about what that timeline is so that we don't have, you know, what you know, back in the day, which is you would be two days from delivering from the client and somebody would show up and be like, wait, what are we doing again? Like, no, no, like that time has passed.

So figuring out how the brief sort of handshakes with the rest of the design process, because if it does move into this more living document, we have to make revisions or it's reflecting our updated knowledge, we need to make sure that we're still working within the established timeline.

Josh: Right.

Mary: And that we are not, you know, sort of being like gotcha. At the end, by something that just breaks our process. And that is a really delicate balance. Yeah.

David: And the brief doesn't exist in a vacuum of metrics. Um, most of the companies we work with use objectives and key results, and then. In some of the, those cases they're cascaded down to like individual teams.

So the brief there's usually like two scenarios. We see one is like the brief sits within that framework. And when the team is trying to build and test something in, they have immediate feedback and it's part of OKR reviews with executive leaders and they start giving feedback and pressure and pace.

And so that's like one pattern that we see teams having to deal with as being like, what did you promise? And it's like a common mistake in this situations is saying like, we'll have it done by X date or like a quarter, rather than having a window or a timeframe in which they can go from, like, this is the point that we started to get feedback and we learn stuff so this is the point that we're going to make some key decisions about what we should or shouldn't do. We're going to keep it or rip it out. And so structuring it like that. It's very different from like the project mentality of a designer was just like, give me a project. We'll do the project I've done with the project.

I moved to the next project. Products and the ways of the briefs work in products that make it can sometimes create an illusion that you're doing a project. And so we, we, we see teams working against it. Now, the other situation is that you have all these OKRs, but the thing that you're working on with the product brief is just critical for the functioning of the product.

Like it's fixing bugs, it's uptime, it's adding stuff. That's just core to it being like a product that when users use it, they're just like, Oh good. There's support. Let's add support. People expect support. We get feedback on support. We can't tie it explicitly to an OKR, but the product needs it. And in those situations, you have to figure out how to prove its value.

And there might be a metric like reduced support calls. So with the teams having kind of negotiate that and be like, how are we going to move these big business metrics with the OKR, but then how are we going to keep improving the product so that it meets minimum user expectations? And so figuring that out, I think like really influences what's going to go in the brief and how it gets socialized.

Josh: I couldn't agree more. There's so many nuggets of wisdom in what you both just shared. So thank you first and foremost for sharing all of that. Uh, one of the things that I feel like as a question that's dying to be asked is who owns the brief? Who should own the brief do either of you have an opinion on that?

David: Most companies we work with the product manager owns the brief, however, based on how much experience product management team has with writing and socializing and maintaining those briefs.

There might be more people consulted or part of the process to create it, especially if it requires knowledge or expertise from other parts of the business. So like, I'll give you like a, a basic example. It's like we see teams or just, just like the brief is all about building backend services and there's a little bit of UX.

A lot of that brief might be from the engineering lead from the person who manages or builds the database from data science to know what needs to go into the brief. And the designer might have a point of view about how that impacts or is related to the user experience. So the PM might be orchestrating that.

So their, their role of ownership is just like, I'm the one that's pulling in all the right inputs and I'm going to help make sure we prioritize the things that are right from a PM perspective, the right criteria. If it's a design problem, like a problem in the product that's really oriented around design.

The designer might start the brief. If it's around engineering back services, it might be engineering lead who's initiating the brief, but in the end of the PM, because they're the business owner for the team, usually that's where it gets into that question of like owning the brief. It's like, they may not own the creation of the brief, but they're responsible for how it's used and they're accountable to the results that are set up by it.

Josh: And in your perspective, or experience that idea of the product manager as the synthesizer seems to be something I've experienced, I've spent some of the better product managers I've worked with in my career, having a really incredible ability to synthesize.

Multiple, both multiple points of view, multiple inputs. Uh, and my favorite product managers to work with are the ones who actively solicit input from vital, uh, stakeholders and constituents in, in building that who should be consulted. How broad does this get?

Mary: I don't know. There's always a question of like, Who should versus who actually wants, um, you know, it's just like who wants to close their eyes and who really wants to get their faces melted off?

Um, I think if. Gosh, I'm not really sure how to answer this one exactly. Because I think each product is a little different and I think each team is a little different, which I know is a very designer way to answer the question. Well, it depends. I, I think for, for me, I think having clarity on who owns the brief is the most important thing. And I think that if we put the brief to a roll, then we're, we're courting a different kind of disaster, you know, there's, you know, ownership versus responsibility. Like, you know, that's the, you know, the, the PM expression is that I have so much visibility as so much responsibility and absolutely no power.

And I kind of feel like assigning ownership of the brief may sort of court, more of those types of situations, where there is this disconnect between responsibility, control, power, advocacy agency. And I think that it has to be specific for each company what's right, not only for the product, but for the team.

And I wish that that were more of a thing because there's lots of companies that are like, Oh, this is how we do it, do it, how we do it, you know what we call the work to Google the wag phenomenon, but it really does need to be for you and your team.

Josh: In my experience, the, uh, investment and input of product design engineering research, and arguably if product is not fulfilling that business requirement role, then someone to step in on that and that group of people almost making a commitment to one another.

That we are doing this. And ultimately it's soliciting input and contribution from the right people and giving agency and accountability to those who actually are on the hook to deliver this thing. And so how much of that legacy baggage are we still dealing with? And is there maybe a different way to even think about approaching? This is, you know, is the brief the right thing, or have we just brought it along with us and didn't even stop to question whether or not it was really solving the problem it was hired for.

David: A possible future that we might be heading towards. Is one where at least I can save with a lot of the in-house work we've done. You've got a lot of data and a lot of feedback coming at you from a ton of different sources. You'd have looking at dashboards of how people are using the product that there's customer support. There's reading verbatims of people like responding to surveys and user research, their sales feedback.

There's this CEO chatting with customers informally. There's a gazillion things coming at you and you start to form some patterns when you look at that data. And then those patterns translate into things that get into the backlog. And then there's the brief. So maybe if you say like it's the brief, the right format, there might be other ways we see things being translated from those patterns, from the data into priorities that end up being focused on by teams. And if the goal is to speed up how fast teams can build and test stuff, but you know, like, you know, you don't wanna sit around designing all day long. You want to like design and ship stuff to get feedback. Maybe a future that could be coming is one in which we figure out how to jump from that pattern to test more efficiently and doing it in a way that doesn't complicate the user journey, because that's, the risk always is like, once you speed up making changes in the product, you don't start to see how they intersect each other and cause issues.

So there's, there's this like tension between the two where it's like, you need the brief or you need friction. But it's the brief, the right thing to create that friction. And maybe there's other ways to have that friction to make sure the decisions are measured.

Mary: For me, when I look at the brief, you know, David was talking about how the brief usually has a really good reflection of OKRs and it really has, you know, it tries to show some understanding of the metrics that are driving the company, but I'm not gonna lie as a disabled person, we don't have those metrics. We don't have audience numbers to command. We're a huge market share, but because products aren't being built for us, we don't have the numbers we don't show up. So it's really difficult to say like, Hey, let's look at our users that use, you know, assisted technology.

If you haven't been building the product for assistive technology, like you can't do a track record. If you haven't been on that track. And it's. Really hard to look at an established process that accidentally on purpose starts with this idea of the brief of let's sort of get everything on paper when those inputs just don't exist.

So not that I'm down on briefs, I'm really not, but I do think that moving forward, if we're not careful, we will templatize innovation for accessibility and for disabled users, we'll templatize it right out of our product because we're looking for numbers for groups of people who don't really yet show up in our products, unless they're specifically built for that population.

And the brief starts starts that, which is that you got to figure out what that space is in order to say, like, if we want to not just increase our user group, but if we want to serve our users better, How do, how do we bring, how do we bring that community in?

How do we bring in, you know, not just the disabled community, but any underrepresented community, like they're there. Oh, right now we don't have the tools to see them.

David: Yeah. And we're only seeing organizations that focus on web products. Trying to move the needle on this. Usually they have a social mission or like a cultural mission like when you think about like Mozilla or Automattic. So there's just so much opportunity in this area that Mary's describing. It just, it just doesn't, it falls under a different mandate, or it becomes like the five or 2% of capacity that the team has to kind of shoehorn it in at the end of the process. And  I would say there's millions of apps and products that are out there in the world, competing for people's attention and use.

And as more and more of us eventually in our lives will be part of this community of people that have, um, temporary or permanent disabilities. It's like it inevitably is gonna become our problem. On the other side is the customers and users of these things. So. Got to get ahead of it.

Josh: We absolutely do. And I've seen that my own definition of diversity has had to continue to expand whether it is physical or mental or some other construct that we're working with. There's, there's so many pieces to designing, uh, any service for any customer base, to your point, the larger the market, the more diverse that market is.

And so what I'm hearing in, in some of what you're saying is if the brief does not become an avenue by which you establish that from the beginning, you'll be lucky if somebody sneaks it in at the end. And I think whether it's accessibility or it is a broader sample of folks that you're working with from a research perspective, uh, whatever it is, if it's not built into this mechanism that we have, the brief, to drive this process. We will continue to, to perpetuate the same cycles and do the same things that we've been doing. The cool part about that is that on the flip side, I'm hearing you identify a specific part of this design lifecycle that is ripe for new inputs. More diverse perspectives, data. And the more that we can maybe collectively spend time on this, the richer our products can become the richer our explorations will be the process that we are working within. We have the ability to shape it each and every one of us have the ability to raise our hand and say, Hey, I read the brief it doesn't feel like we're addressing X or we haven't considered Y. Can somebody tell me why not? And there might be legitimate reasons why not, but until we feel like there's the ability to participate and to be able to raise these concerns, I think we kind of just end up on this hamster wheel and kind of we'll, we'll get the same, uh, outcomes and, and hopefully. We'll be able to shift that as we move forward. I'd love to wrap it up with one last question, which is, if you look into the future and look out five years, what's something and we'll constrain it to the brief that you hope to see happen, uh, in our maturation and our evolution as an industry.

David: Well, if you're talking about what's happening with product teams, The idea of a team coming together and like robustly debating their assumptions. I wouldn't say that every team we work with this is a comfortable behavior. It'd be great in five years, if that was something we were just like, this is as comfortable.

And as part of the work, as any other thing we do to build a product like the biases and towards just sort of like, what's our velocity, like how many story points can we translate into shippable product? But also like how many debates have we had about what we're doing, why we're doing it. And that has led to increased decision quality.

That's like the slang that they keep hearing. And it's just like, to me, quote, unquote, increased decision qualities that you have a bunch of people that have some good debate and they have some good criteria and they're not worried about trampling each other's feelings and they have a biased point of view towards a future that they want to create for way more people that could benefit from the products and services that we're shipping.

Josh: That's awesome. Thanks, David. How about you, Mary?

Mary: I want to see briefs for sunsetting that that's like my, that is my pie in the sky goal, which is that if you are discontinuing a feature, if you are taking away something in a suite, if you're ending something that there's a brief for that, that, that really, I mean, not just to say like, Oh my gosh, we're responsible for our decisions. And no, this is not, you know, like the tragedy that is, you know, being a 20 year user of Photoshop, like, but briefs that talk about sunsetting. I think this, this is. It's not just a, oh my gosh, look at the responsibility we hold.

But it's also like this great moment of celebration. Like look at all the things that we did with this particular feature. This is what we learned. This is what we accomplished. Why are we sunsetting this? How are we going to do it? What's the rollout for this? What's the impact on each member of the team?

You know, it's, it's not, let's just flip a switch and that's sort of my, like, You know that, that's my thing. I just, uh, briefs for sunsetting period done. There you go. Five-year plan.

Josh: I think you're, you're really, really right on with this. And in conclusion, I, I think I'd love to maybe try to draw out one little thing that I've observed in, in, in this conversation, which is the customer, the user, the person who's on the other end of the service, they are actually the center of not only the brief, but the product development process and for us to be successful. We as an industry, I think have an opportunity to continue to learn. How to center around their needs, the things that they are coming to us for. David and Mary thank you so much for spending some time with, with me today and with all of our listeners. And we look forward to more conversations like this in the future.

David: Thanks so much for having us. We really appreciate it.

Mary: Yes. Thanks for having us. Take care.

Thanks for listening to By Design and original podcast by abstract. This episode was produced by Alison Harshbarger and Olivia Rheingold. Join us next time. As we continue our journey through the life cycle of designing exceptional digital products, subscribe on Apple podcasts, Spotify, or wherever you listen to your favorite podcasts.

If you liked what you heard, please recommend us to a friend and rate and review on Apple podcast for more design content and information about what we're working on. Please visit abstract.com. I'm your host, Josh brewer. Be kind to yourself and take care of each other.