How to Build a Stronger Partnership with Design
How should design and product management team up on the journey to successful products?
Jim Dibble joins host Rebecca Kalogeris on the January 8 episode of Pragmatic Live. Get to know one-half of the team behind Pragmatic Institute’s upcoming design practice, take away next steps for creating more user-friendly products, and hear all about our exciting new course Design.
(This interview has been lightly edited for length and clarity.)
Rebecca Kalogeris: Welcome to the Pragmatic Live podcast series, where we tackle the biggest challenges facing today’s product management, product marketing, and other market- and data-driven professionals with some of the best minds in the industry.
I’m Rebecca Kalogeris, Vice President of Marketing and Product Strategy at Pragmatic Institute, and your host for this episode. Today, we are joined by one of the newest members of the Pragmatic team, Jim Dibble. Jim joins us straight from Cooper Professional Education, where he was a design educator, consultant, and coach. He’s been a professional designer, he has a ton of great experience, and he came on board to help lead our design practice. I’m excited to have you here today, Jim.
Jim Dibble: Thanks, it’s great to be here, Rebecca.
RK: For our listeners, can you give us a background on your experience, your passion for design and what brought you here?
JD: Sure. My career has jumped in and out of that triad of design, product management, and engineering. I’ve been in many of those roles, and I’ve also found myself jumping into education as I do that, so it’s kind of a pattern.
I started out as a software engineer in a very engineering-led organization. I found that I wanted more interaction with people, so I moved into education. I started teaching people how to design software from a software architect’s point of view.
I’ve continually switched between engineering and education. I found that in education I was trying to write the story of how the product worked after the product was created, in order to teach people how to use it, and the story didn’t make any sense. I realized I was really good at telling the story; I was just coming too late in the process. So that’s how I ended up on the design side.
User experience was a new field back then. Figuring out the ideal story for the product before you build it — or as you build it — is a really important skill in UX. So, I’ve come at design more from an engineering perspective, but then adding in storytelling.
That’s the work I’ve continued to do. I bounced between design and education. I was a design consultant for about eight years and then moved into design education for the last two or three.
RK: One of the things I find most interesting is your background, those two sides. It’s a background a lot of our listeners share: About 50% of the product managers we work with were engineers, so they have that kind of brain. Sometimes it is easier for product managers to work with engineers because there is the same sort of structure and thinking process they’re used to.
Sometimes, some of the tension with design comes from that left brain, right brain thing. So, the fact that you embody both is such a wonderful bridge, and you can help other people make that bridge.
JD: Definitely. I figured out how to work with engineers and designers, and now I’m figuring out how to work with product managers.
RK: Yes. So what attracted you to this opportunity? Why are you excited to join the Pragmatic team?
JD: I think that collaboration between different functions has been broken in a lot of organizations for a long time. People are under such pressure to get a product out and make sure it’s successful. Figuring out what other disciplines are doing and how to best collaborate with them — it’s hard to take time to do that. I really love the opportunity of being able to crack that nut. And the ideal way for product managers, designers, and engineers to collaborate is going to differ by organization.
RK: Absolutely. To your point, people often feel like those collaboration points slow progress down. “I would have worked with design, but I didn’t have time.” One of the interesting things we’ve been exploring in our new Design course is that it can actually speed items through the process and limit the amount of rework and loops afterwards. It might seem counterintuitive, but it’s important.
Like any good designer (or product manager!), you and co-director Shannon McGarity started off with research into the market and its problems. Can you talk about the different kinds of structures and collaboration models you found in the market, and where the struggles lie?
JD: Some organizations are well-staffed with designers, but in a lot of them there are fewer designers than product managers, and those are dwarfed by the number of engineers. We did find a couple different patterns.
One is an embedded pattern: the product manager has a team working on a product that incorporates one or more designers, who permanently work on that product or subset of the product. So, they get to build a pretty good, regular working relationship.
There’s another model where design resources are more constricted. It’s a centralized consulting agency model where, internally, there’s a design pool where you could request a designer. However, because they’re so short-staffed, you might only be able to ask for them for a very short period. There’s a lot of context switching for those designers, and that leads to different ways in which the product manager and designer might collaborate, because they don’t have as much time to build that relationship.
And then we heard from some people who from the beginning were partnered with a designer, not just once they had a new release to work on. Together, they explore the market and user problems. They do this dance of one of them leading and the other following, depending on what part of the process they’re in, but always together.
There’s a big variety. What we’ll cover in the class speaks to all of these models. There are just different tactics you might take, a different responsibility. The type of partnership you might reach for depends on your access to designers.
RK: That makes a lot of sense. Within those three groups, what were some of the common problems they shared that we’ll tackle in the course?
JD: A common problem is figuring out how to give enough context to designers: whether you include them early enough in the process so they can get context or pull them in later and then you convey all that context.
It’s going to depend on what setup you have, but context is really important to designers: understanding the people you’re serving, how they approach the products, the challenges they have, the knowledge they come with, and what they’re trying to achieve.
You might find that your designers pepper you with a lot of questions about that stuff, which hopefully you’re able to answer as a product manager, but maybe you’re not. Bringing designers in at the right point so they see and experience that context is really going to lead to a better outcome.
RK: For those who just aren’t bought in — who think, “No, I’m going to hit the designers later on when I need some wireframes. They don’t have time for this. I’ve got it covered.” — give them your best pitch as to the difference it will make to bring designers in earlier.
JD: They will be able to make decisions in the user’s interest, on the user’s behalf, while also taking into consideration the business context and goals you’ve expressed, without you having to make all those little decisions. If the designer has more context, you’ll end up with designs, wireframes, and flows through the product that are more intuitive, make more sense to the user, and are more likely to be accepted by the market.
Now, as a product manager, you don’t always have control over whether there’s a design resource available or how much of their time you can get. It’s not always possible for you to get them on your team or bring them in earlier, because they’re a limited resource. But we’ll talk in the course about things you can do as a product manager if you can’t get your designer in early enough to pave the way for that context sharing and for them to hit the ground running.
RK: It’s the same thing when we talk about working with development teams as product management: The more context I give them, the more they can use their own skills and creativity to find the right solution. There’s less of a specification required, for lack of a better word — no one wants us to do those, because they have that understanding.
What I’m learning from you and Shannon is that there are skill sets designers come armed with from experience and education, and they can bring different perspectives. I would love to dig into some of those capabilities.
JD: Yeah, designers tend to be steeped in user research, so they’ve had exposure to creating models like personas. If NIHITO [Nothing Important Happens In The Office] research is new to you as a product manager — or you just became more structured about it once you started taking Pragmatic courses — your designer or your design researcher could be an excellent partner in that NIHITO research.
That will give them context, but also you might learn some interview skills from them. Again, it depends on the designer’s training, but a lot of them are very comfortable with user research.
Designers are also often called on to do some form of facilitation and bring together multiple stakeholders. At a lot of organizations, designers don’t get to call the shots. Not many companies are design-led, so designers have developed skills around bringing people together who are cross-functional, helping them come up with ideas and feel connected to the ideas that come out of those sessions. Quite often, designers have to build those facilitation workshops. If you want to explore different types of solutions that your larger group could come up with, a designer could be a great partner for you.
RK: I think facilitation is often underappreciated. It’s such a powerful skill set and it makes such a difference in getting the entire organization behind a project or a decision. Sometimes, in companies with tension between product and development, there’s finger-pointing. Having that facilitation (and someone who’s not you leading it) can make it more powerful, because people are listening with different ears. It’s a strong addition to the process and the team.
So, what would you say is the first step in building a better partnership with design? If you’re fortunate to have some design resources, but it’s not worked as ideally as it could, how would you make that better?
JD: Part of it is finding a way to bring design in earlier, as we said, but also finding out more about your designer. They may be strong in research or visual design. There’s a whole range of skills that designers can master or want to master. Often, they start in a particular area of design and want to grow their skill set.
Find out where they can contribute to the project’s success by adding their skills and where they want to grow. Maybe they want to try out facilitation. That’s an excellent opportunity to bring them in. If you’re good at it, you can mentor them. And if they bring great user research skills, take advantage of that.
RK: We’ve talked about how design can be a partner for some of the early processes we think of as product management: market problems, discovery, and those pieces. What’s the other side? How can designers leverage product managers in solutioning? How should product managers support designers in the later processes, those key handoffs?
JD: In our research, we talked to product managers and designers, because we wanted to hear from both sides of the equation. One thing we heard consistently from designers is that when they’re coming up with new ideas for potential solutions and looking at big picture things, they want the PMs in the room. Product managers bring a wealth of knowledge and context, and they have great ideas, too. So, having them not just say, “here’s the problem, go figure out a solution,” but to be there in the sandbox asking, “What’s the variety of solutions we can come up with for this problem as a really informed brain?” Finding time for that helps create a better output and also build rapport among the team.
RK: As the departments work together and combine processes, what are some of the key artifacts that either they share or that feed into each other?
JD: The key artifact we typically start with after user research is building personas, a model that helps us understand the people we’re trying to serve, because we can’t all go out and research. So, what did we learn in research? Let’s bring it back and share with the rest of the company, so they can make decisions on the user’s behalf.
The great thing is that user personas are common in design, UX and Alan Cooper‘s work, but they also appear in the Pragmatic Framework. It’s a good alignment.
From there, come up with the ideal story for how the product is going to work, without all the exact details. From the user’s perspective, if they step up to this product, what’s going to happen? How much interaction will there be? What answers will they get? What will they be able to do because they have the product? Coming up with an ideal story is a great first prototype that the product manager and the designer can do together. Or, one could take the lead, depending on where their strengths are. You figure out the story not just so you can market it but so you can build it.
Finding a way to create those use scenarios — the context in which the user will approach the product and what happens when they use it — really helps pave the way for figuring out what solution is going to be optimal.
RK: In all the research you did, what surprised you the most?
JD: Surprised? I don’t know. I think there’s a very muddled understanding of what each other’s role is about. The designers we talked about weren’t necessarily working with Pragmatic-trained product managers, but they were very confused as to the product manager’s role.
We saw them slipping into talking about project managers instead of product managers a lot. But even in places where product management was more clearly defined, there was still confusion from designers around the product manager’s responsibilities. “When do they make decisions? When do I make decisions?”
That confusion is true for product managers, too, partly because designers come in so many different flavors and with so many different capabilities. It’s hard to know what to expect of the designer you have assigned. What are they capable of? What’s their understanding of what they should be doing? But there was curiosity in the midst of all that. It was like, “I’m confused, but I want to know more.”
RK: Well, that’s great. Speaking of knowing more, if one of the product managers listening attends our Design course, which starts in March, which of the problems we’ve talked about will you help them unravel?
JD: We’ll talk about setting the stage for collaboration with designers, but the main thing we’ll focus on is how design can help you keep the human story central to figuring out how the product is going to work.
What are the various tools you can use with designers, either with you leading the charge or with you following their lead? How can you use personas as a way to inspire innovative ideas? How can you use stories as a quick way to prototype what the product might look like and test that out before you actually build any code? And how to participate in or even lead the generation of many different ideas for potential solutions, because the first idea that comes to mind is probably not the best one. So, exploring potential solutions and then deciding what one or two are to move forward. Those are all the key things we’ll cover.
The other stressor for product managers is how to give good feedback to designers that helps them continue to refine and hone the solution they’re creating. And then how to go out and talk to the market and users about work in progress to make sure you’re heading in the right direction.
RK: That is a very full one day course, but it’s going to be great, so I’m excited. All right, I would be remiss if I didn’t also talk to you, Jim, about the design practice. This is the first collaboration between you, Shannon and the Pragmatic team to really create a course for product management on how best to leverage design. But right on the heels of this course you two are building the design practice. I know it’s early, but I would love to hear your thoughts on where you’re heading and why you’re excited about starting a design practice here.
JD: We’re excited to start again with research because it’s really important to us. We’ll go out and talk to people within the design community — but also design-adjacent spaces within organizations — and find the key problems they’re facing. My hunch is that we’ll end up focusing on helping designers position themselves to make contributions to their company’s strategic success. In our past life, at Cooper Professional Education, we saw that a lot of the designers who came to our training had honed their craft, and what they really wanted to do was figure out how to be a strategic partner and share the things they’re learning. User research can have influence and make an impact in helping the organization meet its goals.
RK: Advancing the strategic role of design within organizations makes a ton of sense. That is how we started on the product side: helping product managers not just be tactical output machines but also position themselves and how they do those activities to become a bigger strategic force in their organizations. There has been a very similar arc with design. There’s still a lot of room to help companies see the power of both pieces.
Looking further down the roadmap — because we have a product practice, a data practice, and now we’ll have a design practice — we’re looking at intersections of those three really powerful, growing parts of an organization. With that in mind, talk to me about how you see the interconnection between design and data. What are some opportunities there?
JD: Yeah, data scientists can use a lot of the practices of design as a way to help them figure out: “What is the story behind the data I want to tell, who is the audience I’m trying to reach, what problems do they face, and how does this data help them? How can I then visualize it in a way that either gives them the solution or helps them make the decisions they need to with this data?”
Because they don’t want to just know the data, they want to work with it and see how it applies to their problems. I think it will be really helpful for data scientists to use a design thinking approach to data.
And designers are using data more and more now. A lot of organizations create products that run in the cloud. We can watch how people are using our products. Data is being collected all the time about how designs are working, so designers can get feedback right away. They can do A/B testing to see which design has the desired impact. For designers, it’s about figuring out how to deal with that data and not be overly driven by it. How to use data as part of their arsenal but also make the argument to do qualitative research to understand users and their emotions. We need to help designers learn the right metric to measure and watch for in tests, so they can argue for collecting the right data.
RK: And even just making sure that the product is built, designed, and developed from the get-go to collect the data that’s the most powerful and meaningful.
So if you were to have people remember two takeaways from all the different things we talked about today, what would they be?
JD: I would say, bring your designer along as your buddy for NIHITO research. You’ll learn from them, and they’ll get the context earlier so they can make better decisions.
And the other thing is the importance of storytelling. Figure out what the ideal story of your future product might be before you start solving problems and adding features.
RK: Awesome. Thank you, Jim, for coming on today.
JD: Thank you, Rebecca. It’s been a pleasure.
