Take your design org from good to great with these principles from Segment to Twilio — Hareem Mannan

 Thanks so much for joining us for this conversation.

 Yeah, I'm excited to be here. Thanks for having me. 

 So we thought a fun place to start might be a Twitter thread of yours, uh, from last year. And, uh, in this, in this read, you sort of outline the idea that the best designers really have three things in common. Uh, the first is that they are amazing product quality ambassadors. The second is they're the glue that connects across product areas.

And the third is that they understand the GTM motion for the product. And so I was hoping you could maybe expand on those three areas and kind of what you've learned about each of them.

 Yeah, absolutely. Uh, I remember exactly why and when I wrote that thread, uh, we were just coming off, um, the segment acquisition at the time. And so I, for context, like I worked at segment still work there, but now it's Twilio segment. Um, and we had just been acquired and I remember it was this really great moment of introspection for all of us around, like, how did we get here and what made us special?

And I remember everyone was doing that kind of reflection on their side engineering and product. And then for me, from a design standpoint, I spent a lot of time just like trying to think about like what qualities made designers at segment really, uh, special and, and successful there. Um, so the first one product quality, I like to think about product quality, almost.

A little bit like an iceberg. And I feel like that's an analogy that people use a lot for different things, but in this case, I think, uh, if you think about an iceberg and like the part that's like peaking out of the water is probably the part of the design that you Can see, right? Like the UI or the user interface that people are interacting with is, is like the tip of the iceberg.

And then there's this whole area underneath that is a deeper meaning of what product quality really is. And so that is like how people are interfacing with the product. Are they able to actually accomplish what they came here to do? Are they able to like use the API APIs that they wanted to use, which is a little bit of an untraditional perspective on what designers should be thinking.

But I think the best designers that I had seen at segment really took that like entire iceberg from top to bottom. So whether that was like thinking about the visual design or the product design, or even just like engineering workflows and like made it their problem and made it their problem to not just like focus on in their own work, but also to evangelize and other areas of the product as well.

So almost like instead of just like problem solving, problem hunting as well, when it came to thinking about those areas. So that was the first one, which is just like being an amazing advocate for what a good product experience looks like across the entire stack of product quality.

 Can you give a couple examples of maybe what that looks like or in the last year or two, if you saw a colleague that really exemplified that idea, what, what kind of they were doing.

 Yeah, absolutely. I remember there was this period of time, actually. It was a long period of time. Um, sometimes segment gets the feedback that we are a little bit of a black box as in like you send data through segment and then you can't really see what's happening to it. We just like promise you that we're going to send it to all the places that you want to send your data to now, uh, in principle, that sounds like a product problem.

It also sounds a little. Actually it's a lot of an engineering problem, right? Like what's happening to the data as it flows through segment. But I think traditionally it actually is a design problem. And so a couple of designers on our team got together with our researcher and literally mapped out just like the journey of a data point as it goes through segment.

Um, and this is not at all like, uh, something that our customers can see. It's not a traditional interpretation of design, but it was certainly was a key aspect of what it means to invest in product quality, which is to think about the journey of a data point and then figure out what places are important to surface to our customers and our partners as they get a better sense of what is happening under the hood at segment.

 And so in that example, how do you think about where design picks up and product or product management leaves off or how those two things talk to one another or collaborate around maybe a product area or problem? Like the one you just explained.

 Yeah, that's a really great question. And I think one where, um, I have just like really enjoyed where I work because of my answer to that question, which is that. Bit of a gray area. Um, one of my mentors, Vanessa Cho, who's a design partner at Google ventures. Like one of her favorite things to say that, that she ingrained in my head is that good design leaders are indistinguishable from good product leaders.

And that's because the higher that you go in design and the more you start thinking deeply about design problems, you're inevitably overlapping with a lot of quote unquote like product surface area, um, and starting to think a little bit more critically about just like what your customers and the business are trying to accomplish.

And so, um, the key here is just to build a really strong partnership so that it can feel very, uh, fluid between the two. I think, um, in this example, design came with like the map of what this looks like and product picked it up and was like, okay, now let's brainstorm together in thinking about different ways that we can surface this kind of data visibility and observability to, uh, our customers that. 

 So in that example of, you know, you're hearing from customers a pain point, it feels like segments of black box. what is the role of product and designer product and product designers? Like how do you go from, Hey, we think there's a problem and an opportunity to do something better through, in this case, maybe a shipped product, like who, who is owning, what, or how are they working together to solve that customer problem?

 yeah. I think honestly, well, first it starts with discovery, right? Better understanding. Like what does black box mean and is all visibility, good visibility. And the reason I even say that is because we learned that that was not the case, that like, there is such a thing as the kind of visibility that feels disempowering to customers when you don't let them action on it versus like, what is good visibility?

And so there's a lot of. Nuance with the prospect of even uncovering what is happening under the hood there. And that's really where that partnership comes into play. Right. And it's not just say product and design partnership. Ideally it's a triad, like you have product design and engineering. So you have somebody who's thinking about like, what is technically feasible to build.

And then, which is the engineering leader. Uh, what does the customer care about, which is the design leader and what does the business need, which is the product leader and all three work together on solving the problem?

But I think each of them having those hats that they wear when they're coming together to ideate and think about what they want to do next really helps clarify who is doing what or who owns, what part of the process as well. 

 And so in one of these meetings that you have with. w what does that sort of look like? How are people contributing or what does it look like for someone in design to contribute in that triad?

 Yeah, I think, uh, if we were in office design is standing up writing on the whiteboard, you know, post-its in the hand, the very quintessential view, I think of the designer, but like typically their ownership is like driving clarity to what the problem is in the first place.

And that's typically a partnership between design and product. At that point, once they have a clear picture of what the problem is, they might split off and design tries to come up with some solution ideas, product, uh, approaches it a little bit differently and starts to think about like, what is feasible for the business to address at that period of time.

Um, and so I think it really depends it's on a case by case basis, of course, but that again, like constantly diverging and converging, um, where in, when the situation requires it is, is probably how that would go. I will say, uh, to add to that though, Is one superpower that I've seen designers really lean into is bringing their product and engineering partners along customer calls.

So that they're not the only ones who are steeped in customer context. I think that's a lot of times where teams end up getting a little bit tripped up is when there's only one person who's really wearing the hat of trying to advocate for what the customer needs and the more you're able to democratize that information.

Uh, the more I think in tandem, the team is going towards the same end vision. 

 Great. And before we kind of click over to this, the second category of great designers in, in this first, one of their amazing product quality ambassadors, when, when you talk to, to designer sort of up and coming folks that maybe have a year or two of experience, and they really want to grow in this area, they agree with you.

That it's really important. How do you coach people to develop and grow in, this first big bucket?

 Yeah, I think the first, like when you're starting off, especially as an early in career designer. My first goal for you as a designer is to understand what good looks like yourself. So you can't be a product quality ambassador. If, if you don't fully understand what good product quality looks like. So spend a year, two years, three years, five years, however long it takes for you to feel like you are able to, uh, evangelize and really create the kind of product quality that you want to see.

And then the next stage of that is starting to think about how you might influence that in other people. Um, we have like a bunch of endearing terms for that at segment. Like w sometimes I just call it the eye, right? Where you want to give somebody like the ability to see. Design problems wherever they stand and be able to point it out to a designers.

And so, um, being a product quality ambassador means that you're not just evangelizing that within your own product area, but also making sure that other people are also quality ambassadors around juice, that you're kind of building this chorus of like what good looks like in your company that allows you to like, be moving in lockstep with, with a team that agrees that it is important as well. 

 Okay, great. Let, let's go to this second category, um, and you framed it as they are the glue that connects across product areas. So would love you to share more about that.

 Yeah. So a lot of times design operates in what's called an embedded model, which is where designers are embedded in specific product teams that have different product charters, um, and what tends to happen. And, uh, in working at segment and then getting acquired by Twilio, you see this time and time again at companies of all sizes is it can be really easy to fall into a pattern of working within a silo of your own product area and not really thinking holistically about the end to end customer experience.

And that's where I think, uh, design can play a really special role. And we're great designers play a really important role is ensuring that there is somebody who is thinking about that horizontal product experience and not just the series of vertical ones. When you think about what makes a good PM successful, it tends to be how well they do in their individual vertical product.

Right. Like how well they're able to drive feature adoption for their specific feature or how well they're able to increase retention based on like the area of the product that they own. But in design, I think because so much of success is measured on how we think about the holistic end to end customer experience.

The very nature of how designers think about the quality of their work has to be more horizontal than vertical. And so great designers I've found really lean into trying to be that.

glue between a bunch of vertical product areas And finding opportunities for people to collaborate and work together to solve these kinds of problems.

 And so similar to sort of the first category, what does that look like in practice? Or what are the habits or what is a person doing if they exemplify this behavior or, or live this sort of characteristic or a value.

 Yeah, I think the first thing is, I would say it's on design leaders to create an environment for designers to share their work in such a way where you can see what other people are working on in the first place. Right? Like we can expect designers to be thinking horizontally if they don't know what's happening next door.

So, uh, that's the first piece. But the second piece is once that visibility does exist, there's an element of just like keeping your eyes open for potential areas of overlap. Um, an example is like at segment, we've had several designers think about how data flows through segment. And so like how you might regulate the data that's flowing through segment.

Sometimes that happens early on when you're trying to connect data to segment in the first place. Sometimes that happens towards the tail end where you're. Send data to, and sometimes that happens in the product that we have, that controls data, what I'm describing here, the three places, those are three different teams that are thinking about like the same type of challenge.

And this happens all the time at, at bigger companies as well. And even at, you know, back when this problem existed, like a smaller company, like segment where you have, uh, sometimes three teams that, you know, stumble on a customer problem, it's the same problem. And so how do you think about, um, design being the unifying voice?

And I remember at the time it was designed that highlighted that like, Hey, we're all working on the same thing here. And so how do I get everybody in a room and start to collaborate and think critically and deeply about like, what would be best for the customer in terms of where they should live and how we should solve this problem.

And that starts by recognizing that that was a thing that was happening in the first place.

 And so what are the rituals or touchpoints that allow you to surface these kind of meta problems that exist across the product areas? Because to your point, I, I, I would assume that what normally happens is not, you have, you know, call it five different product teams and everyone's like, I hate everyone else.

I just want to work in my work stream and do my own thing. I think what normally probably happens is like, it's a full-time job to be focused on this one piece of the pie 

 an in that you forget the holistic journey that you're talking about, that a customer may take across these product areas. And so is it just sort of a S some sort of meeting that surfaces, this, are there other, company-wide systems or ways in which you operate that.

Increases the chance that there's, um, a stronger emphasis on the end-to-end customer journey versus someone kind of just building their part of the widget.

 yeah. That, so, you know, what's interesting is I probably would have answered this question differently. Before we went remote. And like, after we went remote, just given, there was a lot more mechanisms and forums and you found a lot more inherent, just like, it's easy to turn your chair around and share your work when you were in the office together.

And when we first went remote, that was one of the first things that I struggled with in leading this team is suddenly it felt like a vacuum. Like I, you couldn't see what anybody else was doing any more in the ways that we were used to like more organically collaborating within the office or working together, or you would just like ask a designer for feedback just because they were there.

Right. And so it really comes down to creating intentional structures of visibility on your team. And I'll give you an example of how we've done that on my team. The first is that we kick off our week together now as a design team, and this is not necessary at all. Like everyone is working on very, very different things.

But one of the key questions we ask when we kick off our week together, that every designer answers is what problems are you thinking through this week? And the next question. Is what are some areas of potential collaboration with other designers as well. And so when designers fill out this doc every Monday morning, you're you have to like scroll through what other people are doing to understand how you might answer that second question.

And so many times people have been like, oh, you're working on an onboarding float. So am I you're thinking about upgrades? So am I, you know, you're thinking about this problem, I'm super interested in that my team might be thinking about that. And so that is one example of just like intentionally designing a meeting so that you're able to drive to the outcome of visibility.

So that's one example. The second is like, I would say that first example is a pretty heavyweight example. It's a meeting, you know, people have to get together every Monday morning and share what they're doing. And honestly do a little bit of prep in so far as like fill out the doc before. But it's exhausting to me all the time.

And, you know, I started thinking about like, what are lighter weight ways to create visibility, where we can encourage the sharing of work while not overwhelming people at the meeting. And so a very simple and small example that has done weirdly a lot for us is every Wednesday morning, like clockwork, there's a Slack bot that goes out in our design team channel that asks what's a screenshot or link of something that you're working on this week.

And every week, every designer and researcher shares what it is that they are working on through a link or a screenshot. And it has just been like a really, really great mechanism for visibility, especially in a distributed team, especially in a remote period of time. There's been conversations that are spurred from like, Hey, can I get quick feedback on this thing?

Or I didn't realize you were working on this, but starting to think about like, what are both like very intentional and maybe, um, maybe a little bit more formal mechanisms of visibility, but then also like lightweight and fun ones helps create those avenues for collaboration within a company that feel as organic as it might've felt being in the office and collaborating together. 

 That's incredibly helpful and specific. So thank you for sharing that I I'm interested. Are there other times that you. As a design organization, try to zoom all the way out to better capture sort of the full life cycle of a user, or does it happen in these sort of weekly meetings and sinks where you kind of figure out the rough edges or maybe how things fit together?

 no, absolutely. It definitely happens more often as well. I would say, first of all, the way that I like to think about designers stream of work is twofold. It's a, what I'll call a discover stream and a build stream discover is like, what high level questions am I thinking through right now that I'm chipping away at slowly, those might be projects that take weeks or months, and then build, might be like, I'm iterating on this feature right now and working alongside maybe my product manager and engineers on my team to start to figure this out.

Um, The discover questions are the ones where we have more of these like existential conversations about who are we for? Why do customers churn? What does it mean for people to buy this product? Where do people get tripped up in implementation? Why do they get tripped up there and implementation? And so we have these projects that run sometimes weeks, sometimes months to get to clarity on some of these things.

And what's cool is because they're so long. And because they are highlighted in these shared forums, it's really easy for other designers and researchers to jump on the train and be like, I'm actually thinking about that problem too. And so let me jump into that longer discover project and make sure that I'm able to benefit from that context as well.

The last thing that I'll add on that piece is we started doing our research leads, started doing what's called, um, customer insight demos at our company as well, which is a demo that is purely based on research. It's just, what did people learn about what our customers are saying that has helped really guide a lot of these kinds of conversations as well?

Because suddenly you're sharing that context. It's open for all of R and D. So it's, you're sharing that context with engineers and PMs and designers, and a lot of times designers and researchers and PMs presenting, but that context becomes readily available for anyone to action on in environments like that. 

 Let's move on to this third bucket Of what makes a great, uh, designer, which is they understand the GTM motion of the product. Um, and I'm excited to talk about this, this specific characteristic, because I tend to think that commercial orientation is, is sort of one of the most lacking skill sets across product engineering, design, and startups today.

And a lot of people just don't talk about it. And it's also something that I think is a little bit trickier to develop. Um, and so I'm curious when you, when you talk about GTM motion, do you sort of think about it in, in terms of like overall commercial orientation or, or sort of, what does that mean to you?

 Yeah. So I guess I'll start a little bit with like where this was born and where I started to realize the importance of this. And I'll caveat this whole thing with, with, um, this is especially important for B2B, SAS designers and product managers in particular, you know, it becomes a little bit less relevant for, um, you know, a designer at door dash to fully understand there's not a different buyer and a user, right.

If I'm ordering my food, I'm also the one paying for it for products that are, you?

know, SAS products that is not the case. Um, and That's where understanding this distinction becomes especially important. I remember when I first joined segment, uh, I joined this team called personas, which is one of segments, flagship products.

And at the time it was. Like five dudes in a sweaty room, trying to figure out this prototype that they had built, that customers were like pulling out of their hands. And so I spent the first six months doing, and I'm making this term up. So bear with me, but like what I'll call bottom of the funnel usability work, which is basically thinking about how people were using.

The product that had already existed. So trying to understand where they were getting stuck, why they weren't implementing it, what was going well, what wasn't if they turned, why they turned a lot of stuff after they had already bought the product and what I was missing. And the big view that was ended up being a huge unlock for me was, you know, the opposite of that, what I'll call top of the funnel usability, which is understanding why people bought us in the first place.

And I remember exactly when that unlock for me first happened. It was when my product manager at the time, Alex, um, was going on a sales trip to New York to go visit some customers. And he asked me to just come along, uh, to just sit in on some customer research. And I ended up accidentally, I think, tagging along a lot of sales calls.

And I still remember the moment when I first heard. Segment personas be pitched, uh, in a sales meeting to a customer. And my mind was absolutely blown. A part of me was like, I can't believe we're pitching it this way. Like, I don't know if what we're building right now fully aligns with the promise that we are making here.

And then I kept thinking about like all the things I would do differently. Had I understood the business outcome that all these customers were driving towards. And because I didn't have that top of the funnel. You know, usability context. I didn't understand to what extent the product should be pivoting to words, the buyer and the user in different ways.

Uh, and I remember as soon as, uh, we, we came back from New York. The first thing that I did with one of our engineers was completely re-imagined the core product experience. Now that I had that context into like why they bought us in the first place. And it sounds abundantly obvious, but again, when you're a designer or product manager, sometimes working knee deep in a feature or a set of features, you're a lot more focused on how it's going.

And maybe for PMs, it's a little different, but like how it's being used than why it was even purchased to begin with, which is a huge mindset shift that I think unlocks a ton for, for designers. Once they do start to understand that.

 such a great way to bring this idea to life. Going back to what we were talking about a moment ago in this sort of first category. Um, and I think you kind of, you're, you're touching on this as you kind of talked about your, your own own journey in this one specific example, but how do you think other designers can develop this muscle?

 Yeah. I mean, I think the first example is, um, you know, sit in on sales calls and, and that is something I wish I did earlier during my time at segment, because I think I would have had this unlock, uh, way sooner. Um, and I think a lot of times designers, again, focus on talking to customers that already exist, not, uh, prospects or customers that could exist.

I think it's also, um, You know, important to do competitive analysis and better understand, not just the feature set of how your competitors are investing in their product, but also how they're framing it, which is not something that product designers tend to think they need to focus on. I think it tends to be more of a brand designer distinction where I'm going to see how maybe the competitor like frames their product, but understanding from a product designer perspective, how your competitors are talking about what it is that they do in the first place can help drive to clarity as well.

On some of the stuff that you feel like you might want to invest in, uh, in your own, in your own product area. And the last piece that I'll say is I, I love to onboard designers with like, you know, we have this concept of just like having a lot of one-on-ones and your first, like few weeks there at a company, um, a lot of times those tend to be R and D focused one-on-ones, but I, I have like a set of go-to-market market people that are like my go-to product feedback, people who are high touch with customers and always like chock full of insights.

That I like to tactically onboard designers with as well, where I'm like your partner for onboarding is a solutions engineer who is thinking about like these problems, but from a completely different angle. And it feels a little out of pocket sometimes for designers who are not used to thinking about the go-to-market motion at all, or who maybe have never worked with the solutions engineer before, but it quickly becomes a one of the most valuable partnerships.

I think that people end up having at a company, 

 Why do you think this specific area is maybe underinvested in or, or at times lacking in the design community?

 you know, I'm not entirely sure. I think a part of it might just be, um, you know, design can sometimes be very focused on having a seat at the table within R and D, which can be a little bit. Of a distracting conversation when you can use the insights that are generated from, uh, being a great partner to go to market and marketing and, uh, deeply understanding customer problems to create the seat at the table yourself.

And so I think it's, it's kind of interesting that it's not focused on, cause I do think it's one of the big areas of unlock that starts to really propel designers, ideas and careers forward as they play key roles in unblocking sales deals or understand the exact flow from how somebody buys onboards, uh, implements and then, uh, scales their usage of the product. 

 Something that's kind of been woven through our conversation thus far as is kind of the simple idea that that product designers should be spending a lot of time with customers and, and, and even prospects or folks in your sales, uh, in your sales funnel. And, and I'd be interested. One of my favorite questions is always when, when you're spending time with a customer, how are you using that time?

How is it structured? What are the types of questions you ask? Maybe. Why do you, do you ask them, are there specific things you explore with prospects versus customers that allows you to get the most useful information from that relatively short amount of time?

 Yeah, I think a lot of times when we do customer research, it tends to be with a goal. But the thing is because, uh, we were talking to a customer. You never want it to be only about the goal that we have. So if we're trying to understand how somebody had implemented segment, we also want to use that period of time?

to be like, and what would you add if you could, you know, and, and start to more deeply understand just like what a customer wish lists are.

Um, so the way that we tend to approach, uh, these, uh, customer interviews and conversations is obviously starting off at a high level, just understanding the demographic of the customer that we're working with, who they are. Why they bought us. What was interesting to them about segment in the first place, what their team size is, how many people are using segment, what their technical proficiency is.

All of this stuff starts to give us a better understanding of how we can slice and dice the data that we have later on to start to see trends across different types of customers or different types of users. And then we tend to dive into the meat of what it Is that we're trying to understand.

Sometimes it's a lot more free-floating discovery in terms of, we really just want to understand, maybe it's a customer who's turned and we want to understand like, why they've turned. And so we ask some high level questions there Sometimes we're truly testing a specific feature. And so we'll, uh, dive deep into that feature itself and start to talk through, um, how a customer might use it and get their feedback.

But we always close with asking customers my favorite question, which is just, if you had a magic wand, what is one thing that you would change about segment today? And that's my favorite question, because you tend to get like the best kind of answers about either the biggest pain point for customers or a feature that they're dying for you to have.

And it's kind of the magic of having a tool that people rely on that you get really crisp, uh, and opinionated feedback, uh, in those kinds of questions as well.

 Is there anything you do to avoid confirmation bias? I think one of the trickiest things is a lot of times you go into these conversations with an agenda or a story you're telling yourself about your product or customer. And so is there anything you'd do to kind of remain open-minded.

Hareem Mannan is the Senior Director of Product, Enablement & Design at Twilio, which she joined via the company’s Segment acquisition. She explores the three pillars that set great designers apart and her top lessons on hiring, onboarding and managing a high-impact design org. 

The principles to take your design org from good to great

Hareem Mannan explores the three pillars that set great designers apart and her top lessons on hiring, onboarding and managing a high-impact design org. 
