 Awesome. Hi, everyone. Welcome to this week's product school talk. I'm Cassandra. This week, we have a very special guest with us. His name is George Perrantados. He's the product manager over at Redfin and he started off at Microsoft. Hi, George. How are you doing today? Doing well. How are you? Great. I'm really happy to have you with us today. Happy to be here. Awesome. Well, I know you have a presentation. So if you want to start screen sharing, I'll let you get started with that. And guys, as most of you know, we'll be taking questions following his presentation. So you can type those into the comment section underneath the video whenever he's done. Looks like we're set to go, so I will let you take it from here. All right. Thank you. And thanks, everyone, for joining me today. I've got a few things I want to talk to you about on one topic, which is how to make hard decisions as a product manager. First, a little bit about myself. I started my career quite a while ago at Microsoft. I've done enterprise software in SharePoint. I've done incubations at Microsoft as well in office labs, entertainment software and gaming and Xbox, built devices at Amazon. And right now I'm a lead product manager at Redfin where I work on the listings team, the listings product. And so just a little bit more about what I do. Redfin is a tech-powered real estate brokerage. We help people buy and sell homes. And I work on the selling part of that. So we help our sellers and our Redfin agents make the experience of selling a home which can be really stressful, really efficient, really easy and amazing. That includes promoting the sellers' home online, giving them some cool technology like 3D walkthroughs so people can see their home without necessarily visiting it and also giving sellers a dashboard where they can watch the whole process and what's going on. But something you all probably don't see and something I'll talk to you about first is some tools we built for real estate agents, customer relationship management tools and other tools to help them be productive as well. That's certainly another part of Redfin. So making hard decisions. There's a lot of them in the world of product management. I'll just touch on a few of them. The first hard decision I want to talk about is taking on incumbents. You may have an idea about a new product, a new company even that you want to start or make and let's say there's a Facebook or an Amazon or an Uber or a company of that size or caliber already in that space doing pretty well and maybe the question you're asking is, should I go for it? Should I build that product? Should I start that company? Well, I didn't build a product or start a company necessarily that was going to take on Facebook but I had this problem recently and this question to answer within Redfin. And it was this product that we called the CMA. It's not a shipping container ship as I show here. It stands for Comparative Market Analysis and what that is is as follows. So let's say you want to sell your home and you talk to a real estate agent and you say agent, how much is my home worth? Well, what that agent does is they look around other homes near yours, see how much they sold for and try to figure that out by analyzing the prices and all the other statistics. So agents who work with sellers do this day in and day out and they put together these reports and they meet with sellers to talk about what their home should be listed at. And what you list your home at is a really important number because if you list way high, nobody comes to check it out and if you underpriced it, people may wonder, is there anything wrong with it? And so from an agent standpoint, what the question we were trying to answer is, can we replace effectively something like Microsoft Word for them? Something that people use almost every day, several times a week. And it's like as core to their work and their business as Word is for a product manager or anybody else that's an information worker. And we thought, yes, and here's why. First we said, those reports, by the way, they look like this. They're really ugly, chock full of numbers but they're really hard to understand. Two, they take a lot of manual work. It's an empty vessel. You have to find all the homes, figure out the right ones and add them. And third, there's no unique content. Everybody has the exact same data. It's just crunching it slightly differently. There's nothing to differentiate this analysis for a Redfin agent versus anybody else. And so we said, we think we can make something different and something better. And we did. Our product was beautiful. It automatically suggested homes for agents to put in and it had data no one else had because we have this big website where we can watch and see what buyers are doing in which houses they seem to be gravitating towards or not. So you may be wondering, well, did we succeed? I will say not right out of the gate. This is our adoption numbers by agents when we launched the feature. We started about 50-50. So we kept talking to agents and listening to feedback and iterating and adding improvements that they told us they really needed. And eventually we got to almost all the agents. And I will say now at this point, this is about a year old. We're pretty much at every agent at Redfin who works with sellers using this product. And this is what I live for. Not the numbers, but the stories. Agents, these are direct quotes. Agents saying, I love this tool. I'm amazed by what you all built. It's very eye appealing. So at the beginning, we didn't know if we were gonna succeed. But we thought we had an edge. So if you're thinking about, gosh, should I take on that incumbent product or company? Figure out, do you have an edge? Is there something really special about you? Can you build something amazing? And that should hopefully lead you to the right answer. All right, question number two or hard decision number two, taking on a new job. So here's my story on that. You saw Microsoft free times earlier in that slide. I was at Microsoft for 12 years. Some of you may be wondering, this is a long time, George. And I will agree that was a long time. Three jobs then, but still a long time. And after 12 years, I said, I wanna try something new. I wanna learn new things. I wanna try building some products in a different place. And I knew some people at this company down the road called Amazon, here in Seattle. And they're working on something, but it was a secret project. They wouldn't tell me. They couldn't tell me. In fact, I would have to sign that I was accepting my offer at Amazon before I found out exactly what the product was, which sounds crazy in hindsight. And it is a little crazy. So of course, my mind was racing. Like what product could this be? Like, is this some random transparent toaster? You know, is it a weird like iPad potty thing? I have young kids at the time. So like, what's, you know, is it that? I mean, is it a giant mecha robot? By the way, this is not a Photoshop. That is actually Jeff Bezos in a giant mecha robot. I don't know what that is, but that is real. So it's none of those things. So I signed on the dotted line. I joined in my first day. My manager said, we're working on the fire phone. You may be groaning now. Oh my gosh, George, fire phone. Wasn't that a business flop? Like, wasn't that a failure? Well, it was not a business success. But remember what I said? I said I was going somewhere where I wanted to learn and do some different things. And in that frame of mind, I had a successful time at Amazon because I learned a ton. Shipping a phone is extremely hard. There were dozens of teams involved. It's hardware, software and services. It's a massive rally across the company. Ton of exec meetings. Like I'd never shipped a product like that before and worked on a product like that before. And I specifically owned the beta program. And this is probably one of the hardest beta programs I've ever run because it was a secret project. So I couldn't just like toss it out to the world. I had to work with only certain people that were disclosed. Most of them were inside the company and somehow motivate them to give me great feedback. So I got out of what I wanted from this job, regardless of the success or failure of the fire phone. And Amazon did too. Do you know Alexa? Well, the first product that tested Alexa was actually the fire phone before this product ever shipped called the Echo. And if you've heard about Amazon Go, this cashier-less convenience store in Seattle, the people that built the cameras for the fire phone were the same people that built the cameras on the sensors for the Amazon Go store and the same camera that is the Amazon key. So for Amazon, it was a success too. It wasn't a complete failure. There's a lot of technology that came out of the fire phone that Amazon was able to harness. So if you're contemplating a new job or a new role, the questions I would say you need to ask yourself is what will you learn and what will you get out of that experience? And who are you gonna get to work on this product? And finally, what's the worst that could happen? Because a lot of good I think can happen. So ask those questions of yourselves if you're contemplating a new job and hopefully it'll lead you to the right path. Okay, so last question or last hard decision is saying no. Saying no is hard. I mentioned that comparative market analysis tool. So generally Redfin Agents give us a ton of feedback online and in person. And that CMA tool I mentioned that countless amounts of feedback I've come in about that tool. So I just mentioned it was a success, right? Well, there's a ton of feedback on it. Agents want us to make it better. And here's the challenge. The challenge is we could hire an army of engineers to address all the feedback and we still wouldn't be through with addressing all the feedback. Because it's never ending. We could always make it better. And meanwhile, there's other things we can do that are brand new. For example, a year ago, Redfin announced, we're doing a mortgage product and we started helping customers with mortgages and about six months ago we announced, hey, we have this product called Redfin Now or instead of you listing your home with an agent, you could sell it to us directly and avoid all the hassle of cleaning and staging and things like that. So there's this tension. Do I put the blinders on and just focus on my current product and make it great? Or do I ignore customers and focus on new products and ignore my current products? Well, of course it's no extreme. It's somewhere in the middle. And the question is, well, how do you strike the balance? And I really have one answer to that which is customer empathy. At Redfin, we can shadow our agents, we can watch them work, we can do online user testing in-person focus groups with buyers and sellers on our website. And I've found no other way besides watching people work, hearing their concerns, their wishes, their pains to decide where to set the balance. Because only when you see something, you feel it, then you can prioritize whether it's a mild annoyance or a really severe problem to set that balance. So if you want to say no to a customer, first figure out, have you addressed the big pains with your product? Also, what is the next big opportunity you're trading off against? In that last comment, 5% for art, always save a little bit of time to keep a product fresh and address the top pain point, however small that may be. Don't let it die on the vine. All right. Those are my three hard decisions. I want to close with one personal story which is a topic or a theme of big opportunities. So you may see my last name. It's a long name. It's Parentados. It's Greek. I was born in Greece. I was born in Athens. And I'm not there. I'm here. And I don't have an accent. You may have noticed. And that's because my parents and my sister and I moved to the States when I was five years old. We followed our uncle who had settled after attending school somewhere in Georgia to this little town in Northwest Georgia named Dalton, Georgia, which is known for carpet, Marla Maples and Deborah Norville and not much else. So you may be wondering why the heck did your parents move from this big metropolitan city, cradle of democracy, et cetera, et cetera to this small town in Northwest Georgia? And the answer was opportunity. It was opportunity for themselves and for their children, myself and my older sister in terms of education and jobs and all the things that led me to where I am today. So you're gonna encounter these big opportunities in your career, in your life. I just wanted to leave you with a few tips there, which is make sure you're running to and not from an opportunity. My parents at the time were actually not running away from Greece. Greece economically was great then. It is not so great now. But their friends said, you are crazy to leave Greece when they left in the 80s. But they were running to something. And I recommend anything you do with your product, with your career, run to something. Also, remember it's about the journey, that learning and growing piece for Amazon. I did not regret one minute of my time at Amazon because I was learning and growing every day my time there. And finally, there's no regrets. You can't explore every single possible opportunity out there, but remember, you can always make a change. So don't regret where you are and if you don't like it, you can always make a change. So I always try to bias on making a leap as long as you're heading somewhere you think is gonna be amazing. So that is what I had. This is my contact info. I'd love for you all to reach out. If you have thoughts, if you wanna get in touch. But I think right now, we're gonna do some questions. So I'll hand it off. Awesome, thanks George for a great presentation. And thanks everyone for joining us. Make sure you're typing in your questions there. We'll get to them. Really interesting stories. And I know you mentioned you were at Microsoft for 12 years. Can you talk a little bit more about how you landed your very first role as a product manager there? Yeah, good question. So I went to Georgia Tech. I have a CS degree. And I was trying to decide between product management and engineering. So I did one product management internship and I did one dev internship around my like end of my junior through my senior year. And I didn't have any product experience before. And the way I landed that product internship was I talked to recruiters and I expressed my interest in talking to customers, figuring out what to build, all the characteristics and the skills I think that make a good product manager and they took a bet on me. And if Microsoft would have said no, I would have pursued another company that would have said yes. Awesome, thanks. And let's see, have a couple of questions coming through here. This one came in from Slack. Can you talk more about what skills have helped you be successful as a product manager? Sure, there's a few. One is synthesizing information. As a product manager, you get information from a ton of sources. You get information from customers, from competitors. If you're in a company from executives, figuring out an answer from all those sources of information, being able to distill it down into like here's the three things we need to focus on and then leading your team as a result of that. I think it's really important. The second is really clear communication. That's the next step. You can communicate to an investor or an executive or just your fellow developer about why we're doing what we're doing. I think really having a knack for understanding what customers want is important, not just hearing what they say, but digging in below the surface and understanding why are they doing what they're doing or saying what they're saying. What are they really trying to achieve? They may be proposing a solution when in fact the problem may be something unrelated. And finally, there's many more, but the final one that comes to mind is being scrappy. As a product manager, figuring out how to get things done is really important, not just through others, through developers and designers and others that you work with on a team, but also unblocking yourself. How do you, if you wanna do something, do you go and get a tool to do it off the shelf? Do you build something? Do you talk to someone who's an expert? Do you find someone online to just have a coffee with for 15 minutes that knows more about the space than you do? There's a correlation between I think product management and entrepreneurship in that both roles, I think require startup founder or a product manager require a certain level of scrappiness to just keep yourself unblocked and keep moving forward. Right, definitely. It's definitely about continuing. It's being a lifelong learner too, right? Awesome. So our next question is from Igor. What are the biggest challenges you face when you worked for Amazon? Biggest challenges, that's an interesting question. I'll say to the following. Amazon's strength and also weakness is its risk taking. It can turn on a dime, which is impressive given the size of the company and say we are gonna do this or we're not gonna do that. We're gonna change course. The challenging thing for me was when I got really invested in a project that was actually after the fire phone I didn't talk about. I was at Amazon for two years, I worked on the fire phone for a year and I worked on some other stuff that didn't ship for a year. I think Amazon made the right call to change course on the stuff I was working on but I got so invested in what I was working on. It was hard to say, oh, it's been four months, five months, I need to pause on this and work on something else. So it's the, in hindsight, I think it was the right decision, but when you're in it, it's sometimes hard to kind of change course when you're personally invested in the product you're trying to build. You've heard all the customer stories, et cetera. And that's maybe another skill to add to the list, which is you can't get too attached, you have to do what's right for the customer, right for the business. Sometimes if you're too personally invested, you may go too far down a course you shouldn't from a business strategy product perspective. That's a really good point. Here, our next question, we have actually quite a few coming in. So let's see, our next question is from Katie. Do you publicly post roadmaps or commit to feature rollout schedules? And if so, how much do you disclose ahead of time? We also, yes, if you take the word public and assume kind of within the scope of Redfin in my case, I've never posted something outside of the company, mainly from a confidentiality standpoint, it would be a competitive advantage if somebody knew exactly what we were building when. We usually let our PR team handle what we talk about publicly. But in terms of like within the company, yeah, Redfin has two kind of patterns that I find really good. One is we have this annual strategy team process where different people from different disciplines get together and figure out, what are we gonna do for the website or our agents or this particular business problem? And they lay out a roadmap for the year. And then every quarter, teams like mine get together and figure out what are we gonna shoot for next quarter? Like what metrics are we trying to drive and what products do we think we'll build? And both of those are public to the company. Anybody can go read that document or that strategy document or read the quarterly plan and comment on it. We use Google Docs and we do a short kind of exec review for that quarterly thing and a longer one for the yearly thing. So we're from a value standpoint, we're a very kind of transparent company, not just with our customers, but within ourselves. And I think that's good because ideas can come from anywhere and people have different perspectives, especially diverse perspectives. And it's good to make sure it's not just blinders on, let's go. So that's the process we use it for and I found it's pretty good. It's awesome. Our next question, excuse me, it's from David. How do you prioritize your backlog? Yeah, good question. So as I mentioned, we set up a plan for what are we gonna do next quarter? Once we have that plan, we prioritize based on if something has more or less urgency, like an agent is like screaming for this tool or this is like the most important problem to solve or there's another team depending on something we need to ship to unblock them. So we kind of lay out our quarter roughly and then that's what prioritizes essentially the backlog. But that's really a guidepost. That's not a fixed plan. We do, like many companies we have our own kind of modified version of Agile that we use, but we are in principle Agile and that we can change the plan. If something surprises us and sometimes it does, some issue arises in production or some new request comes in that is the more urgent. So we have regular, we have like weekly meetings are pretty short to kind of scrub the backlog and give daily standups to make sure everyone's unblocked. So, but I found personally that having a little bit more than one or two weeks of projection of what the team is gonna do is useful because it helps us roughly understand what we think we're gonna get done. What I found sometimes in Agile and Scrum teams is if you stay too focused on one week or two weeks you miss the kind of the where you're headed or you don't quite know how far down the roadmap you'll get, which in some situations that's fine. In my situation, we do need to have a little bit of predictability for one reason. One reason is we're building tools for agents and agents think of that more as like an enterprise software thing where you can't change the software like every day on them. So it's like word or Slack changing on you every day. Like it can be problematic. And so we need to be a little bit more predictable about when we think we'll ship things. The website feature teams do move more on a, yeah, let's start testing this today. Let's AB test this tomorrow. Okay, awesome, great. Let's see, our next question is from Daryl. What are some pitfalls that a highly effective product manager should avoid at all costs? That's a great question. One pitfall is don't assume you have a rock solid understanding of the customer forever. If you spend three months researching a particular customer segment at length, you do site visits, you travel the world, whatever. You say, I know this customer. That's probably true for three months, six months, a year. But depending on the customer segment, that information will decay. So at some point, if you do no more customer visits, customer research, customer outreach, you will not know the customer. So it's not a one and done. It's a marathon out of sprint on the customer side. That's probably my top one. Let me think if I have another one. I guess the other one is more of a business strategy one which is, and this is hard, which is when you're on a particular course, you're like, this is my strategy. This is my roadmap. This is the product I want to ship, not being open to change. And this echoes earlier with what I mentioned, but this could be more of a business problem too, if there's like a new competitor that arises that maybe is trying to disrupt the entire industry in a way you didn't expect. I think as a product manager from a feature to a product to even a company scale, you always need to be open to change and be objective to what the right decision is at any point in time. So the course you're on now is not set in stone and should never be set in stone. Awesome, really good point. And our next question is from Pranav. If your team has a dependency on another team to build a feature and let's say it's blocking your own team, how do you manage that situation? Yeah, I'll answer that by saying there's probably one more pitfall to avoid, which is not being paranoid enough. I think product managers are naturally both curious and paranoid. I don't know what it is, but I think you need, if you have this dependency, you need to be on top of it as a product manager. You need to create a system, a framework to manage it. And that's not necessarily a meeting every day or an email every hour, but some way to check in on how things are going, keeping things unblocked if they're great, but providing the help that's needed or the decisions that are needed if it's not. So usually the wrong answer is, oh, I'll assume that product will be ready in a month for me to, or that API or whatever, for me to depend on. Great, see you in a month. The other extreme of I'll call you every hour to check is obviously not right either. But the specific framework, I think depends on the company or the organization you're in. In general, what I try to do is rather than worry about the individual, like how often am I gonna check in? It's setting up a framework. Is it a weekly meeting? Is it a Slack channel and a reminder? Is it, you need to figure that out. And I would say that the more paranoid you are or the more mission critical it is, usually the more okay it is to have a more frequent check-in period. But maybe really the ultimate answer is, you need to check in at a good pace so you can respond if there's a problem. You can't, that's been the best, really the best solution I've had to that problem. Awesome, thanks. And say, I have quite a few more questions. Sure. I'm scrolling through here. This one's from Sagar. As a student pivoting from software engineering to product management, what builds credibility for hiring managers? Yeah. Side projects, startup weekends, blog posts, anything that demonstrates you're thinking about what customers want, the look and feel of a product, what's important and what's not. I think builds credibility. An internship, a product internship would as well, but I know not everyone has that and still wants to be in a product role. The other would be, hey, I'm an engineer in my role right now or I have an engineering background, but I'm looking to take product-like work off of other people's plates in my current organization or company. And so it's like, oh, I was the engineer, but I worked on this feature I was really passionate about and I actually wrote this back or I figured out, I used Balsamic and kind of sketched it out. We actually had an example of a developer here at Redfin just last week who did that. And I mean, this person doesn't want to be a product manager. He just stepped up and said, we need to solve this problem and I'll do it. That speaks volumes from a hiring manager perspective. It doesn't have to be a formal role. It can be an informal yet demonstrated. Oh, this person's doing product-like work. And we have time for one more question. This next one is from Hyun. What are some things that you do to continue learning and improving your product skills? Yeah, it's a great question. I've been at it for a while, but lifelong learning is definitely high on my list. I read books and I get book recommendations from people I trust. I have mentors, those people I trust, who are more experienced than I am and I meet regularly. That's some of them are within the company, some of them are not. I do some online reading as well. And then also by having a team, by managing people and by being a mentor to others, it helps me kind of stay plugged in and hear both what people are struggling with or need help with, as well as kind of what's new in the industry to make sure I'm not missing something, not just technically that I need to understand, but also a pattern, be it agile or whatever else. So those are the techniques I follow. Awesome, thank you. Well, we appreciate you again for being here with us today and sharing presentation, taking time to get to all those questions. Yeah, you're welcome. It was fun. Awesome. Well, before we let you go, I'd love for you to share your advice for aspiring product managers out there. Great question. My advice is be scrappy and hustle. Product management is not a very kind of traditional role. There's people from many different backgrounds that do it. If you're passionate about it, keep networking, keep practicing your skills, keep trying to find opportunities to demonstrate those skills, and you're gonna land the position you want in no time. Awesome, thank you again. George, I appreciate you being here and thanks to everyone for joining us today. As you guys know, you can learn more about us at productschool.com and have a great day. Everyone, bye. Bye-bye.