Put the business case around the design process.
Learn how to effectively communicate operational and organizational impact through design leadership, become fluent in the language of business metrics, and identify the intersection of business value and user need.
Hear from Devbridge Director of Product Design, Chris Wilkinson.
Watch the talk:
Transcript:
Good morning, everyone. Good afternoon, good evening, depending on where you might be. Welcome, thank you for joining us this morning, kicking off 2021's Full Stack Friday series. My name is Chris Wilkinson. I'm the Director of Product Design at Devbridge, and I'm very excited to be sharing today's session with you, design is a business job. And for this, I really want to start with the question of, why do people become designers? And I think it's important especially in the Full Stack sense, this is a career and sort of a mindset that takes a very particular individual and really requires a unique perspective to want to really dive into this world head first. For me, I think there was a moment of just like, realization of the power of what design could be. And it was through the design of this gentlemen, this is a guy Dieter Rams, and you've recognized his sort of aesthetic and a lot of different ways, heavily influencing especially with things like, the Apple design aesthetic, but really he was one of the first champions of having a really strong design philosophy behind the work he did.
And I think that's because, he really understood what good design was. And so I remember reading for the first time what his principles on good design were and really what actually made design impactful. And this is something that's really sat with me personally. Now everybody is going to have sort of their own perspective and journey into design but for me, the core of this is really understanding that good design is something that makes things accessible to more people. And it really involves as little design as possible. And understands its impact overall, and do something that people are really able to enjoy using. But I think one of the common threads across everyone who becomes a designer, is everyone knew that they wanted to make a positive impact. Now, one of the things that has sort of been a weight on the design industry for a long time, is that designers have been trained for so long to have empathy for people and to understand people's motivations.
And really that training and that focus has only really been for half of the equation. Designers have been trained and told to focus on how to interact and how to be around the people that are going to use the product, but they really haven't received the same kind of time, training, attention, and focus, on what it means to be a designer within a business context. And so today I going to break down that with you and share some ways that designers can be better partners with the business and realize the business aspect of a career in design. Now, one of the common threads that have come up in the design industry in the last probably 10 years has been this discussion about getting a seat at the table. And there have been numerous attempts by design to kind of frame itself as worthy of a seat at this table.
And even to the point where designers decided that they had to totally change in lie about who they were, just to give the impression that they needed to be at the table and that the table should be ready for them. I really don't think there's a lot of value that. I mean, just like Ferris Bueller here, he's great just the way he is. He doesn't need to be Abe Froman, the Sausage King of Chicago. And I think that created this generation of designers and design leaders who are really trying to forge a path. Designers look closer to this. They were like Bear Grylls going through the wilderness with a machete. And this whole generation of design leaders that had no path before them. And so what made the current generation of design leadership successful, was basically becoming these machete-wielders in the jungle, trying to forge a path for design.
Well, we reached a point with design maturity in organizations where it really needs to set a foundation for itself to develop and build the next generation of design leadership and design in the business. And so really, there's not a lot of value in being a bunch of machete-wielding table seekers. The value is in communicating clearly with the business and the rest of the stakeholders and how to actually communicate that value of the work that you do in a way that they can access and understand. So what do we know today about what makes us work? Well, we know that designers have a unique perspective, but really, you hear these things like unique perspective, design thinking and all these buzz words that try of value design, really design is about generating outcomes.
And so if your first thing to say what design is, you say design is empathy, design is understanding, design is being a design thinker. I want to try to challenge you to get a little bit of a new perspective today and look at things in a slightly different way than maybe you have in the past. If you're a designer, I want you to sort of look a little bit at how you've understood your profession and your place in it. And if you're someone who is a product manager or an engineer, or a business professional who works with designers, think of this as a way for you to raise your expectations of what to expect and what your design team is capable of.
That means there are some phrases that I think we need to remove from our vocabulary. So things like chasing a seat at the table, or making sure design has a voice, or trying to forge a path, let's assume that all of that is done. Let's also assume that not all of the tables are tables that we should be seeking out. There are some decision-making tables out there that really aren't that great. They're antiques of an old way of working and living. They are relics of an era where there wasn't equity for all people, there wasn't inclusiveness, and there wasn't accessibility in mind to a wider audience. And so I think design also has the ability to craft its own tables and create its own sort of destiny and future for how business is shaped going foward.
So if we assume then that we are in the room where it happens, now what? What do we need to do as a profession? And what do we need to do as a product community to be able to successfully build on the progress that's been made to date? This is the most important thing, and I got to emphasize this very strongly, we have to stop talking about there being a table. There's no magical table where, if you get a seat at it, suddenly designed value is realized. The key to getting design value realized does not create itself just by having a chair at a specific table. And I can't think of any other profession that talks about having an impact on the business in this way. So the first key piece to making this possible is making sure that design leadership is itself a function of the business, and design expectations for design teams are a function of the business.
And they're talked about in measurable ways instead of just aesthetics of a clean and usable user experience. You're talking about things in terms of metrics and KPIs and results that are generated. Now, you might be thinking, Chris, this is all great. But my organization is not set up in such a way where this is even close. And that's okay, you're not alone. InVision did a design maturity report about a year and a half ago where they went out and interviewed a handful of design organizations about 2,000 across varying sizes. And there's one continuous throughline throughout all those conversations they had, which is that in 83% of design organizations, they weren't fully integrated with the business. So that means only 17% of organizations are really starting to turn the corner and build the next future and realize the future value that design can bring to the business.
So in this case where there's 83% of organizations that are still building and still trying to set up that foundation, what can we do? Today, I want to share with you a few of the things that we've done on the design team at Devbridge to accomplish this goal and things that we've seen work across our clients in different industries, as they looked to integrate design more fully into the business.
At Devbridge, we're a matrix organization. And so the way that that plays out is that we have a team of product managers, and a team of product designers and each of these groups of product managers and product designers actually don't report into their disciplines. They all report across squads, and each of these squads has leadership within it that supports it. They have a group product manager that supports the product managers, and they have a product design manager that supports the product designers.
Each of these portfolios of business or verticals within our company is supported by a managing director. And then there are practice leads, a director of product management and myself as director of product design that support the disciplines themselves. And so what this does is it sets up a dynamic where you have practice leadership that's really focused on the operational excellence of the discipline and the quality within that discipline and the value that discipline can bring, and then you have delivery leadership that is focused on making sure the objectives are set and that the goals are realized for an individual engagement. So you're actually separating out the concerns a little bit and you're saying, okay, how does each discipline make sure it's fully represented without having this push and pull between the two? But what that means for the individuals on each team as they have to be able to not only speak well about their practice, they also need to be able to speak well about delivery considerations and things that go into successfully building great products.
This same dynamic has carried through to our engineering organization as well, where each individual team is supported by a team lead, and that team is made up of a variety of engineering roles. Each of these roles then form our product team together, and these different groups will mix and match over time, spreading out context and knowledge across the different teams. So this also means it's really important for us to have a standard way of operating so that way, every time someone begins a new engagement, they know the basis of what to expect.
We're being very intentional about how we set up our teams and our engagements. So that way we can be intentional about the results that we create. And I think that intention is really important because the alternative is that you can just place a bunch of bets and just hope that it's going to turn out. You can put all of your money on a hard eight being rolled, and really hope that it's going to happen, but it might happen once in the course of an entire week, or maybe just once in the course of an entire month, and you're really counting on that moment to realize the value.
A more consistent and predictable way to do this is to set up a system where you're actually investing in learning and the team over time. And so the first way that you need to do that is realize that delivering value is the shared mission of all of leadership. To deliver any sort of value, that means that you have to realize that you're working in concert with every different discipline to create that outcome for whoever you're working with. Now, this might vary depending on the kind of team that you're. In some organizations, design might be part of a marketing department, where they're really treated as a service to the business and they're separate from product delivery.
Another way that we see organizations have organized where there's a product division and design is embedded as a part of that product organization. And an additional way that you sometimes see design within an organization is design is inside of the technology org and is its own bubble separate from product and product management. Regardless of how you're organized as an organization, how your org is structured, your collaborators remain the same, and the people that you need to collaborate well with remain the same. And so that is across design, quality assurance and test engineering, engineering teams, product teams, marketing, finance teams, and the list goes on. I was curious when I first started putting together this talk, and I mentioned this earlier, do other disciplines really spend any time talking about having a seat at the table?
And so what would it be like if all six of these disciplines, their main thread was, how do I get a seat at the table? How do I get to be represented? I need to have this focus. That's not really how it actually plays out. And I verified this, I went ahead and did a little bit of a search engine statistical analysis, which I know is not the most scientific way of understanding things, but still it was pretty stark. There was 2.7 million design results when I searched design plus seat at the table. Whereas there were only 460, about half a million posts about engineering having a seat at the table. And I think a lot of this is because these disciplines are a little bit more mature in their history of software development, and they've built the structure to support future generations continuing out the value. That's something that designers hasn't really done successfully so far.
And so how does this play out when you look at the other teams? Other teams, similarly, quality assurance, marketing, finance, not really a common conversation. Product does show up a little bit more, but when I looked at that a little bit further, most of those were just saying product design. So that product number is just a little bit inflated. So design has been having this conversation for 10 years plus, and it's still having it. Is it the right conversation to have? The answer is, it's time to move on. Instead, it's important for every role to focus on how they all collaborate and bring their unique perspectives to bear, when they work together as a team, where really building relationships successfully in a product team means empathizing and supporting with all business rules. And that empathy word, I mentioned that before, design doesn't have the market cornered on empathy. The marketing department cares about the customer. Engineers care about the customer. The product team cares about the customer.
So if design leads with its value prop being empathy, you're kind of not only selling yourself short, you're also cutting off a little bit your colleagues and your peers, who also care about what's creative. And so how do you instead become a more inclusive team? Well, the way to do that is not to show up, looking a little bit like this. And I think anybody who's been at a design team sees this and goes, yeah okay, I've rolled into the meeting feeling like this, ready to go. And I think there have been people who have been sitting in meeting rooms seeing a group of people roll into a meeting looking like this and they're usually equipped with all of these great things ready to roll. And if you're seeing these slides, and you're hearing, Led Zeppelin's immigrant song playing in the background and you're like, okay yes, I'm ready to go, Chris! This is what we need.
No, do not embody this. You do not need to be in a situation where you're coming in engines revving to get anything done. You have to make sure that you anchor yourself in a position where everyone is aligned and working together to get that result. When you journey together as a team, you're actually able to not only be a better designer because you're understanding the customer well, but also because you're understanding how your work product needs to be used by the rest of the team. It's not the job of a designer to create mock-ups. Yes, designers have to still build them as a part of their job. So make sure, repeat that for the designers in the crowd. You are not hired into your jobs to build mock-ups. Mock-ups are an artifact of the core of your role, which is to create an output, create an impact for your team that helps build working software and brings that software to market.
And there are many different facets that go into that. When you're thinking about how do you set up a design organization for success, there's three things to cover here. I think first you have to make sure that you prepare the team well. And once the team is prepared, you have to make sure that they're able to execute well in the delivery work that they do. Once those things are taken care of, then you can begin to have a conversation about how do you actually set yourselves up to build the design for outcomes.
It's really important that, as leaders within product organizations, that we prepare our teams with the tools that they need to deliver value in their work. And if you're not in a leadership role, this is the expectation that you should have for your leadership. They should be setting you up for success with the tools that you need to deliver value in the work that you do. And when I say the tools that you need to do your job well, I'm not talking about the ever-expanding buffet of design tools that are out there. I'm not talking about having a great kit of design accessories to do a "Design thinking workshops." These are important. And I'm also not talking about having a good webcam, although today, and this way of working, also very important. I'm talking about the skills that you need to execute in your job.
I was talking with one of my colleagues, Tim Kearney, about six months ago, and we were talking about how do we set up the teams for success? How do we set up product teams and design teams to work successfully together? And he made a really great point. We were talking about all the different skills that go into product management, product design, and one thing that stuck with me as well, there's all of these skills out there that these disciplines could focus on. What are the skills that they need to do their job here well? And so we work together to create a core list of skills that you need to drive this car well. What are the skills that people need to drive the car at Devbridge well? And so we rewrote the entire skills' framework for our product management and our product design teams to really reflect the tasks that they need to do well to do their jobs well.
There are so many other areas that you can possibly focus on. One of the things to really elevate design and product within a business is to make sure they're focusing on the hard skills that they need to succeed within the framework of that business. That means in some organizations, designers would really need to be great at research. Other sort of teams, they might have their own research department and so it's not as important. By understanding the skills that you need as an individual and as a leader, understanding the skills that your team needs, you can focus your time and energy on setting them up to be successful. And this wasn't something that we actually were able to just say we had a great conversation and we threw it up on the screen and told everybody, this is how it's going to be.
I think this is where it's really important for design to understand the value of socializing things and building consensus within a business. So we had several rounds of conversations to make this happen. The first step was the practice leads, got aligned and we all said, yes, this is the way things needed to be. We then brought in our HR team and we said, okay, here's what we're thinking. Are there any blind spots? What expertise can you bring to round this out? From there, we brought in the managing directors, those folks that own our delivery portfolios. And then finally we brought in the group product managers and their product design managers who run the teams, and said, okay, here is how we're going to approach scaling the team. When we built this consensus step-by-step we were able to not only better test out and measure and learn on what we had created, but also we were able to bring in perspectives that we didn't have ourselves when we were creating these documentations.
We had a couple of skills that got cut at varying stages and new ones that were added to get to our final state. I think this is where it's really valuable to not think that as a designer, you have to go behind a curtain and magically come out with a solution at the end. Instead, engage in a process of co-creation with your entire stakeholder group to get to where you need to be. The other piece of this that I think is really important is for designers to understand that the skills that you've learned in school and at design programs likely aren't going to apply fully in a business context. A business meeting does not run the same way as an art school critique. And so for us at Devbridge, the way that we're countering this is we've developed a program called, Sourcery for Product. And it's a six-week intensive program where we take new hires to the organization through all of the things they're going to need to drive this car well.
How do they execute this job well? I've seen a lot of job postings and things out there over the last several years for things like people that need seven years of Figma experience, when Figma is really only been out for five years. There's outsized expectations of what you need to bring new talent into an organization. I think for organizations to succeed in 2021 and beyond, they have to invest in an education curriculum for their team, to scale and home grow talent for the jobs that need to be done. You're not going to be able to magically go out and find a fully experienced person in your organization. So you do have to make that investment. The other benefit of making this investment is it also widens your talent pool to bring in people of various experiences and backgrounds, where they may not have a deep software bunch of experience, but they have related experiences that make them valuable to a software team. The more experiences and backgrounds that you can bring into your organization, the healthier and more resilient it's going to be.
When you invest in developing people, you're investing in their success. And I think one of the key things about that as well is, as a team, you can't expect this to be something that you just do and you set it and you forget it. For us, we built an entire ecosystem in learning and professional development. This means we have a core design toolkit. We use confluence of templates and assets that people can use to kick off delivery of any engagement. So any designer could go, pull out the information that they need, and have the tools at their disposal to kick off doing any type of design work.
That design toolkit is supported by company-wide Lunch & Learns where we share best practices, as well as practice-focused brown bags. Brown bags are something that I really encourage you to look at bringing to your own team and your own organization. And what these are is they're short, informal, 20, 30 minute over lunch conversations where you're really focusing in on a very specific and particular thing, like how does Flexbox work, and how is resizing represented in Figma? Or how do you successfully set up a user research cycle for a project? Or what are the best things that you can do to set up a heuristic analysis for success?
These kinds of smaller sessions, especially when they're led by the team and not by a team leadership, are ways to encourage that growth and that development over time. All of these things are supported at a longer-term level by having regular retrospectives, where you look on the past and determine what can be improved as well as future perspectives, where you look to the future and plan for, what does the team need to do to evolve and encounter the challenges that are coming?
We also do something called experience reports where every designer is asked to keep a journal of all the things that happened in major moments in a project, and then share those learnings out with the team. That mindfulness is really important for design to understand its role in relation to the business, and then be able to communicate out what was learned and elevate the team alongside. Large team trainings are also a very powerful way to sort of steer the entire ship and reset expectations for everyone about the quality and the standard they should be achieving in a particular element of your process or your delivery.
The other piece of this to keep in mind as we're developing people is, as leaders, we can't be everything to our teams. We can't solve every single problem that they're trying to address. And so the people need to have managers, mentors, and friends that carry them throughout their careers. That manager is obviously someone who is usually assigned, but that mentor, and everyone should have this person, is someone who is where you want to be in your career, or has gone on a similar journey. And those friends that you have along the way, in that professional sense, especially are those people who you can call up after a really weird day, and just kind of have that venting session that resets your energy, and clears your mind, and gives you that friendly gut check that only a friend can give. All of these things are important to support any ongoing learning effort.
This is why it's so important also that designers and product professionals take ownership of their own development and how they evolve over time. So once the team has prepared, the next piece that you have to do is successfully execute in the delivery work. This is the responsibility of everyone in a software team, deliver working a software. And really it's deliver a working software that creates a result. That means that all of the teams that work in product or engineering are able to track out their work and execute on it effectively. We leverage a dual-track approach where we have a backlog separate for product and engineering. Each of those backlogs are then tracked and managed and prioritized. By having a key focus on the outcomes that you're responsible for, you're able to tell a more comprehensive story on the impact that you're having with the business. We have backlogs that have both features and business hypotheses, and those backlogs are prioritized and broken into tasks that can be measured and evaluated.
And we do this because design has a velocity. It gets really important for design to learn from one of the beneficial practices that Agile engineering teams have deployed, which is measuring their work and communicating out how that work is progressing. If you're in a small design team of one or two people, especially it's important to have this velocity, because the conversation moves from whether or not you have enough time to design workflows to prioritizing your work of research versus design versus validation, because of the bandwidth that you have and also because of your historical progress. When you do this, you're able to prioritize all the work amongst each other as a team, estimate the relative complexity, and then provide predictable progress to the business. See, one of the things that the business really cares about is when things are going to be done. And it's very, very valuable skill for a team to be able to communicate clearly when a software product is going to be done.
We go back to that empathy being a shared skill. You need to have empathy not only for the software delivery team and the people that are going to use the product, but also the rest of the business who's going to be impacted when that product is completed. Imagine you're not in the software team and you're just waiting for this product to be finished, to do your job. It's going to be very anxiety-inducing, and it's probably going to make it difficult for you to perform your job well. Instead, by sharing this predictable progress as a product and design team, you're able to elevate yourself in the conversation of the business from, are the mock-ups done? To if we skip research, here's the impact, and we may need to bring on an additional designer to accomplish both research and design for the upcoming sprints. It's a much more productive conversation to have as a group.
The key to this and the key to any sort of design and product team working consistently is for everyone to agree on a consistent approach. For us, we call that our Secret Source, the Devbridge Secret Source, but really after you have that, that's when you get to improvise and kind of come up with those moments of, okay, here's where we need to have a unique approach. If teams come in and everyone's kind of trying to do their own thing, it's very chaotic for anyone in it, but it's also very chaotic for anyone observing it. And so what I'd recommend as well for your teams is that you have a set of plays ready to go for different kinds of engagements. We have a handful of different plays that are ready to go. And I know, I know it's a flow chart. Some of you right now are very excited.
Some of you are like, oh my gosh, Chris, is there actually a flow chart in a Full Stack Friday, yes. But really this decision tree is valuable because it says, if you're trying to validate the viability of a product, what do you need to do? And this takes our teams through a series of decision points to determine if a product after we workshop with a client is actually ready to go into delivery or if it needs a validation period of discovery and definition where you validate the viability of the product, say whether or not there's even a product to be built. And then after you have that certainty, moving forward with the delivery. Having a place like this that goes as far as even to say, here's the exact team that you need, here's the time you should carve out, and here's the output to expect, and even what you might do week over week, is an incredibly important step in building up that consistency of practice and then being able to deliver that value to the business.
The other piece about that I think is really important is, there's this lens of, you have to bring design thinking to the business. How do you bring design thinking to the business? I think the first thing you do is, you don't talk about it as design thinking. You talk about it as, here are the activities that we're going to do. Here's the results that it's going to generate for the business. And here's what comes next. Every activity that you do and every specific step that you take as a designer should be moving the product forward. And if you can't answer the question of what do we do next, how do these things carry forward, then you aren't ready to actually execute that activity, and maybe you don't need to do it at all.
This also means that you need to be inclusive in the way that you design. So when you're doing something like a Crazy Eights activity, and you're engaging multiple different stakeholders, that means bringing product and engineering and the clients together to all go through the ideation as a group. So they can carry that context forward, and they have a shared meaning and shared understanding of why they're doing it. At the end of the day, when you're working on any kind of effort, you're trying to answer the question of, why aren't we building that software yet? If we're still trying to figure out how to build the software, we need to figure out what questions need to be answered. And you can only do that by being a collaborative group, focused on the outcomes for the business.
You can't be focused on, well, I just need mock-ups, and engineering just needs a build pipeline, and just needs a CI/CD pipeline. Instead, you got to be focused on, what do we need as a team to have that shared understanding to execute? This also means moving past some broken metaphors that have weighed down our industry for awhile. This one in particular, where you're having someone who is getting incremental value. When you really think about this, and you imagine this situation and you have somebody who is starting out running, and they move into skateboarding, well, I want you to picture yourself on a skateboard. I would fall pretty quickly. I'm not very good at skateboarding. But then the next thing you're supposed to deliver, an incremental value as a bicycle, well, how much of that skateboard can become a bicycle? And how much of that bicycle can really be useful for a motorcycle?
And if you have the skateboard bike that's become a motorcycle, how much of that can you actually use to build the car? Instead of trying to think of, what are all these incremental steps, instead, answer the question of how can we connect people to the business? How do we bring people and their context closer to the business, and how do we actually make the business understand in terms of their priorities, what's important to people?
And so, instead of saying, we need to iterate until we have a car, we can say, we have a hypothesis that if we produce a better car, that is more eco-friendly, it's going to use less miles per gallon, people are going to be less guilty about using it, but also it's going to reduce overall traffic and congestion, and it's going to be more green for the environment, and also people are going to like it more. They're going to be more likely to buy it. These are all things that you can actually validate this hypothesis. And then you can say, if we make all these changes to whatever car we're building, we also think the revenue for the business is going to go up 45% over the next five years. When you have statements like that, you're communicating in a common language of metrics with the business.
And so when you're executing successfully in delivery, you have the right perspective, and you're well-prepared, that is when you really can start to design for outcomes. Metrics are a shared language of the business. And I think it's very important that we all learn to speak that language well. Good metrics are specific, actionable, and achievable for a team. Great metrics are also comparative and behavior changing. So you can compare the metrics with each other, and they actually drive and change behavior. This means that whenever you're doing an activity as a designer, you understand the potential outcomes. So over here, we have a two-by-two that ranks different design activities from whether or not they're reporting out information, or they're exploring possibilities to whether or not they generate qualitative or quantitative information. It's important to understand which activity are you using and why you're executing it, and being able to communicate this to your entire team, instead of just saying, we need an analytics platform, or we need user interviews, instead, being able to say, we need to get some hard quantitative data around this by analyzing whatever analytics packages in place.
And we also need to explore the possibilities by doing some user interviews with different groups and potentially also doing some sort of group conversations. These specific focuses for each activity, and having a reason to do it, and a risk of not doing it clearly communicated is how you're able to prioritize effectively with the team. We have to be able to clearly communicate the anticipated outcomes of every activity that we do as a designer. The other piece that's really important with this is, you have to be able to tell your story as a designer. You have to be able to take people on the narrative.
And this doesn't mean every time you do a design activity, running a mini lecture of what the activity is. It's not saying, today we did a usability interview, and usability interviews are conducted in this way. And here is the format. And we had a note taker and we had a facilitator. It is saying, we talk to people to address a specific question, answer that question and bring that answer to bear. It means taking the business and the entire team on the journey of, you came to us, and you said that you thought the entire platform needed to be reworked in order to actually ship the product. Well, we went we looked at the analytics for that, and we saw there were two key areas in the flow that were actually preventing people from moving forward.
So what we did is we went out and we prototyped each of these different areas of that workflow and then put the new design in front of users and then allowed them to react to that, and tell us what was working and what wasn't working. That feedback cycle drove progress and drove better decision-making for the team. And to do all of this effectively, and I have to emphasize this, this means designers we have to be able to speak clearly in the language of metrics. This also means then that the entire team should be speaking in that same language, when we talk about how we prioritize our efforts and how we reinvest in products over time. We absolutely must then engage the business in that same shared language of the metrics that we need for success. And that should be the common way that we communicate the outcomes that we look to generate.
Another key piece of this and this is universally true, a friend of mine, Ryan Rumsey said this, and it stuck with me, I think it was just about a year ago today almost. You have to do the math. And if you're a designer and you're not comfortable doing the math necessary, this is a great thing for you to focus on building up skills in, being comfortable in something like Excel, being comfortable in different analytics platforms and being able to go and find the information that you need to validate and to better understand the hypothesis that you have about your work.
So when you're able to do all these things effectively, as a team, we're able to also then set up the next wave of product teams to be successful. We're able to move past being these machete-wielding table seekers, and instead start to build a foundation for the future of the discipline. See, the design process, as everyone has, is not something that you just staple on every situation to make it better. You actually have to understand the context of the product that you're working on, and then be intentional about the kinds of techniques that you bring to bear. I want to share with you something that I call, the digital product maturity spectrum. I know, fancy title. It is a two-by-two that helps you understand the type of product that you're working on, the type of activities you should be using to focus on.
So the first matrix to track across is how much time you have available, and what the outcome is you want to generate. The next lens to consider is whether or not you're actually thinking of a product with an outcome, or you just have a PRD full of features that need to be built.
And so every engagement is going to fall in one of these four categories. If you're product oriented and outcome focused, you're going to be doing true strategy. But if you have a feature list and you're trying to say, you have a set feature list, and you're also outcome focused, this is where you get caught up in those dangerous innovative products that maybe sit and churn in an innovation team for a long period of time but never really find the light of day in the market. The other one to be aware of, is when you have product thinking, but time isn't focused. And so if time is limited, you really have to ruthlessly prioritize and focus on getting delivery of that product out the door to the deadline. And finally, if you're in a situation where the time is highly focused, and it's also very feature-focused work, you're really doing some kind of staff augmentation or delivery augmentation.
I think all of these have a time and a place, but what is really dangerous is when you're working in one quadrant and you're pretending that you're working in another. And so as designers, we can help the business understand what kind of product they're working on and how it actually is situated in a compendium like this. And then we can create a strategy to say, okay, each of these different products should move in a direction across this matrix. So we should invest more in product thinking for innovative ideas that work, prevent them from becoming innovative. And for something that really just has to get done and it's a set of features and a set of time, lean into the fact that you're in pure execution mode. Because when the entire team is moving together in that pure execution mindset, yes, you're more likely to incur potentially product and tech debt, but also you're more likely to accomplish that goal more quickly and then move onto the next more valuable thing that needs to get done.
This means making smart investments and being able to communicate those is a key skill of leadership, especially within a product team. And designers, very rarely you're going to get taught this in advance. So you have to work with your teams and develop this skill. And the rest of the product team, you have to expect this of the designers that you work with. You have to be able to communicate across all different disciplines within a team and be able to empathize with their perspective and why they care about the product that's being delivered.
We also need to be building an ecosystem of learning and professional development within our teams. So to realize the full value of design within the business, you not only have to be able to communicate with the business well, you have to communicate well as a team, and have a culture of improvement and pushing everyone to improve together. No one is going to tell the story of design better than you are, and the value that it can bring to the business better than you are. But that means you have to be able to also speak in a language the business clearly understands.
You have to have a default stance of collaboration. Design is not this magical savior of product. This champion of the user. Those moments are there for design, but they're there for every other role as well. We have to break the cycle of having role conflict within software teams. We've all heard teams go, oh, those frontend devs, oh, those Q&As. I've heard product managers go, oh yep, that dev team, they're just real being real squirrelly, not getting the stories done. The way that we talk about our teams, the way that we talk about our colleagues, influences our attitude and influences our energy, which means we have to have a default perspective of collaborating and a shared goal, not wondering and worrying, well, I need this from them, or I need that from them. Instead, understanding the business purpose of their activity and how and why they might need support, and supporting them in that journey.
Now, someone who's coming up in design right now, and you're hearing this, you're thinking, okay, yes, what does this mean for me? A few parting words for those of you that are beginning that journey of product leadership. The first is, everybody who has come before you in any sort of product leadership role has done the best job that they could with the information that they had at the time. And let me tell you, some of that information was pretty incomplete and we did the best that we could. The other piece of this is that you're not alone. You have to lean on your network and your community to be successful. If we operate as a bunch of islands, all sort of championing our own journeys, we're never going to be able to develop a future-focused foundation, that design as a discipline can continue to build on.
Design has a moment. Well, we need to turn that moment into momentum and carry that forward. The other piece as well is that people are going to come after you. And so you're building the foundation that the next wave of the professionals are going to build on. That means you have to prioritize your focus and know that you can't accomplish everything. Be mindful of the impact that you're looking to make and how you want to develop your own career and your own skills and focus accordingly. This is also true for any product that you're working on.
The other piece is if you engage the business directly on business value and the tasks that you're going to do to get there, you have to share a clear line and a clear path to go from a concept, an an idea that you might be presented with to the outcome that you're looking to generate for the business. And sometimes people have a hard time articulating that. So you have to be comfortable helping people articulate and tell their own story.
The final piece of this is, well, is you're going to break things, it just happens. Anytime you're trying to build something, things are going to break. The current generation of product leadership, everybody that you see in a product leadership role today, we broke things. The key to being successful is to be transparent and honest about those moments, learn from them and mend more than you break. And when you have that attitude of being able to mend and help and support and drive progress together for a collective whole, that is where you're able to create real change.
And finally, very important, be good. I think design has an incredible responsibility in its role to help shape products that are beneficial and useful for everyone. That goal is shared across the entire team. If your team doesn't see that goal, this is where design has that unique perspective, not to represent empathy for the business, but to make sure their team sees the empathy in the work that they do as well. Be good in your actions and be good in the way that you do your work. It carries through and people notice. The design world is a small world, the product world is a small world. And the products that you use are going to be used by real people living their real lives.
So that's what we know now. Imagine how much more you're going to know tomorrow. Be ready for what comes next. And to do that, you have to be willing to learn, and to unlearn what's gotten you here.
I want to thank you all very much for joining me for this Full Stack Friday. There's a lot in here. If there're specific elements of today's conversation, where you'd like templates or assets or examples of how we do things at Devbridge, make sure to reach out and let me know, I'm happy to share those things. So again, thank you all very much. I appreciate y'all coming and joining me here for this morning's Full Stack Friday. If you want to reach out to me directly with questions, my email's here, it's Chris.Wilkinson@Devbridge.com. Also, please do feel free to reach out linkedin.com/in/cwilk, I'm on LinkedIn as well. And CWilk in most platforms if you want to find there as well.
About the event:
Full Stack Friday is a monthly meet up hosted by Devbridge where we share insights on product development, design, and process. The talks focus on issues relevant to product people and full stack teams. For more information about the next event, contact us directly.
