Working With International Product Teams with Brian Dreyer of Sightcall

Brian Dreyer - S3E6

Kayla: [00:00:00] Thanks for tuning in to Product Chats. On today's episode I talk with Brian Dreyer about building teams out and working with teams across the world. So hope you enjoy the show and don't forget to leave us a review.

Hey Brian, thanks so much for coming on today.

Brian: Thanks for having me. Pleasure to be here.

Kayla: Awesome. Well, in a minute or less, can you tell us about yourself?

Brian: Currently I'm a vice president of product management at a company called SightCal. I've been in product management 12 years now. Worked at some larger companies all the way back to some initial startups.

So I've had a lot of different experiences in product management. It's been great.

Kayla: So I think we'll dive into that, kind of like the different stages of companies and what that looks like. But I wanna hear a little bit more about how you actually got into product and what that journey has looked like.

Brian: Absolutely. The funny thing about product management, right, is like none of us go to school for it. So we all, we all have a "what were we doing before this" for the most part here, right? So I actually came from the marketing side of a [00:01:00] business. I was doing online and digital marketing, and I was working at a startup that actually had no product management.

So it was one of those where a couple of us internally actually transitioned into it. Really to, you know, provide that structure that we all kind of knew wasn't there. Nobody really had, you know, that full time experience of how to get there. But, you know, that was kinda learning on the job. So, but I came from marketing, I was doing a little bit, you know, on the web development side of marketing, so I was gathering some technical skills that kind of helped me, made that transition.

Really never looked back.

Kayla: And so with that, like what overlap have you seen with marketing and product? Like what skill set or what are things that kind of run through in both marketing and product.?

Brian: I like marketing as a background here too, and I know there's a lot of people that come from the technical side of the house.

So you see a lot of developers, QA managers, those kinds of folks that also do make the transition. Marketing specifically, you know, we have to get very good at talking about value and why things are important and why you should care, right? Cuz you're trying to convince somebody to [00:02:00] use your product effectively.

So it brings a little bit of that sales aspect to it, and I do think that is sometimes a harder lesson to learn. People might think that learning technical skills can actually take a lot of time. You know, I think if you've got a good aptitude for some of those kind of logical thinking and technical skills, so, I don't, I don't know how to program every single language, but I understand system architecture and system logic pretty well. So I can have, you know, perfectly fine and credible conversations with our engineers at really at any level that needs to be had.

But the marketing side really contributes to how you talk about your product. As a product management leader, there's no shortage of opportunities and scenarios where I am constantly talking about the company, why the product is important, and as a, you know, owner of a long term and short term roadmap, I really do need to be able to articulate value in why we are building things and why you are going to care.

And I do think that marketing side, that marketing background [00:03:00] really helped prepare me for that. Now, any product manager that's starting out is oftentimes not going to be thrust into the spotlight, from a public speaking perspective. So I had, I had some mentors to learn from, you know, along the way, you know, and pick up some tips there.

But you've gotta be comfortable getting in front of people. And on the marketing side, you know, I was already working trade show booths, in the marketing side. You know, we were there, we were talking about it and we were doing demos. Might have had a marketing hat on, but you know what, I was there doing it. When I got to product management it was like, all right, send me that show , let's go. I know how to do this. So a lot of that helped, really helped me prepare for it. So, I mean, I've done a lot of speaking as a product management lead. You know, big audiences in front of, you know, a couple thousand people, smaller ones at trade shows, you know, you're back on the floor.

So there's a lot of opportunities. So the marketing side of things really is, I think, an important asset to really kind of help prepare me for that.

Kayla: And I think with that, like you mentioned a few different departments, right? You mentioned marketing and sales, and something I wanna kind of dive [00:04:00] into is how do you actually collaborate with teams?

And let's talk a little bit about that.

Brian: I mean, there's no shortage of collaboration opportunities as a product manager. I mean, I, on a number of occasions had to kind of help people understand the role of product management a few times. You know, companies that have joined have been in different stages of having product.

Some have never had it before. Some have needed to restart it because it just wasn't working for them for one reason or another in the past. And. I usually draw product management at the, uh, the center of a bicycle wheel. We touch every department, and there are different opportunities and different times to touch the different departments too.

So you have your customer- facing teams and then there's pre-sales customer- facing teams that are out there trying to, you know, close new business. Then there's the post-sales teams like your customer success managers, your account managers, and customer support, and they need different things from you.

You know, sales loves to sell the future. I don't know, I'm sure you've been with sales teams, right? They love selling what you don't have. [00:05:00] You know, which is always a fun dynamic. So really making sure that, you know, you're really kind of articulating that. So they're not, they're not always over promising, but they're actually, you know, accurately promising. It's a big part of that communication. You know, the customer- facing teams are obviously interested in the futures for sure.

They bought something, they wanna know that you're the right partner for the future, not just a vendor. But, you know, we really do strive to be partners. But they also are in the weeds and they are using it and they know the ins and outs. And what they're asking for is very pointed. So being able to give a lot of that really hyper specific details, not just about what you have today, but you know, what's in that release is a big part of that.

So whether that's directly from a product management lead, you know, my current role, I've got technical writing on my team too. So, you know, really making sure that we are providing those details a minute. Makes sense to kind of keep that as close to product management as possible I think there too. But then you get into places [00:06:00] like finance.

Finance is an area that people don't always think about from a product perspective, but it's actually a really important role. I do have an MBA. I went back for my MBA after being in product for probably a little less than two years. One of the things that I saw really fast, and I know there's , you can find a lot of articles questioning the value of an MBA these days, and I get it.

It can be an expensive degree. You know, there's some financial education in there that is sometimes hard to get on your own. And I realize there's a you- to- me class for everything these days and there's a way to learn it. But you know, in an MBA setting, I did find, you know, that really that financial education really valuable. Because I tell you as a product manager, there's a lot of times when you've gotta be able to have financially credible conversations with your finance department, not only your CFOs. That can be cost of the platform, right? It's not just simple as like what these servers cost you, but actually distributing that amongst your revenue base is important. Understanding revenue recognition models [00:07:00] is pretty important.

I mean, we're in, we're SaaS companies. You and I. ARR is what we are all talking about. But, you know, 10 years ago that was a little bit different. You know, ARR was important, but it's not quite that, you know, must have that it is today because that's what all of our valuations are based on. But, you know, and valuation is a part of that.

So, you know, people forget about the finance part of this job, but there really is that too. And then we're responsible for pricing , you know, we don't do it.

Kayla: Yes.

Brian: You know, we, we do. We're responsible for pricing. Now, any good product manager understands that you don't do that in a vacuum. I mean, we don't just say, here's a price, go do it.

And, you know, there's obviously conversations, but, you know, really leading that function and leading that conversation and how that kinda, that go to market is a very important part of product. And then, you know, there's your executive level. You don't get to be an executive product manager without being able to communicate at an executive level.

So that's, every founder's a little different, right? Founders come from their own backgrounds. Sometimes you get very technical founders that want to know the technical details that are in the weeds. [00:08:00] Sometimes they're sales people. You know, you're starting to see more CEOs come out of marketing. And I'm starting to see CEOs come out of product, although I haven't worked for one yet, but I am starting to see that a little bit more.

They're communicating at the business level, not necessarily at the user level. So really being able to communicate at that higher level. Again, this is kind of like why is your roadmap important to your business? Right? You know, it's being informed by what the market is. Any kind of market transitions, customer needs, what you're listening to. But really transitioning and translating that to executive level, you know, roadmap and messaging is a pretty important part of that.

So I always tell people it's like, you know, every day is a little bit different in product management. One hour you're having very technical discussions with your engineers. The next hour you could be giving a roadmap presentation to a customer. You know, in the next hour you're informing your CEO about something.

So we wear a lot of hats. You know, there's no doubt about it. And I, you know, when I interview folks and I've done a couple like mentoring sessions, I [00:09:00] really do stress the interpersonal skills of our job. I mean, you, you talk about communication, it's like you've gotta be able to not just write an email articulately, but you've gotta understand who you're talking to and what's important to them.

And I think that's one of the really, that's probably one of the toughest skills to learn, to be honest. People starting out really do need experience to learn that, you know, it's hard to go from a college classroom.

Kayla: Something I actually wanna go back to is you talked about talking with like sales and success and support. And so obviously everyone in sales and success and support has a very definitive view of what they want you to build out because it's important to their customer and their deal closing or their renewal.

But how do you actually figure out what you're gonna prioritize? And obviously not every salesperson is gonna get their feature built, but how do you decide, hey, we're gonna build this out and it's gonna affect the most amount of customers or the most amount of revenue. How do you actually build that out?

Brian: Yeah, that's a very subjective question. I bet if you pull 10 product leaders, you'd probably get eight to 10 answers. You do a Google [00:10:00] search and you can find some frameworks for this. Like this kind of wish shift model is a pretty popular one. This weighted shortest job first, I think is what it's called.

I don't like it.

Kayla: Yes.

Brian: It prioritizes easy work is what I struggle with it. It, you know, it just, it may, There's a time and a place to do the easy stuff. In my mind though, if it's important.

Yes.

It's like, It's important. Plain and simple. So how do you figure out importance? To some degree, this is, you know, and I've said this to other people, this is where we make our money.

You know, there's listening, right, and looking for common trends and threads. So I keep an ideas portal. I've been doing this for, I don't know, six or seven years of a couple different companies of keeping an ideas portal that is, you know, even if it's just internal, email is a silo. I do not like feature requests that come in through email.

I want the teams that can suggest things to it to be transparent because they can vote on it, they can comment on it. It adds a little bit of transparency is probably the best word, but it's, you know, it's kind of a [00:11:00] crowdsourcing. You know, some companies are great at making this public, you know, I see some big companies that do these, you know, public like user voice type sessions.

But you know, there's a lot of ways to do it. Um, even if you just do it internal, I think it's a great way to do it there too. I would love to say that, you know, votes is the only thing that matters, but let's all be honest, big customers matter too. I mean, there's no way around it. And if anybody tells you that it doesn't matter, you're kidding yourself here.

Strategic customers do absolutely factor into that. Like they just do. This is, you know, we all have them, we all have their, you know, that top tier kind of customer base, whether that is the company name because you want to keep promoting that name or it's because of dollar value.

Kayla: Mm-hmm.

Brian: Sometimes it's both, but not always.

I mean, even my own customers, we've got some of the world's, you know, some Fortune 100 companies. We work with quite a few Fortune 100 companies. They're not all seven figure deals. They're not all of our biggest deals by any means. But they do, you know, they're big companies and they have big needs, and we want to keep promoting that too.

So, you know, it's a balancing act. I always tell people, [00:12:00] you know, it's like, well, 1) frequency is always a big factor. To me, frequency is always a big factor.

Kayla: Mm-hmm.

Brian: So I'm going down a level here. Frequency is a big matter. 2) Like how important it is, is it to the strategic direction that we actually have set forward? Like, if a feature request ties into something that we are already gonna be working on, makes a ton of sense to bring that in and bring that forward.

If we're doing a redesign, it's a great time to bring in some, you know, maybe some little feature requests, maybe some bigger ones. But if you're already doing work or you're already touching a part of your product and you can bring, you know, some of those in, even if they are low hanging fruit, maybe they are a little bit bigger, it's a great way to do it and bring that in there too.

And then, you know, look, strategic nature of where the request is coming from is a factor. Like I mentioned, we don't ignore that. Sometimes, you know, my, my experience with enterprises is, you know, everyone thinks that large enterprise is kind of scary. More often than not, they really just want dependability and credible timelines.

It's more my experience. If you say you're gonna deliver at a time, deliver at that [00:13:00] time. If that time is eight months out, more often than not, they're okay with it unless there's like some real impending event that is just changing things. Being credible and being honest and transparent is really what they're looking for.

So feeling good about that is, is an important part of, you know, having the right process in place so that you can say, okay, that release two quarters away, we're gonna put that in there, that's when we can get it done. And being able to articulate why it's two quarters away and not in one quarters important. From a sales perspective, you know, you're kind of weighing the strategic nature of new opportunities.

Is it a customer you really wanna land? Is it an industry you really wanna move into? Weigh those things too. I mean, we've got a couple, in my current company, you know, we've kind of switched to more of a verticalized sales approach where we're not necessarily trying to be something horizontally to everyone, but really focused on a couple of these.

We've got four verticals that we're going after. Two we're really dominating. Two are kind of nascent. So, you know, if we can add some product features to really give us another leg into those verticals, you know, [00:14:00] that's gonna find its way at the roadmap because we know it's got future revenue and sales implications.

It's a lot of case by case, like it really is, and that's kind of what, you know, you're weighing day to day and kind of request by request. So, and no, I hate saying no . I always wanna say yes to everything. Like I really do. I wanna say yes to everything. That's obviously not realistic, but we, you know, we try and we do our best.

So these are the kind of factors that come into it. So a lot of the frameworks, it's, it's hard to create a framework, you know, a quantifiable framework that really helps to tell you that this feature should, you know, be number four on your list versus number eight on your list. And that's why I've struggled with some of those prebuilt off the shelf models that you can find pretty quickly out there today.

They look good in a board presentation to justify certain things. And you know what? I've used them from a board presentation once a year. Do they really impact priority quarter by quarter? not that much.

Kayla: I know we're talking about, it's kind of like some systems and processes. Yeah. Let's talk [00:15:00] a little bit more about that, like let's dive into that, about like how to start a product team.

And I know there's not one right framework, right?

Brian: Mm-hmm.

Kayla: As you mentioned, but like what are kind of some rules that you, or pillars that you stick by to see success?

Brian: Mm-hmm. So let's take what starting a team kind of looks like here. So 1) probably the stage of the company's life cycle is an important determinant on that.

So I mentioned my first product job was with the startup. We were three years old, give or take. The company had never had product management. You know, we were maturing kind of on the fly. You know, there's a bit of learning as we went, as we were growing and looking for people. It was a lot of, you know, kind of busy work.

A lot of the grunt work, we weren't doing as much of the public facing side of things. In a couple other places I have gone to after that, I was in this one video management company that had parted ways, we'll say, with their product team prior to me joining. You know, without going into details, they just, they were not performing.

So now you had management that was looking for a product team to get in there and actually perform pretty [00:16:00] quickly. That's really not the opportunity to bring in people that wanna learn and that are on entry level. You actually do need a team that understands product management process and understands, you know, kind of working with developers and working with teams and you need some experience.

So in that particular case, you know, the first couple hires were, they were senior product managers, like they were not meant to be junior PMs right out of the gate. So you're looking for some communication skills. You're looking for people that understand user stories that hold working with developers.

You know, the place I'm in now is almost a hybrid between the two. The company itself is a little over 10 years old, and I joined about a year ago and there has never been a product organization prior to me joining this one. It was kind of an interesting place to start. You had a very mature sales organization, a customer success team that was starting to hit at stride, you know, and you had never had a product organization.

So you know, people you're looking for is one. You know, as we're coming, building a team here, you know, communication has been [00:17:00] wildly important. I can't bring anybody on that really cannot communicate first and foremost here too. You know, some of that product development side, you know, it had been going on.

You know, we had a founder that was effectively, you know, acting as a PM lead. So some of that dev process, while it may not have been textbook, it was still happening. Other times I've had to change dev process a lot. This one, you know, to some degree was about getting in and making sure the wheels kept turning.

Maybe they weren't the most efficient, but understanding, making sure it keeps turning. I mean, one of the hardest things about joining a new organization is like, you know, what are you inheriting? There's times when I've inherited developers, even a couple product managers that knew all the right things to do.

The process was good, they didn't know what they were doing in two weeks. So you have to kind of get in there and establish a roadmap fast, before you even really understand maybe all the different dynamics of the industry and things of that nature. In other times, you've kind of inherited.

This time I inherited a [00:18:00] roadmap, but really some of the surrounding processes weren't always there. So it kind of begs the question, you know, I try to hire for the strengths that we need, right? Most often. This time around, I have product marketing as well in my role sometimes. Sometimes product marketing standalone.

Sometimes it's on marketing, but in this case, we actually have it within the product organization, which I think is a good thing because that really means I don't have to do all of the communicating per se. Being able to really work with the development organization to really help deliver on those promises that were already made. You know, so that's kind of one of the interesting dynamics is like, what are you walking into?

You know, I went, walked into a big company too for a little while, and most of my experiences with smaller and startups and I would say it's startup life and small companies have been good to me. I think I kind of like it. I tried a big company, but why? And the, the slowness of it just wasn't me. It wasn't for me.

You know, like to produce. You know, I didn't have to do any change there either. You know, I always kind of just went in. You were kind of going through the motions and, you know, [00:19:00] that's good for some people. But, so to your point of like, what does it take to build teams? There is an assessment of the situation that you really have to make.

And my, you know, one of my always pieces of advice to people is listen first. Like understand the team, understand the dynamics of the people you have around you, and where are you going to be able to make the most impact right away. Sometimes that is feature development. Sometimes there's just some low hanging features.

Like just put your stamp on it, get it out there, and you can build some credibility that way. Other times it's bring some transparency to the process. Do you have people that you're working with today that can help you with that? Do you need to bring that skill in? Is something that you're gonna, you're gonna kind of look at, you know, case by case, company by company, but you know, there's a ,there's a textbook on how to do product and agile and scrum and all that stuff. What you don't have a textbook on is people. And people dynamics really do add that wrinkle. That makes every situation.

Kayla: I think with that, right, like what you kind of talked about is really assessing the situation [00:20:00] before you hire, right?

Hey, do we actually need to hire for these senior PMs? Like are we at this phase, or do we have the capability to bring in like junior PMs who are trying to learn and grow? And so I think it's really interesting just to take like a step back and before you just say, hey, we need to hire, hire, hire of, hey, what do we actually need and what's gonna fit this?

Right?

Brian: So currently my dev team is in Europe. The, probably the second time I've had a dev team in Europe, but I've certainly had distributed teams before. And as a, on a product nature, you know, that really means that you've got, you gotta have some people that are self starters, you know, in my particular case.

So I can't sit next to everybody because we're a continent away. When you wanna put somebody next to your development team, you know, they have to be able to work independently. So, you know, you're looking for people with some skills, not just communication, but you're also trying to assess work ethic, which to be frank, is a hard thing to do in an interview process.

But if people talk about, you know, some of their past work and their past projects and past products, [00:21:00] you, you know, usually you can kind of understand, you know, how independently they've worked, where they see autonomy, where they've been able to find autonomy, add some to their own. So you're trying to tease some of that out.

Now, if I was sitting next to someone, maybe I could, you know, coach them in certain areas, right? So maybe they do have the interpersonal skills. You like the way they think. Maybe their user stories aren't the best. Right? To me, that's like a very coachable skill, but it also helps when you're a little closer, or even if you're just on the same time zone, it makes the world a difference.

So there's a lot of different dynamics, you know, and you really do have to kind of read the situation. Somebody gave me, I mean, I got this advice, and I'm sure I've seen it in writing here too, right? You know, hire for the strengths you need, you know, and really focus on what that is. And that's one of those pieces of advice that's really stuck with me.

It's like, what do I need? What skill do I really need right now on the team, you know, so not to ignore everything. Product, I realize, is a multifaceted kind of role here. But you know, this role, we really need somebody that's gonna be able to talk to our [00:22:00] development, which means they gotta have some skills there and be able to be customer- facing.

You know, communication skills are gonna be pretty important here.

Kayla: If an aspiring product leader could take away one piece of advice from you, what would that be?

Brian: Be a good listener. Learn to listen. You start, when I start a new situation in a new job, I always take a listen- first mentality. Read the room, read the personalities, read the dynamics.

Don't be so quick to say, you know, well, we did this at my company, this other company, so it must be the right way to do it. That might be true in the end, but it may not be true either, and sometimes listening is the best approach. If you're going to be a customer- facing, you know, product manager, listening to customers, what are their challenges?

How are they using your product? You know, they may tell you they need a button that does X, Y, and Z, but that may not actually solve their problem. And you may have three other customers that have similar problems that are articulated differently, you know, and that sometimes you can solve all three problems with one feature or one solution.

So my biggest advice to people is learn how to be good listeners.

Kayla: [00:23:00] On that note, where can people connect with you?

The best way to connect with me is probably on LinkedIn. You can find me, Brian Dreyer. I'm currently the Vice President of Product Management at a company called SightCal. So if you see uh, Brian Dreyer in SightCal in there, that would be me.

Yeah. Thanks for coming on today.

Brian: Hey, thanks for having me. Good talking to you.

Thanks again to Brian for joining us on today's episode. If you want more product management resources, feel free to head over to canny.io/blog and we will see you next week.