Sandy Huang
===

Emily: [00:00:00] Welcome to LaunchPod, a product management podcast from LogRocket. Today, our guest is Sandy Huang, Vice President of Product Management at GoodRx. Sandy has worked in tech for most of her career, beginning at small startups such as MusicNow, which was later acquired by AOL, as well as Wedding Channel, which was acquired by The Knot.

She then moved on to companies including Shutterfly, Minted, Jive Software, and Flipboard. Before joining GoodRx, Sandy worked at Amazon as head of product where she led the global search and discovery team for Amazon Shopping and led the Alexa team developing experiences and content,

On today's episode, LogRocket CEO and Head of Product, Matt Arbisfeld, talks to Sandy about the importance of alignment in product management, ways to collaborate with stakeholders, from her experiences at Amazon working on projects like Alexa and global search and discovery.

Emily: So here it is, our conversation with Sandy Huang.

Matt: hello everyone. I'm Matt Arbisfeld. I'm the CEO and co founder here at LogRocket and [00:01:00] today super excited to be joined by Sandy Huang, who's the vice president of product management at GoodRx. Thanks so much for joining us today, Sandy.

Sandy: Great to join. Thanks for having me.

Matt: Awesome. Super excited to, to learn more about your experience in products. And I know an area you're particularly passionate about is about creating alignments in product management across stakeholders. So maybe. Just talk to us about what does alignment mean to you? What type of stakeholders do you always bring into the fold?

Just how you think about alignment in general would be great.

Sandy: Sure. So alignment is. It's critical in product management. It is essentially inherent to the function. Product management is very collaborative function, works with a lot of cross functional stakeholders. And the role of a product manager is listening, getting input, synthesizing information developing a point of view on something, whether it's the product strategy, roadmap requirements, goals, success, or something else.

And alignment is just really [00:02:00] essential to moving any project forward. Teams often get stuck when, and lose momentum when they're misaligned or they disagree on a decision and can't move forward. So in product management alignment it's also important to note when I say alignment that I don't mean that everyone has to agree because that's, of course, difficult to do, but that everyone understand what is being put forth and there is a mutual understanding there and it's okay to disagree.

agree to disagree, but you're understanding the problem you're trying to solve. In a case, for example, of a product direction and the stakeholders that product managers need to align with are vast because it is a cross functional role. And that could include your immediate team, your cross functional design engineering, your manager, executive leadership, and executive stakeholders.

Matt: Of those groups. Is there any in [00:03:00] particular you found most important or most challenging to align with?

Sandy: Yeah, definitely aligning with your manager. It is a problem if You have a very different point of view from your manager. So starting with that, but of course, executive stakeholders, if your project needs funding, and needs that green light to move forward and then buy in from the team that's working on the issue itself, so essentially they are all important. But I think number one is aligning with your manager first so that your manager can support you in that initiative going forward.

Matt: That makes sense. And do you have any advice for PMs who, how to present to your manager, how to talk to your manager, and then when they disagree, how to work through those issues? I know that's a common area.

Sandy: Well, Listening is a big part of alignment to understand your manager's point of view. So as you as [00:04:00] a product person assess, You'll have a point of view. Your manager will have a point of view and understanding what that point of view is. So treating your stakeholders as you would as a product manager, treating your customers.

These are your customers, essentially your stakeholders. So that is key to understand. And and one of the things that we can talk about is really getting to the why. Of these points of view or what your conviction is or what your manager's conviction is, if it is very different. So that is the first step,

Matt: Kind of isolating what is the court of assumption that maybe you disagree on that is creating that disagreement. 

Sandy: Right? Cause oftentimes the disagreement feels like you're disagreeing on one thing, but actually if you dig in deeper, it is behind meeting a certain goal or different assumptions in terms of the metrics of success or misalignment between teams of what [00:05:00] is important. So that's why the understanding the why is really critical.

Matt: What does understanding the why look like? Is that kind of the why from a business perspective or how do you get, what do you mean when you say understanding the why?

There's a number of things in terms of understanding the why. One element is that I often see that blocks teams is that there are different assumptions as to what the, what success looks like in the initiative. And and success is defined differently with different people. So getting on the same page.

Sandy: For what that looks like. And in order to do that, there's all has to be work done on where the North star is where are you taking this project? And sometimes the North star, different people have different assumptions in their head. So unless it is articulated, put down on paper, put down in a PowerPoint it's easy to just think that, Oh everyone else is thinking the [00:06:00] same thing.

Matt: If you're basing your thoughts on opinions, it's hard to agree on something, but if there's a kind of core North star that's measurable and customer focused these decisions become a lot clearer.

So love that. we'd love to go more into your experience.

So I know you previously worked on Amazon on the Alexa team. Maybe you could talk about what you worked on there and then how you went about evangelizing your ideas and building consensus in such a large organization.

Sandy: Sure. So when I joined Amazon, I joined at a time where I joined on the Alexa side of the business. So Alexa was introduced with devices that don't have screens. And and a lot of the interactions were about talking to the device. Talking to Alexa, getting feedback and going back and forth. And especially in early days, users don't know what to say.

And there's a lot of trial and error because they're the technology was not as developed. So [00:07:00] there was a lot of back and forth. And a big issue was what do you say? The teams at Alexa would send out emails. That would explain, here are the different things you can say to Alexa, and just give people ideas which are great, but it's not within context, right?

You're getting an email, and separately, when you're talking to Alexa on the device it's a different, you're at different times, usually. So Amazon introduced this Echo Show that has device with a screen and one of the fundamental user problems identified was just that, people don't know what to say.

And and so this was the start of what can we do with this screen. Now, in the beginning, people put their photos on the screen or you could have nice screensavers and it's great and you can think of a world where you have this, essentially a photo screen that you can talk to and ask [00:08:00] questions, but how about we use that as a way to help people.

Because now you have something visual to look at. So the work that I did and my team did was to essentially leverage the Echo Show device as a way to discover content. And the nice thing about a screen is that it's visual. So you can put a lot of keys there. You can put a lot of interesting images and things to engage the user on.

So that really was the start of that part of the business. But it was challenging because the company and the organization was deeply rooted in, interactions via voice. So introducing a new paradigm of touch becomes a much more important part of the equation when you have a screen right in front of you that you can touch.

And so a lot of the work early on, even to just align the different teams is to say well, we need [00:09:00] a new metric of measurement. If for the success of this program, if we only. monitor and determine the success by a voice that is not going to be effective and we won't get this program off the ground.

So that was critical in early days to establish that. 

Matt: What was the metric you tracked?

Sandy: in terms of engagement, the voice engagement was about voice interactions. the number of voice interactions. When it comes to touch, it's the same thing. It's engagement, but it's touch engagement. But with a screen, you have both. And it was interesting to see how that dynamic changed when we started launching content on the device and what that split was.

And depending on the size of the device, too, and how the device is used some of the devices were, people were using more as a communal device, for example, in [00:10:00] the living room where the family's using it, or more individual, it's in someone's bedroom.

Matt: . And so the more people interacted with the device, the better engagement was, and that was, that's how you measured success.

Sandy: And it was just important to say, hey, we are looking at engagement in general. It really doesn't matter if it's, Voice or touch. The intent behind it is that people are engaging. And that was one of the big hurdles because teams that I was working with had already set their goals and they were based on voice interactions.

That's asking the teams to reset it and rethink across the board, across the organization. And while at Amazon, it is a whole process to really lock those goals every year. It was critical because of the spirit behind it. 

Matt: In some ways, having voice interactions go down meant the product was successful.

So, yeah, that's a change.

Sandy: That's right.

Matt: and then next [00:11:00] you moved on to global visual search and discovery. Maybe you could share more what that is and what are some of the products you worked on there.

Sandy: Sure, so the Amazon Global Search and Discovery was a team or is a team on Amazon that focuses on image search. So if you go to the Amazon shopping app and you look in the search bar, there's a camera icon that you can tap and you'll see the full experience in there. So we have experiences in there and they're also integrated throughout Amazon and actually off Amazon.

So the premise behind this is that text search, which works for many people, there are certain queries where you would want as a user to use an image. For example things that are more inspirational. You see a nice patterned shirt elsewhere on the web and you want to take a screenshot of it and put it [00:12:00] into Amazon search.

So that inspiration really comes from anywhere and it's hard to describe. Some things are hard to describe. If you're looking at, for example, a living room set, if you were to type it in, it would be this long query. It's easier to just show what you want to see and return. It's interesting because It's either you can get to a specific thing that you want or the entry and the image is about something that you like and you want to see more of just as inspirational shopping.

So that was the premise of visual search and why don't. While I was there, we launched two new features, which is multi modal search and and find on Amazon and actually more like this, which is another feature, but essentially multi modal search is combining the image with text because sometimes you put an [00:13:00] image in there.

And, oh, you want that, but you want it in a certain brand, or you want that in a certain color. And that way you can specify. And the notion here is multi modal, very much like my work at, on the Alexa side of things, is that users want to engage their, what they're looking for is the result, how they go about doing it, whether it is through an image or voice or text is dependent on the preferences of the user is dependent on what device they're using.

And it's also dependent on. what best fits the case. So I was saying about the inspirational or just hard to describe. It's great to use images, but if you're looking for something very simple, like I need a mouse, then you can probably just use text and it's a lot easier. I actually have a great [00:14:00] example when I was on the team and I had a a light bulb in my closet go out and it was the weirdest looking light bulb.

There was no way I could describe this weirdly shaped light bulb. I didn't know what it was called. I knew that if I typed it into search and search for light bulb, I would get thousands of returns that, Weren't it? And I noticed there was a model number as well. I was like, okay, I can type that, but it's a very long number and I might get something wrong.

So I just took a picture of it and it just showed up. It was the first search return. It was so easy.

15 seconds. I was done.

Matt: I'll have something break in the house and be in Home Depot for hours, trying to find the part. So now I know

Sandy: Now, now, yeah. And so that so that was one of the features. One of the, another feature is find on Amazon. So as I was saying earlier, you could be looking on Tik TOK or Instagram and see something interesting there and want to find something that looks like that.[00:15:00] 

similar. And because Amazon has such a big catalog, it's easy to go from that image and share it to Amazon. And it automatically puts it into the visual search and you can find a similar thing. So that was another area that we innovated on.

Matt: and this was before the whole AI wave. I'd be curious now, almost everyone I know who's working has a search experience is rethinking that in this world of generative AI and multimedia search, how do you measure results of that compared to the sort of typical search and filtering and weigh those two paths for users.

Sandy: Yeah, certainly the search results, there are quantitative ways you can then also having a human eye, right? Where technically, yes, the return is returning something that is valid, but where does it rank on the search returns, but also what's the quality of it. And that's, what's difficult is the quality of it.

and in terms of [00:16:00] text search for many years, when you look at the quality of it, or certainly the early days of image search, you have to have human that are trained to understand is this actually the right quality? And that takes a lot of human training because you have to calibrate because people are thinking that the people who are annotating and evaluating are thinking different things.

So with A. I. and M. L. and retraining and using A. I. to retrain so you can give feedback that should get easier and easier. And so that also, when we're talking about things like Fashion and looking at images and fashion. Then you're talking about looking at the training data and making sure that it is fair to get the results that you want and not biased and all that.

So it will just continue to get better and faster and less human intensive involvement which is great for the [00:17:00] user.

Matt: Definitely. It's so important to always have the human involved in the beginning to be evaluating the results and make sure it's aligned. 

So, Yeah, really exciting projects at Amazon. And then now you're at good RX, which is much smaller at, I'd assume. Maybe would love to learn of how you handle.

Alignment and team alignment in a smaller company like good RX versus Amazon, which obviously much bigger.

Sandy: yeah. I find that the size of a company doesn't typically matter as much as the number of stakeholders that you have either on the team or that have to weigh in on the decision. So, For example, at Amazon, the ownership can be widely distributed, whereas a team can develop an idea. And get stakeholders, immediate stakeholders, which usually involves um, Amazon has a very specific process.

It's the working backwards [00:18:00] six page narrative process that usually starts with the PM writing that documentation. And in that process, you're bringing in the various stakeholders, your first. iterating it with your immediate team. So your cross functional, the designer and engineer, and then taking it broader to the stakeholders, eventually to whoever will be the one who greenlights the project.

So it gives it an okay. So that process of Amazon has made um, Amazon a way to, to do and innovate at scale rapidly. At a smaller company again, unless it's a very small company, like a 10 person startup where you can literally just, talk to the person on your left and your right and that's it.

At a smaller company, it really depends on the structure. It depends on how many approvers there are. Of course, the more stakeholders there are in that approval process, the more aligning there is. So it's not so much about [00:19:00] the size per se, to, to some limit but it's about just how many people you do need to engage in the decision making. 

Matt: And hopefully even if it's a big company, you don't need approval from. All 10 product VPs to get or else that's a, that's an issue. Have you implemented something like the Amazon memo process at good RX or any, yeah, any sort of process you brought in when you joined?

Sandy: Yeah. One of the things I took away from Amazon is that I really appreciated that process for two reasons. One, that it is It's extremely collaborative because you are bringing a lot of cross functional stakeholders to the table at the discovery phase. at the inception of a project. So that is, that was great.

And then the other thing is that the process helps to eliminate unnecessary churn downstream. So if the alignment in the beginning is not done, sometimes it crops up when you're already in [00:20:00] development and that's when teams churn and say, Oh, actually we were going to We thought we were going to focus on this thing.

We have executive leadership that thought they were going to focus on, , something. And that results in different product requirements. So then you're going back to the drawing board and saying, okay, we have to rethink the product requirements. We have to redo the design. We have to do reduce some of the development.

So that was some of the thinking I wanted to take to good RX. And of course, good RX is a a much smaller company compared to Amazon. So the important thing is to right size it. At Amazon, this process, especially for brand new initiatives where you're going from zero to one can take months and months at a smaller company it's too heavy handed.

I brought an abridged version to GoodRx, which is taking the same spirit of it. And right sizing it for the number of people that we have, the number of [00:21:00] stakeholders that we have to make sure that we are moving quickly with with velocity, balancing because there's no, There's not an opportunity at smaller companies to do this for months and months on end.

So the right sizing is important.

Matt: And can you share the kind of spark notes version of that? Is it like a shorter written document or what's that process look like?

Sandy: Yeah. So specifically it's a one to three page document with guidelines of doing it within four weeks or less. And depending on the size of the project I piloted it with the team last half. and without saying that we need to do this process just to see how it goes so that I can get feedback and amend it.

And so this half where we're doing more of that and and getting great feedback on it. And then, it, it is an evolving document, especially in the beginning, because you want to make sure it is, [00:22:00] enough process to give structure, but not so much that it is taking away from velocity.

I, I think the most difficult hurdle is that when people think of, Oh, we'll spend more time in discovery. And at the beginning of the project there's an automatic assumption that, Oh, now we're adding process is, are things going to take longer? So there's a bit of. Trust that is needed to say, Hey, we're going to try this out so that we can actually see what the velocity gains are.

There's a bit of a leap of faith there.

Matt: And sometimes you have to move slow in the beginning to move fast later to your earlier.

Sandy: Exactly. Because once the alignment is there, I can tell you it's so much easier to write the product requirements. Because as you're writing the product requirements, if you're not doing this in the beginning, you're spending the time during the requirements process to figure this out. The problem is at that point you're already writing the requirements.[00:23:00] 

And so those assumptions are Maybe in the product manager's head, but not explicitly written out.

Matt: Yeah. And then you don't have some other executive swooping in at the ends, not having known about the project. Did you say the four to six weeks is basically how long? The long, yeah, what is the four to six weeks in that framework that you mentioned?

Sandy: So it's a product alignment mechanism that I've amended for the company. And that is a general, the four weeks is a general timeframe guideline. As to how long it would get from starting the document to getting the alignment to the final. Great, thumbs up, we're aligned on this. And it doesn't mean that it takes four weeks to write that, it's baking in the time of.

The meetings the various meetings with your stakeholders working from the core of your core team on out depending on the number of stakeholders and how big the [00:24:00] initiative is really. So that's been the guideline.

Matt: And does that document have designs of the product or what is the sort of scope of a document like that typically?

Sandy: It doesn't typically have designs the product. I think there are some initiatives where It is easier to get some early thinking from design and maybe some early wireframes just to help that process along. But this process is also done with design as your stakeholder. So whether or not it is in there it may be too early because you're still talking about things like, what is the North Star?

Why are we building this? And why do we need to build it now? What are the gaps that we're that we see in this? Asking questions like, how can this thing fail? What are the user needs? So basic questions like that. So it is still a step back from actual design.

Matt: Makes sense. And I think the interesting thing I found [00:25:00] is even over those four weeks, maybe our brains just evolve and we're sleeping on it and we learn something new or you talk to customers. So you actually learn a lot, even if. You think, on the day one, what the product should be. You learn so much just by taking a breath before you dive into a project.

So

Sandy: Oh, absolutely. I think when you look at it week one versus when you look at it three week three, and if you have some time in between a few days where you don't look at it, which is also important, you come back with a fresh perspective. 'cause the idea behind it and the reason to involve all the stakeholders is that you have different perspectives on it.

That's the point of it. It's important to debate topics. And have the debates and the decisions made from those topics now versus later when you're deeply engrossed in the product and want to move quickly forward. So that's critical too.

Matt: I feel like there should be a life rule or [00:26:00] something. Don't make any big decisions in less than four weeks. You don't buy a house without thinking about it and under a day. So why should you

Sandy: Yeah. Yeah. Yeah. And I always tell my team that the most, one of the things. Signs of success that I see with a great product alignment doc is that I read it and I don't have questions. I don't have questions like have you thought about this? This doesn't mean that the document answers everything.

You can't possibly have answers to everything, but you can say, we've thought about this. We know this as a whole, we know this is something we need to get back to, but we've identified it. And that's 

Matt: Love that. Super helpful and actionable. So yeah, thanks so much for the time today, Sandy. Maybe if you want to share with the audience, where can they find you? LinkedIn, Twitter any,

Sandy: you could just search for my name 

Matt: Awesome. Thanks so much for coming on today. Really great conversation.

Sandy: Thanks so [00:27:00] much. It was fun being on the podcast.