In this week's episode, we speak with Kameron Canbaz, Product Manager at Yahoo, who shares collaboration strategies between product managers and engineers, highlighting the early involvement of engineers in the design process to preempt errors and align user goals. He provides practical tips for maintaining a user-centric mindset, urging regular communication with users and fostering a culture of empathy within product teams.
Key takeaways
Chapters
Featured Links: Follow Kameron on LinkedIn | Yahoo | "What we learned at Pendomonium + #mtpcon Raleigh: Day 1"feature by Louron Pratt
Episode transcript
Lily Smith: 0:00
Hello and welcome to the Product Experience. My name's Lily and this week I talk to Kameron Canbaz. He's a product manager at Yahoo who works on ease of use. He did a great talk earlier this year at Pendemonium and I managed to grab him for a quick chat after his talk to find out more. The Product Experience podcast is brought to you by Mind, the Product part of the Pendo family. Every week we talk to inspiring product people from around the globe.
Randy Silver: 0:32
Visit mindtheproductcom to catch up on past episodes and discover free resources to help you with your product practice. Learn about Mind, the Product's conferences and their great training opportunities.
Lily Smith: 0:44
Create a free account to get product inspiration delivered weekly to your inbox. Mind. The Product supports over 200 product type meetups from New York to Barcelona. There's probably one near you, Cameron welcome to the product experience. It's so great to speak to you today.
Kameron Canbaz : 1:06
Yeah, thank you.
Lily Smith: 1:07
So we're going to have a chat today about ease of use, which is a very interesting topic. But before we get stuck into that, it'd be great if you could give our listeners and viewers a quick intro to who you are and what you do in product today and how you got to where you are as well.
Kameron Canbaz : 1:25
Sure, yeah, so I'm Kameron Canbaz. I've been at Yahoo for almost 10 years, which is, I feel, very anti-millennial of me, so I'm not hopping around as much as I guess my generation would expect. I actually started in product. It's been about four or five years.
Kameron Canbaz : 1:41
Originally I was a user in the platform that I work on at Yahoo, so that gives me a unique perspective, I think, into how people use the platform and it gives me a lot of empathy for our users as well, and I got, I think, fortunate that a product role in ease of use opened up. So I made the transition there and I feel very, very lucky that I get to focus on just how our users continue to use our platform and to really just make it an enjoyable platform for them. But not I didn't study product management, I think when I was in college that wasn't even a track that you could get into, and I just think that my kind of experience, even in the company I was at prior to this, led me somehow into a product role, which I am super jazzed about.
Lily Smith: 2:25
Everyone loves product.
Lily Smith: 2:27
Yeah, it's hard not to. And it's super interesting that your kind of remit as a product manager is ease of use, because often you hear about, you know, product people or I think it's changed nowadays but, like in the past, you might have had, like, the product manager for the app or the product manager for you know, a specific I don't know revenue stream or something. So, yeah, it's interesting that it's around like this type of theme. I guess you would call it. Is that something that's common within Yahoo? That you know the way that the product teams are structured is more around like a specific I don't even know what to call it. Is it a theme, like an area?
Kameron Canbaz : 3:06
Yeah, you know it's interesting.
Kameron Canbaz : 3:11
It's a blessing and a curse when you're like a workflow PM, because a lot of things can become workflow items and truly, like, anything that's user facing is a workflow challenge. So we've kind of gone back and forth where stuff will become workflow things that we handle, which is great because the product managers in that area get a lot of experience on different aspects of the product, but then, of course, like sometimes that becomes just a lot for us to handle, which so we become experts in prioritization and figuring out what works. Well, but we do, I think, at Yahoo and I can't speak Yahoo broadly. You know I'm in the ad tech organization and so that's my focus but we have sort of I don't want to say siloed it because that's a bad you know that's a bad word now but we have product managers that focus on specific areas of the product, so, whether that's certain optimization features or different like flagship features for our ad tech product in itself, and then we have some PMs like myself that tend to have a broader area of scope.
Lily Smith: 4:10
Yeah, and one of the things you're talking about at Pendomonium is the experience that you've had with what I kind of usually call like non-functional requirements or like non-functional considerations for your product. So tell us a little bit about the performance and the error handling and all the errors that you were seeing within the platform and how that came about that you've got to be so focused on that aspect of the product.
Kameron Canbaz : 4:38
Of course. Yeah, I mean it's born from just ease of use in general and realizing that when users run into problems, even if they're not like workflow breaking or feature breaking issues, it's still annoying to them. And so it was kind of born from doing normal user research that we do a ton of and just hearing again and again from users that this page is slow to load or I keep hitting this error over and over and not having a really great way to quantify that other than just people ad hoc slacking us and telling us that issues are happening. So, of course, like what I'll go into in the presentation is how Endo really has helped us visualize that from more of a product standpoint.
Kameron Canbaz : 5:24
Engineers can see it because they build the systems and build the dashboards to understand what's going on a little more, but that takes time away from the cooler stuff that they're working on that I'm sure they want to be, which is building actual features. So we really saw that we kind of had this escalating issue with pages being slow, with users encountering more and more errors, and it got to a point where I think probably a lot of companies and a lot of organizations get to, which is this is just too much and we need to dedicate some resources to addressing those problems. I think we don't always want to do that, that it should be, in my opinion, more of like an ongoing effort to minimize and keep pages performance and keep errors down. But sometimes you're just focused on, like I said, like cooler stuff, yeah, and it can get lost in the mix.
Lily Smith: 6:13
And it's interesting as well from, like, a product management point of view, because I've never really I guess I've never really thought about whether that sits with products or whether it sits with engineering as a thing that is owned and checked and made sure is good. I guess it probably depends, depending on the organization.
Kameron Canbaz : 6:32
Sure, yeah, I think I mean my perspective, I guess would be anyone that surfaces the issue can can own it and help drive it. And so, yes, like we have engineering teams that are coming across errors all the time, especially when they're doing their own unit testing of features that are coming out, but they may not always be focused on all the user-impacting errors, so they may see that, okay, this click doesn't work, it doesn't get a user somewhere, and they'll fix it before handing off the product or end users to do testing, and that's how we'll catch a lot of errors. But these are more so kind of the errors that a user experiences but it doesn't flag anything in our system. Generally they can get around it and figure out some way to finish what they're doing, but it still stops them, even if briefly annoys them enough, that they're going to have a sour perspective of either that feature or hopefully not the product as a whole, and I think it can sit again in engineering or product.
Kameron Canbaz : 7:32
And our goal really was to empower product managers to take more ownership in it because at the end of the day, we're building this product and service of our end users and for us that's our clients that are running advertisements. For me personally, like I, having been a user and understanding the myriad things that our users do in our platform and all those little touch points where they can run into these annoying things it just became kind of a product driven initiative to get more visibility for product managers so we can help engineers pinpoint, you know, errors and then know what to focus on yeah, and I suppose, as a business like, depending on where you are in your place in the world, you know, if you're top of the, the food chain, as it were, you probably can be a little bit more relaxed about these things.
Lily Smith: 8:25
But shouldn't be, because there's always someone like you know chasing behind you, trying to steal your customers from you and stuff. So, yeah, having you know, having your eyes on this all the time, is just super important.
Kameron Canbaz : 8:36
Yeah, and I mean the perceptions matter too, because even even with us we have like a B2B product and those aren't, you know, the most talked about products in the world usually. I mean I'm sure there are some out there that I'm probably neglecting, that are talked about a lot. But you know, for us we are measured against our competitors and we believe, and I strongly believe, our platform is easy to use. But where it comes from is like we maybe have a history where it's not that easy to use. We've done a lot to address it, and errors and performance are one example of where and I think you sometimes, when you have those areas like performance but you don't pay attention to enough, that can kind of tarnish your reputation and you have to do a lot of rebuilding, whereas if you, I feel, if you build it into the process overall, you may not find yourself kind of at the bottom of the food chain. I'm not saying that we're at the bottom, yeah.
Lily Smith: 9:29
And I guess, like you say, having a product manager and maybe a team dedicated to that ensures that it's always a priority, and you have people championing that. Ease of use within the business. Yes, yeah.
Kameron Canbaz : 9:41
So yeah, I would say we very much, you know, and I don't.
Kameron Canbaz : 9:44
I don't know that that's how every company should be, or even that we should be, that I think if I made it like in an ideal world, if I was, I don't know, the power to be for product or whatever, every, every role would, would focus on ease of use. Every product manager that's building something that goes into the hands of a user should be asking themselves questions. You know, is this the easiest thing for our users? Is this simple? So that maybe you know I'm not talking myself out of a job, but you know, maybe we wouldn't need, like a workflow centered position, not we, as in Yahoo. I really feel like I'm talking myself out of a job, but I would think like I would love to see just more product managers focused on the end user, and I think there are a lot of them out there, and we certainly have a lot too, and I would say at this point, all of our product managers are very focused on our end user, but it's been a journey to sort of get there.
Lily Smith: 10:39
And you mentioned earlier, particularly around the sort of the identifying errors or like sticking points, I guess, where the customer's getting frustrated. I know in my experience like one of the really great things to look at is rage clicking and where people are like rage clicking pages or even just like playing back sort of like video replays of someone's walkthrough of your product or whatever not walkthrough, but experience, experience of them clicking through. Are there any other ways in which you can identify where people are getting stuck? You mentioned user research as well, so is that how you go about doing that too?
Kameron Canbaz : 11:14
Yes, so user research is very much a key way that we do that.
Kameron Canbaz : 11:19
A lot of our user research is more when we're developing features to make sure we design it in a right way to avoid those things, hopefully.
Kameron Canbaz : 11:27
I would say where we've noticed it, especially with the error tracking that we've been doing, is when you see a user just getting the same error over and over and over again. I think that signifies for us like, oh, they're clicking on the same thing, expecting a different behavior, and I think that's in part because sometimes that works. Sometimes there could just be a backend error that shows up and a user has learned ah, if I just give it two minutes and then click on it again, I'll probably get past it, which, again, not the experience we want our users to have. But the error tracking that we're doing gives us the visibility into when that happens and I would say that's specifically what we've been seeing the most in this error tracking is those types of instances where we have a high volume of errors that are coming from a select number of users and that's something where that's a roadblock for them and we can hone in on that and really address that and then just make the experience for them better overall.
Lily Smith: 12:21
And so if you see something like that in the data and you want to understand more about it, do you just reach out to that user and get in touch and be like, hey, what are you actually doing? Yeah, yeah, how are you breaking the product? Yeah, exactly.
Kameron Canbaz : 12:33
I love. That's. My favorite thing is to talk to users and have them show me what's going on. Yeah, especially when they're. I like when they're angry about it Not that I like angry, I hate angry users. I hate that users are angry or get angry, but for me that's a problem that we can solve. And so, yes, we reach out to users when we see that they're experiencing that type of issue. If it happens a lot, you know, for better or worse, users tend to reach out to us. So I think another benefit of having been on the team and just having, I guess, done the anti-millennial thing and been at this company for so long is that I get Slack messages all the time from users that are experiencing problems, and I think, at least for us like when we have our product managers that are so connected to our user base and so open to that, it helps us identify where our users are getting the most frustrated.
Kameron Canbaz : 13:23
Of course, you have to balance that with you know the loud. What is the saying? The squeaky wheel gets the oil, or whatever. The loudest user, like you know, we have to pay attention that we're not just fixing one user's problem, and that's where, when a user comes to us with that issue, we can back it up with data. They'll bring to light something that's happening in the platform that maybe we didn't know is happening. And then we can look in Pendo, look in our data, to see, okay, like not validating, because I, you know, I trust our users, but just seeing how much it's happening and for who else, and so we can really prioritize our fixing the errors and performance that way yeah, nice.
Lily Smith: 13:59
So how do we make a case to invest in funding time to a I look into it if we're not already looking into it in terms of performance and errors, but then also spending time on fixing some of these problems? And I guess, how do we even know? It's like you say, if one person is experiencing it, do we jump on that and fix it, or do we, you know, wait until other people have? Sorry, this is like 20 million questions in one. That's okay. That's okay, I'll try. I'll try. You know the direction I'm going. Yeah, absolutely.
Kameron Canbaz : 14:30
Yeah, I would say it's all in service of the end user's experience and it is difficult, if you're not tracking this sort of stuff, to find it, of course, because it's not going to be in the data. So I think, first and foremost, and something that we've been doing for years, which is just talking to our users and doing user feedback sessions, not just when we have a new feature that's coming out or a new product, but kind of the maintenance conversations of just seeing how's it going, like, what's going well on your day to day, what things are frustrating you. I tend to ask like a very specific question of tell me about the little things that annoy you, that take an extra click or that take a long time, because I find and I remember doing this as a user People will tend to think oh, I'm talking to a product manager, I'm talking to a designer, I need to come to them with, like, big ideas or really big problems, otherwise they don't care.
Kameron Canbaz : 15:24
They don't care that I have to click on something four times and for me I just try to like get that out of the way at the beginning of a session to say like I don't care if it's the smallest thing. Like we had an issue where you couldn't paste a dollar value with a dollar sign or a currency sign into a field without it giving you an NAN error and we weren't hearing about it. And just simply, out of all the features I think I've put out and worked with teams to put out, fixing that got the most unsolicited feedback of anything. They're like oh my, I can actually just paste something from a spreadsheet and it's. It's small things like that that don't just come up too naturally unless you, specifically, you know the freedom to bring that up. So I would say the first thing user feedback sessions, just maintenance and for new features.
Kameron Canbaz : 16:11
Outside of that, I would say, once you're addressing, if those sessions are giving you this impression that there's stuff you're missing, you really, I think, need to look at how you can start measuring that and how you can start getting that information from whatever measurement tools you're using hopefully at least one, but you know to get to sort of see, okay, like these are the things our users are telling us. Can we quantify it and see is there other stuff that we may be missing? And I think what also helps with that is just the error messages that are given in a system anyways, which you know I'm not, I don't have a technical background, but I do know you can do logging and I think if you're already logging errors in your system, just seeing what they're telling you know, telling you about what your users are doing, and I think just with that alone provides probably plenty of ground of things to address. But yeah, the important thing is talking to users and measuring in some shape or form.
Randy Silver: 17:14
Product people. Are you ready? The word on the street is true. Mtp Con London is back in 2025. We're very excited for Mind the Product's return to the Barbican next March.
Lily Smith: 17:26
Whenever I hear people talking about the best product conferences, Mind the Product is always top of the list. If you've been before, you know what's in store. Oh, that rhymes. New insights, strategies, hands-on learnings from the absolute best in the field, plus great networking opportunities. And if you're joining us for the first time, I promise you won't be disappointed.
Randy Silver: 17:48
We've got one speaker already announced. That's Leah Tarrin, who you've heard on this very podcast. With more to come. From the likes of WhatsApp, the Financial Times and Google, you know real people working in the field who will share real actionable insights to level up your game as a product manager.
Lily Smith: 18:06
Whether you're coming to the Barbican in person on March 10th and 11th or tuning in digitally, join us and get inspired at MTP Con. London Tickets are on sale now. Check out mindtheproductcom forward slash MTP Con to find out more, or just click on events at the top of the page and you made a really interesting point there as well of like you don't have a technical background. I think product people may sort of like maybe shy away from this a little bit because it feels quite technical. So what, what have you found? Works really well when you're talking to the engineers about some of these issues and some of this stuff and yeah, and trying to like uncover, like really what's going on and what they're seeing from their side as well great question.
Kameron Canbaz : 18:56
Um, I think a lot of it's. So where to begin? I would say a lot of it, at least in my experience, has been getting engineering bought into the user experience as well, which I think every engineer, at least that I've encountered, is really honed in on. Okay, I'm building something, but what am I building it for and what impact does it have on a product but also on users? And so I think that talking to them a lot about kind of the user journey and showing what's happening and what sorts of things we want to track, goes a long way.
Kameron Canbaz : 19:28
So at the end of the day, I think product, you know, of course, sits in between engineering, ux and our users and we help coordinate, like air traffic controllers I guess, and all of this stuff. But everyone's human and they want our products to succeed and our users to be able to get things done in an enjoyable manner, and so working with them just to understand like this is why you know a user experiences this error or they have this frustration, and sort of quantifying like that takes five seconds away from their day, which doesn't sound like a lot in isolation, but when you add it up across all their actions, that can be a lot, and I think a lot of the discussion too, is why we want to measure, that is, we want to make sure like we would for sure prefer it to be five seconds out of their day versus five times 200. And so I think just getting them bought in or just included in the conversation about why we want to track this goes a long way to getting to that point.
Lily Smith: 20:26
And do you get involved in things like you know when a new workflow or feature is being created, like understanding what errors might come up and designing for that side of things as well?
Kameron Canbaz : 20:39
Yes, yeah, so we. It's a very collaborative in the sense that one product manager with a feature will work with the UX designer. So I'll work with them to do all the user interviews, do mocks, et cetera. But we're also reliant on the users who really understand these workflows especially when we're enhancing a current feature that understand what roadblocks they'll run into. That way they can help tell us sort of those validations, right? So I shouldn't be able to do this because X.
Kameron Canbaz : 21:09
And then we want to make sure in the design that not only do we just prevent them from doing that, that we understand why and what their end goal is, so that we can design around it or help them through it, so that they don't end up clicking on something they don't have access to because it's like, well, why could they click on that in the first place? And so I think that helps us answer those questions. And we can do a lot of that in the design phase and honestly, we should as much as we can, because that's the easiest to iterate in. I think everyone knows, once a developer's built something, much harder to change it and much more costly to do so then yeah, Awesome.
Lily Smith: 21:44
So what would be your top tips for a product person who's listening to this, or even well, I say product person that could be engineer, designer, whatever.
Kameron Canbaz : 21:53
Sure.
Lily Smith: 21:54
For them to you know if they're thinking this sounds great. I'm not thinking about this right now and I really should be thinking about it, like where should they start?
Kameron Canbaz : 22:01
I would start with again seeing what users I think I always fall back, and I think people at Yahoo know me as someone who's like anytime they ask me that sort of question or anything. It's like oh, are you talking to UX? Yeah, Like, are you working with designers on this? And also importantly, are you talking to your users? I think part of our role should be weekly, daily. Whatever works best is talking to end users, because they will tell you about those nuances.
Kameron Canbaz : 22:28
And I would focus on too, like asking them outright what are your pain points, what's something that you experience often or every day that gets in your way that you wish just wasn't, there, didn't happen or there was a different way, and I think that alone can really hint at whether there's a bigger issue in something you want to address. And then, second, I would see if there are any tools currently at the company you work at or on the product that is already measuring some of this stuff. And if not, like are there processes in place with your engineering teams or support teams that can help you measure and understand that Things? Like you know, we have ticketing systems. I guarantee like there's at least some tickets out there of a user complaining about something, and I think that's a good place to start to kind of get in the measurement mode of looking at these sorts of issues Because, at the end of the day, like these little things are what make a product feel bad.
Kameron Canbaz : 23:21
You know, like my role before Yahoo I was working in software implementation and warehouses, which I never thought I would grow up to do that at all. But like we worked on an enterprise resource planning software suite and just seeing like how complex that is and then hearing directly from users that used it, like how they didn't understand it, and just I've always had a knack for being really honed in on the experience of the end user and the problems they run into. And so I think like if you, if anyone, can get more into that and more into talking to users, it's always going to be a net good thing.
Lily Smith: 23:59
Yeah, Do you ever like use the product yourself? Because I guess it's that must be quite tricky if you don't require doing any advertising. I do not advertise myself Because that must be one of the ways in which you can kind of pick up on some of these things. But then if it's not a product which, naturally, you need to use in your day to day, that must be quite tricky.
Kameron Canbaz : 24:23
Yeah, and we've floated some ideas that we haven't quite, you know, gone forward with. But some of them, yes, like, definitely use the product, but in more so now, in a sense of when I'm working with engineers on a feature that we're having built, we'll test it as product managers first, and that does involve, you know, we'll partner with nonprofits to use their like PSA ads and then, where you can assign them to lines and then pretend like we're users. That gets you only so far, of course, because an end user is going to have all the business knowledge. They're going to have interactions with clients to really know what to look for. But it does go a long way for all of our product managers to be using the platform at least a little bit, and certainly, when a user encounters an error, to go in and do it yourself and really encounter the error. See how that could be frustrating.
Kameron Canbaz : 25:16
The thing that we tried to implement that, I think, is just hard is you know for products and really like to your point. Anyone that needs to be familiar with a product is, when you start or you're on board, having examples that you can do in your product as if you were a real user and really stepping through and ideally stepping through and getting to a point where that would cause frustration, so that you, as a product manager or whomever, can get a sense of what users do on a daily basis. And then I think that just gives you more empathy. And, of course, if not, schedule shadow sessions. So we have countless users who would be more than happy to just let you sit down and watch them do something while they explain to you what they're doing. I think that one makes them feel heard and seen, but two, it gives them some pride and some ownership in the hard work that they're doing. And then our benefit is we get to understand how they're using the products, how they're actually using the product.
Lily Smith: 26:14
Yeah, it's so good. So much good advice there.
Kameron Canbaz : 26:16
I hope so, I hope so.
Lily Smith: 26:19
So we've talked a lot about kind of uncovering these issues and addressing them and you have mentioned a little bit about. You know, the ideal is obviously not to introduce anything in the first place, but how do you make sure that that sort of like standard, I guess, is kept like once you've achieved it, or is there, is there ever an achieving it?
Kameron Canbaz : 26:38
Great question. Yeah, the. It's very, very difficult because I think, you know, even introducing a new process is tough on its own because you really have to get buy-in, and I think the more that you can get people interested in not only what you're trying to do but the result of it, it helps just get people jazzed about doing it. And so I think part of the challenge has been, you know, for us to implement this, like this sort of tracking and this sort of improvement, is just getting people bought in, and I would say we're still working on that. But I think the repetition of talking about our end users' experience and including conversations about, well, how long before the page that they're on is usable Are there any minute errors that they're getting that maybe we used to just brush past because ultimately they're getting their work done and no one's screaming about it, those sorts of things I think when you start to for lack of a better word evangelize this type of thinking of user focused and user centricity, thinking that you inevitably start to address this stuff throughout the product life cycle.
Kameron Canbaz : 27:44
So I would say now we've always been or should you know, always, because I have, you know, four years at Yahoo, but for a long time we have been very user-focused in design phase and then maybe not as holistically focused when we're actually building products.
Kameron Canbaz : 27:59
But that has changed instrumentally over the last several years and what I would say is is like engineering is far more bought in with UX and with product now, and it's much more of a bubble. I think squad is like the new word, but it's a squad of people that are all bought in and with different expertise on the product. That now also include in these questions about performance and error, so that when we're starting to develop stuff, we're bringing in product managers, designers, users earlier to test, so that we're catching these things ahead of time, and then when we introduce it slowly through beta testing into our generally available product, that we have even more clients testing it as well, just so we catch these things ahead of time, Because no one likes coming back six months later having forgotten how they coded something and having to address an error that just seemingly came out of nowhere.
Lily Smith: 28:52
There's no eradicating that like that's probably always going to happen, but we can reduce it significantly by just paying way more attention to our users up front yeah, I also think that one of the things a product manager can do is just like bring this topic, like in conversation, to the rest of the product squad and, you know, to the designers, to the engineers, and make sure that everyone knows that they care about it as well, because I think sometimes there's maybe an assumption that it won't ever get resourced or anything because we don't have time for it, because there's so much other stuff to do. And, yeah, I think, making sure that if you're a product manager, like, you're bringing that to the conversation to say, hey, you know, are we paying attention to this? What's going on? Does anyone have any suggestions of like stuff that we should be doing or should be concentrating on?
Kameron Canbaz : 29:41
Yeah, I mean that's a good point, like I think you're right. A good point Like I think you're right that there's never an end, there's never, there's never an end, it never ends, right, but the I think it's the as you're developing things, you can start to chip away at it, like you don't have to fully resource something like this. You know, generally that should only happen if it becomes like a big issue right.
Kameron Canbaz : 30:01
But I think, like as you notice things throughout the product life cycle, you can just address them one by one, like maybe there's an error on this page and we're developing a new feature for it, let's address it. Or maybe we can speed up the page a little bit because we're building something on it and I think you can chip away at that and just make kind of progress as you go yeah, yeah, definitely awesome.
Lily Smith: 30:22
Well, thank you so much, camera thank you really great to talk to you today.
Kameron Canbaz : 30:25
You as well.
Lily Smith: 30:37
The Product Experience hosts are me, Lily Smith, host by night and chief product officer by day.
Randy Silver: 30:43
And me Randy Silver also host by night, and I spend my days working with product and leadership teams, helping their teams to do amazing work, and our theme music is from product community legend Arnie Kittler's band Pow. Thanks to them for letting us use their track.
