How Product Managers can Work with Designers and Developers w/ Michael Sacca, President at Crew

Hey, this is Mike Beldito here with Product Collective, and we are back for another product launch. So thank everybody for joining us. I'm really excited about today's product launch, first of all, because I have a friend that is one of our guests, Michael Saka at Crew. But it's also a topic that I've always been really curious about because it's something that it's been a challenge for me and it's been a challenge for other product people that I know as well. And that's How do you as a product person work best with other people that aren't necessarily like you, you know, designers, developers, um, they're creative. So, um, I can't wait to get into that first before we do get into that, just a few, uh, sort of basics about what Product Launch is all about and the rest of Product Collective. And we also have a sponsor today, so I want to make sure I can let you know a little bit about that sponsor. But for those of you that are joining for the first time, Product Launch is a webinar series where you can think of this like a virtual fireside chat. You know, I love bringing all types of product people on board to talk about all different topics. And in the future, we already have one planned with Cindy Alvarez that's coming up in April. She's the head of UX at Yammer. That would be great. In the past, we've had Dan Olsen, author of Lean Product Playbook, all sorts of other product people. So the cool thing is, if this is your first time, you can actually go to Product Launch and replay all of the past Product Launch episodes. So I definitely encourage you to do that. And if you haven't been involved with Product Collective in the past, I definitely encourage you to go to productcollective.com and sign up to be a member. We'll notify you about Product Lunch sessions like this. You also receive our newsletter where every week we talk about different topics related to product management. And you also get free access to our Slack community for product people. So all sorts of cool stuff there. But Before we dive in and I introduce Michael, I do want to let everybody know about our sponsor for this product launch session, and that's UserVoice. And UserVoice, they've been a sponsor of Industry since day one, and Industry is the product conference that we plan here. But it's a platform for quantifying and qualifying the feedback that you receive so that you could basically find the most valuable place to spend your engineering resources, which is One of the reasons why UserVoice thought that this would be a natural place to sponsor, because we're going to talk about how to best work with engineers. So UserVoice is all cutting through the noise, finding that feedback that really matters from your customers. And again, a lot of you know that Product Collective, we put together this product conference every fall called Industry, but UserVoice, they actually have a product conference coming up next month. So especially if you're in the Bay Area and, you know, next month works out real well for you, And if you are really curious about data, their conference called Basis is actually all about data, and that's going to run April 28th, 2017. It's an entire day focused on data-driven product management. Speakers are being added, but Dan Olsen, I mentioned him before, he'll be at Basis. He's also going to be at Industry, so hopefully I'll be able to personally see you at both of those events. And I know there's a, there's a button below where you can learn a little bit more about Basis. With that, I'd love to get into the episode today of Product Launch. And first off, Michael, just thanks so much for being here. I really appreciate it.

Thank you. I'm excited for the, for the chat today.

Now, Michael, you and I often, we get to talk about interviewing other guests together because, you know, of course we both co-host Rocketship FM. And that's been a lot of fun. I know you've been doing that for years. But you're also the president at Crew, is that right?

Absolutely, yeah.

And maybe you could just talk a little bit about, you know, your background in Crew and sort of your role as president.

Yeah, so I joined Crew as part of our partnerships and sales. And so for the last 2 years, I really managed a lot of our larger relationships, setting them up, developing them, and also working with the product team to satisfy them. We were moving upmarket. And so we were starting to interact with larger corporations, they had different needs. And so I worked across the sales, the marketing, and the product in that partnerships role. And then when we split Crew and Unsplash, so Crew is project matching for designers and developers. It's kind of like the Uber for creative services. And then we have Unsplash, which distributes free stock photography. and it's royalty-free under Creative Commons, so you can use it wherever you want. And so that was a side project that we built at UnderCrew. We split them, and our CEO, um, Mikkel, he went over to run Unsplash, and I stepped up as president of Crew. And now I get to oversee the full operation, um, on the— of Crew as a whole.

Awesome, awesome. Yeah, when I thought you'd make for an interesting guest for this particular topic, because, you know, on one hand You certainly, you know, as president, you, you get to work with product teams, you get to work with the engineering teams and design teams. But just even as a company, like, this is what you do. You know, you're matching people up with designers and developers and helping them find that talent. I imagine you've had a chance to get a look at a lot of teams that would be considered successful product teams. And we know that successful product teams, you know, usually there's a lot of cohesion that's going on there among the product people, the designers and developers. But sometimes that's easier said than done. Why do you think that is? Why do you think it's, it could be a real big challenge to make sure that, you know, there is that cohesion?

Yeah, well, that cohesion is based on clear communication. And so we're all people, we all communicate in different ways, and we have different ways of, different personalities and ways of communicating. And I think those teams that work really well together, they have that thing that gels them, they have that, that system of communication down. And I don't think there's one system that works for every team. I think it's really, it's how the personalities come together. I've worked on a lot of different product teams and, you know, I started off as a designer myself. I wrote a lot of front-end code at an agency and really led the product team there before doing kind of the partnerships and sales at Crew. And I really think it's how the personalities come together. So the teams that we have, we work with a lot of teams under 5. And so they're, they're really at that point where they are the product team. So when we match them, we know exactly who's going to be doing the development, who's going to be doing the design. And it's pretty standard each time. And those teams that, that have that, that really good cohesion, that really good communication, work really well together. What we see in larger teams where we don't know who's going to be the designer, the developer on the project, but maybe the, the salesman or the project manager, manager is consistent. We do get inconsistent quality coming out of that because when they put the teams together internally, oftentimes the people that they're putting together don't have that real rapport on how to communicate, how to give each other feedback, how to say negative things without killing the kind of motivation of the team, right? Giving feedback is a huge component to any creative work. And when we don't do it properly, it can be really hard to continue that momentum and create a high-quality product when people, maybe they feel unheard or disenfranchised, or, or the team internally doesn't have a really good way of, of working out problems. So I, I think it all comes down to communication and product, and that could be cross, cross-platform or cross-team, you know, cross-discipline or even internally on a product team.

Yeah, no, that makes a lot of sense to me. And I mean, one of the things that I think about, this is a product person myself, you know, I've never been a designer or a developer, but I have been on product teams and been a product manager. Is there, in knowing that, you know, you spend a lot of time in design, is there something about designers, developers, what, you know, creatives that product people might work with, is there something about them that you feel like Product people, they just don't know, you know, X, and if they only knew that about their personalities, it would help. Or is it, you know, is it just— I mean, obviously everybody is their own person, you know, so is it— is there not that generality that you think we should, we should look at?

There's some, right? So we have to know the language, right? We have to know the language with which— so that we can find common ground. So we can't come in and not know anything about the tech stack that we're working with and the capabilities of that tech stack. The more that you know when you're working with a developer, the more respect and rapport that you can build. Build quickly. So I think one of the biggest, the biggest faults of a product manager coming in is they're not able to gain the respect of the team that they're supposed to be leading. And when you don't have the respect of the team, it's really hard to lead them, right? They, they, you, you, you kind of, you have your team, they start to ignore you. They start to kind of work on their own way. Rather than working together because they don't have that leadership. And so, you know, part of it is knowing the capabilities, part of it is being able to build a rapport outside of work. And the rapport part is everyone is different. You have to meet everyone where they're at. And so I think that's a harder kind of personal skill, right? And everyone builds rapport in different ways. They could be through company outings, it could simply be through being a good conversationalist and being able to relate. You know, maybe it's their kids, maybe, you know, whatever's happening in their life. I think that's kind of an unspoken important part of any sort of leadership is being able to meet each teammate where they are, not expecting them to meet you where you are in life. But beyond that, designers have their own language, developers have their own language, and whether you're the product manager or you're another department coming in, you need to be able to get on the same page. And so, you know, when, when you say something is easy, right, I think that's one of the biggest mistakes. Like, this should be easy, this should be quick. Knowing that's probably going to annoy your development team because they're the ones that say it's easy or it's quick, right? It's not, it's not you because you're not the one in the code You don't know the complexity of, of what's built. So while a feature may seem simple, there may be, you know, complexity outside of it that prevents it from being an easy fix or a quick fix. Um, and I think knowing that and readjusting some of our language to, to give that respect to their job, um, is incredibly important.

Yeah, it makes a ton of sense to me. And I'm trying to put myself back to when I was starting up on a product team, you know, from day one. And some of the advice you give, you've given already, could be really useful, you know, making sure I'm doing my homework and understanding the languages that, you know, my design team and development team, you know, making sure that the language I use, you know, I'm conscious of that, not saying, hey, you know, this should be easy, get it done. What else, if, you know, if I'm going back to when I was that new PM joining a product team and, you know, meeting that development team, design team, what else can I do to make sure I start off on the right track? You know, I want to make a good impression. I want to get this relationship going in a positive way right from the get-go. Are there other things you feel like I should do?

So I think putting in a system— there's something that we're working on at Crew right now, actually— is putting in a system so that people know when to give feedback, how to give feedback, what type of feedback to give. And you're really the owner of that information. So oftentimes designers will just throw, you know, a mockup. In Slack or in, what do you think, right? It's the worst question ever. What do you think is not particular, but if you're able to then coach them to ask specific people for specific information, and then also to give them a framework where to present their design. Don't throw the design in Slack, call a quick 15-minute meeting and talk through the reasons why you made those decisions. Give them that platform, because a design in and of itself is rather useless. And oftentimes a lot of the feedback you get, it turns into an argument because the designer isn't communicating why they made those decisions or the implications that they've already thought through from the suggestions being made. So then people are making suggestions trying to be helpful and the designer gets on the defensive because, you know, they've already thought through it. That's not going to work because of X, Y, Z. And it turns into an argument. But if you give them a framework with which to present that design to the development team, to the marketing team, whoever's relevant, give them a platform so they can do a 5-10 minute presentation and really talk through why, not just like, these are the features we want to build, but this is why I made this decision. As a product manager, it's your job to coach them and to get them there, right? It could be using sprints and different, like maybe agile processes that, that put that framework in so that developers can have their time to code and don't have to be fixing bugs every time that something pops up in Jira, right? There's a structure to it. Our job is to put that structure, give them a good way to work. And I think as a young PM, picking a structure, coming in and not saying, hey team, what do you want to do, right? Because you're going to lose respect right there. You say, this is how I've seen it be successful and this is how we're going to do it. and then you adjust along the way, but you have to have a framework so that you can start coaching your team to work well together. Cause really you are a communicator, right? You're, you're dealing with people who speak different languages and you are the translator in the middle. And we need to have a framework for that translation. Yeah.

So it's like you come to the table with something specific in terms of the process, but stay open-minded. I mean, knowing that you'll work with the team to figure out what's right for your team. I like that. And the meeting you mentioned, that seems like a really good meeting. I mean, there's— we actually on Rocketship, we did a whole episode on, you know, sometimes there could be really bad meetings. How do you balance out the communication side of it and then also ensuring that the product team is actually— you know, when I say product team, meaning designers, developers, everybody actually creating product, you know, you're not getting too over-meeting, you know, how do you, how do you strike balance? What have you seen works well?

Yeah. So I think you have to, so like, I like, I like sprints, not everyone does, but I do, cause it gives that focus, right? So you have that 2 weeks where the product team can build product, right? You're not having meetings every day, but you have that time when you be at a retrospective or maybe it's just a planning meeting where you're going over what you're going to do in the next 2 weeks. And that's the time where you have that design meeting, where at the end of the sprint, the designers can present their next ideas. The developers can say, this is where I'm stuck, or this is how far I got. But you have that framework where that can't just happen randomly on a, on a Thursday afternoon because someone has an issue, right? But you have a framework so that everyone knows that they're going to be able to come together every 2 weeks and have that discussion. Because meetings aren't bad. I think they can be incredibly productive. I just think we call meetings because things aren't getting done and then we just keep calling more meetings. That's not, that's not effective. But as product managers, we have the opportunity to, to balance that too, between very focused work time and, and making sure that people have the opportunity for very focused work time and then getting the planning done. A planning meeting is never an inefficient meeting as long as you have a structure, a framework, and an outcome to it.

Yeah, no, that's, that makes sense. By the way, I had a question come in and it's totally relevant to what we're talking about, rather what we just spoke about. I want to ask it now. You know, when you talked before about coming in and, you know, coming to the table with a procedure and a process and, you know, that will help win points with the team, but What happens when you find the team actually isn't following that? And so now you need to address with a certain team member, you know, there's a behavior correction that needs to take place and that can be tricky, especially, I mean, this is all, this all varies, but sometimes that person doesn't even directly report to you, you know, so it could get really, really tricky. Do you have any feedback for how people could, you know, help their teammates sort of change and adjust? How they're doing things to make sure it's in sync with your process without, you know, I don't know, without going about it the wrong way?

Yeah, I mean, I'm a very direct manager, so I address problems as soon as I see them and I address them in a very direct manner. I know there's ways to kind of talk around it to encourage, but I think especially when you're coming in new, it's really important to establish the the rules and the expectations. People respond well to expectations, right? And so if they know what's expected and they know whether they're choosing to or not, but they know whether they're satisfying those expectations or underperforming or just ignoring the expectations, then the next logical outcome, it could be moving them to a new team because they're not a good fit for this, but that conversation is really easy. Because now, you know, if you're upfront with your intentions when you're coming into a new team, you address issues as they come up in a nice but firm way. And you say, this is, you know, this is our new process. If you can't follow it, then we'll move you to another team, we'll find something else, or we'll have to let you go, whatever, depending on the size of your organization. That conversation is really easy. That conversation is hard when you haven't set the expectations, when you haven't had the hard conversations along the way, because now you're having this big conversation. Now it's, well, I asked you to do this and for the last 3 months you didn't. And then they say, well, you never told me that I was doing anything wrong. That conversation sucks. But I think a lot of small conversations, and it's really the job of a manager, is to nip those bad habits in the bud. Early so that they don't become these bigger snowball issues where you have to fire someone or move them to a new team, because that's bad on team morale. It's, it's never good all around.

Yeah, I think that's great advice. It's, it's like set the expectations but address things pretty much immediately if you see that those expectations aren't being met. It's what it sounds like, right?

That's my style. Yeah, I mean, it doesn't work for everybody, but, and But that's, that's how I usually try to get in front of it. Because then you're, you're, you're laying the path one way or the other, right? You can't force someone to do anything, right? But you can give them that fork in the road where they can join the team and become a very productive member, or they can choose not to. And all I can do is lay that path out clearly.

Yeah. Got it. Well, you, you mentioned a few things that I think it's really useful advice for product people on what they can do to head in the right direction. Are there common traps and mistakes that you've seen happen time and time again where, you know, it's head-scratcher to you, but it's just, it seems like these are common traps that product people make when working with design and development teams?

I think, um, so the biggest thing is biting off a lot, right? And, and so what happens is you have this big initiative that that you want to do, and you can imagine this amazing product that you don't have right now, but if you just built these 10 features, it would be great. And, and so what we do is we start these giant initiatives and the team gets burnt out because they're not releasing, they're not doing that, that they're not getting that satisfaction of having their code go live and seeing people interact with it. That's what we build. We don't build so that we can hide it behind a wall for a year. And then throw it out when, when it's not quite what we need. We build iteratively. And so I think breaking down logical pieces is one of the most important things that a product person can do that makes it easier for their team to not only see where they're going in the short term, but also the long term. You have to balance both, right? So if you want to do a big initiative, what are the smaller things that you can do to work towards it rather than needing to build this whole silo of a new product. And teams, they react well when they see success. When you go 6 months without any kind of like success or reward or positive feedback, it does wear, wear the team down.

Got it. Got it. Hey, by the way, I had a question come in on something you had mentioned before as it related to sprints and such. The first question— actually, there are two questions right on the same topic. Somebody had asked, you know, you had said some people don't like sprint product management and they're just curious, like, what are the reasons and are there alternatives? Like, what are the alternatives even to, you know, sprints and stuff?

The alternatives are like a more continuous delivery Kanban approach where, you know, sprints, they generally lock you into, I think the normal is two weeks, right? So in that 2 weeks, you don't push code live, right? You develop, you develop, you develop, everything is done, and then on that final day is when all the big feature list goes live. So that's a sprint model. You could do like a continuous delivery model, which is more like what I believe Facebook does. They were famous for doing it at scale, but where you just have product features and every day you're pushing up, it just goes live and there is no rules or kind of timeline. You just— each feature or each development has its own date on the calendar when it's expected to be done. When it's done, it gets pushed up. And so that's more of a continuous development. There's also like waterfall, and there's, there's verify— like different variations of sprints and agile and Scrum. But those are, I think, the two main ones that we see today are a more rigid sprint model and then a more continuous delivery model.

Yeah, it's an interesting, like, change of the times because I remember when people were like, well, what is a sprint? And now it's interesting to see, like, what, what's the option?

What do we do besides it?

What else would you do? But no, that's it. Thank you for pointing those out. That's definitely helpful. So let me— I guess it's more of a priority. Almost on our time, which time went by really quickly. But if anybody, by the way, has any final, any other final questions for Michael, let's definitely ask those. I'm open to that. But before anybody else thinks of their final question for you, Michael, just, is there any sort of advice, just sort of like final advice that you think is important for product people to know when they need to work with design and development teams? Just sort of a big takeaway that you feel like Maybe not all product people assume this.

Yeah, I think being the most organized and prepared person in the room is really our job, right? So when we're leading a product team, we need to be prepared, organized, we need to do our research, we need to know basic capabilities, right? It's not just about ideas and keeping things on a timeline, but it's really about knowing some of the capabilities for your team so that you can really work collaboratively. I often do research into different APIs and different solutions that we can implement when I want to develop a feature with, with crew. And so I will bring in, it's not always the one that the team chooses, but I help start that research process. And so when I have an idea, it's not just me throwing at them and saying, figure it out. It's, I have an idea, this is the stories around it, these are some of the possible solutions I've gone out and found. And then I let them do the research into whether, like whether it fits into our technical capabilities. But at least they appreciate that I have taken some of the work off the table and I've thought through some of the implications. And I think that's how you earn respect, especially in the design and development world. I think giving feedback in a really constructive way is really important when working with designers. So learning how to give good constructive feedback is important. Saying things like, this doesn't look good, or this doesn't work properly, or— that's not helpful, right? But being very clear with the feedback that we're giving, I don't think this will work because X, Y, and Z, or this feature is broken on an iPhone 6, you know, when I do this, right? Not just the button is broken, that doesn't mean anything. What's broken about it? Is it that you click it? Is it the wrong color? Is it that the wrong size? Does it just not show up? There's so many things that, that, that we, we say very quickly and simply that can be very frustrating to the team. So being prepared, doing the work, and coming into the meetings, um, I think is, is one of the most important things we can do as product people and that the team really appreciates.

That's, that's great. I think that's awesome advice, and, uh, and thank you for that.

I—

one, I'll take this final question from the audience here before we wrap up, and it was basically just what are, what are best practices or tools on idea exchange? Just like what's worked well for you in your past, Michael, or what have you seen on teams that, you know, again, sort of the idea cultivation and train up ideas?

Yeah, so we do a process where we scope on either Google Docs or Dropbox Paper, something like that. So that way we get everyone, the development team, the design team, to just get it in writing. So that kind of a stories, but usually a little bit more detailed about what we want to do. And everyone kind of voiced their concern in that because there's a nice stream of comments. Then we take that kind of scope and we usually go to the design process where we'll use something like InVision so that everyone on the team can start to annotate on top of the design. I think that's pretty essential. And then from there, we break it into the individual project stories or features that we're going to build and organize it. And we are just moving into sprints actually. So we're just starting to break it down. We actually used to do more of a continuous delivery process, but we hit some roadblocks with it.

Got it. And if somebody like, and I don't know how it works at Crew, but, or even your past experience, if somebody said, oh, I have an idea for feature X, How does that flow through the process? I'm curious about that.

So it depends how big it is, right? So if it's a bigger kind of initiative, we'll start, we'll ask them to write up a quick scope doc, and that could just be a paragraph or two kind of describing it. And I keep all those in a, in a folder. But if it's a smaller, like, idea that you can just describe in a sentence, we'll put it directly into the project management kind of like icebox, if you will, where, where the product team can then review it when they're looking for, for the next, features to build. So it really just depends how complex it could be. Is it like a small thing? Like I just want to add a skip button here. That's something we would just throw right into the, to the product roadmap. But if it's something where you're taking a feature and really trying to reimagine it, we would, we would run through a full kind of scope design and development process. Awesome.

Awesome. Very cool. Well, Michael, I think that will wrap up our time today. I appreciate you joining us. This is an awesome topic. And yeah, thanks for being here for it. If people wanted to keep tabs on what you're up to, or even if they thought of a question that they didn't have a chance to ask now, maybe can ask you on Twitter or something.

Is that— are you on Twitter? Yeah, @michaelsocca. Shoot me an email, michael@crew.co. Happy to help. Yeah, any way I can. Awesome.

And so thank you. And I want to say thank you everybody else for being here. By the way, if you see the background, I'm actually at Start Mart in Cleveland, Ohio. It's actually the biggest coworking space in Cleveland, Ohio. Just dropped by for a visit today. So if you're ever in Cleveland, a place to check out. And if you all have ideas on people you want to see involved with Product Launch, future topics, shoot me an email. It's just mike@productcollective.com. So hopefully I'll hear from some of you. Until then, thanks for being here, and we'll see on the next product launch. See everybody later.