Hà Phan is the Director of Discovery for Pluralsight, an e-learning platform. Before becoming a product leader, she was a principal UX designer at GoPro. In this conversation, we discuss Hà’s journey from UX design to product leadership.

Show notes

Show notes include Amazon affiliate links. We get a small commission for purchases made through these links.

If you're enjoying the show, please rate or review us in Apple's podcast directory:
https://podcasts.apple.com/us/podcast/the-informed-life/id1450117117?itsct=podcast_box&itscg=30200

This episode's transcript was produced by an AI. If you notice any errors, please get in touch.

Read the transcript

Jorge: Hà, welcome to the show.

Hà: Thanks Jorge, for having me. I'm glad to virtually meet you at the last.

Jorge: Oh, I'm very excited to meet you as well. For folks who might not know you, can you please tell us about yourself?

About Hà

Hà: Yeah. So, professionally, I work for Pluralsight. I am the Director of Discovery, for our Discovery Products. I view that as a platform and we basically solve problems like search, browse, recommendations, and wayfinding. And the reason why I say it's a platform is because, we build capabilities and infrastructure to enable teams to do other things. And on our team, we have a real mix of machine learning engineers, data scientists, software engineers, product managers, and designers.

Also, everything we build is on top of what I call a data structure. And that's why I joined Pluralsight. That's why I picked search as the first problem to solve, because I view it as the ultimate information architecture problem. Actually, when they interviewed me at Pluralsight, they asked me, "you came from GoPro, you worked at all these cool machine learning, computer vision problems... Why do you want to come work for us? You know, we're just building this website." And I said, "I see the main problem being information architecture problems." And I didn't know at that time how true that was until I worked on search. Anyway, that's a little bit about what I do professionally.

Personally, I'm quite a boring person. I don't do much. I live in a beach town in Southern California, and right now we're in a pandemic, so daily I take walks to the beach and I walk on the trail and I do a lot of thinking, on my walks. So, yeah. So that's a little bit about me.

Back to Pluralsight quickly... just so people don't know what Pluralsight is. Pluralsight is an e-learning platform for technologists. When I first joined Pluralsight, the pervasive product story is that we enable anyone to be able to reinvent themselves through learning and technology. There are always these stories around, you know, people who re-skill to get a better job in tech. That was a story I heard very often when I joined Pluralsight. But as we scale as a business and as a platform, we move more into the B2B space. Right now, I think the pervasive product story is that we help enterprises upscale their workforce and enable them to meet their business goals through that. That's a very broad stroke about what Pluralsight is.

A broader remit

Jorge: I'm going to try to reflect back to you the journey as I see it: you went from a UX design role at GoPro to this role at Pluralsight, which sounds to me like it has a broader mandate than just UX design. I mean, just from the roles: you said that you have machine learning folks and data scientists alongside with designers. And I'm wondering if you can share with us insights as to the differences between UX design roles and roles that require a broader perspective.

Hà: I think as a UX designer, we tend to think broad already, right? When you start to think about new innovation or new problems to solve, UX is the practice of building these visions and then bringing them to life. UX is a way of providing clarity for the rest of the organization to find their mission and their vision. So, as UX designers, we already have that in our DNA.

I think the difficulty was between the role I have now, or the delta between the role I have now versus being a UX designer is that, you know, it's really a leadership role to basically provide the path to clarity. When you have a vision, even as a seasoned UX designer, you're going to present forth this vision. And usually there's a thousand questions and a thousand steps before you get there, right? And usually, you don't get there entirely. You know, you don't get to the vision entirely the way you had envisioned it. You’re going to take turns, right? And I think in this role, what I get to do is that I get to enable the team to find that path to clarity, and to provide the milestones or the mission for each of the goals along the way.

It's really hard to explain, but I think I didn't come into Pluralsight thinking I was going to do that. I came into Pluralsight thinking that "Oh, there's this really hard problem and nobody's solving it. So, I think I need to be the person to do that." When I was hired in, I was hired in as a PM for the AI team. But, in the process of conducting research for AI, I started doing research on search just because it was this obvious platform where many of the user journeys start with search. And then I recognized that, "wait a minute, how come we're not focusing on search?" And I just... I didn't think I was qualified to lead that team because I've done enough research and I've done enough work in my life to know that usually the leader who leads search needs to be an engineer. I just felt underqualified the entire time.

But in addition to that, the other challenge I actually had was that the team is in Boston and I'm in San Diego. So, I'm remote, right? So how do I lead a team remotely? This is before the pandemic. Imagine that most of the company is co-located, I'm this leader working on a brand new product. Well, I'm trying to replace the existing search because I recognize it wasn't just... it's not scalable and data excellence is not there. I recognize all these problems, and I recognize that I have to lead this team remotely. One of the decisions I made upfront was that, I'm not going to tell the team what to do.

I'm just going to give them space, right? And I'm going to do whatever it takes for them to run independently. And that's the bet I made, because I'd worked enough with engineers at GoPro who are just working on new technology that they know nothing about. And you know, when you give them space, engineers can do great things. So, that's all I did. It was me and four engineers. And they're working in Boston while I'm in San Diego. And I try to just let them, do whatever they need to do. I just ask questions. That's pretty much all I did. And then I managed up where I presented vision. And then at that time, they were like, you know, every company there's always sexy projects that leadership tells product people to do, and everybody has FOMO because they wish they were working on that product. I never had that FOMO. I was like, that's great. Just go look at that stuff over there. Don't pay attention to us; we're just working on this really boring project over here.

That was something I learned: that sometimes, it's really beneficial to build your own island so that you have the space to experiment and to do the right thing. If you talk to people on my team, they will call us an "Island of Greatness." Actually, I have to attribute this phrase to my, previous product manager at GoPro. He always said, "build an Island of greatness and trust that the rest will follow." Because a lot of times when we build things, we're like, "well, what if this happens over here? What if this team doesn't adapt what we do? You know, what about inconsistency?" So, you have a thousand questions. And I used to do that, and he said, "Hà, don't worry about that. Just build your own Island of greatness and then the rest will follow."

So, my team used that phrase a lot, and now we're at the point where, you know, my boss has said, "forget about your Island of Greatness. There's tourists now! Everybody wants a piece of your Island!" So yeah. So that was sort of my journey. And I recognize that giving people space, trusting them to do the right thing, just laying down the guiding principles really, really works. And protect your team from noise, so that they can do great things. And these are things I picked up from working with other people, but I never really got to practice it and build it on my own until each time I had a thought like that, I would be like, let's try this out! Let's see if this works. And so, I got to give kudos to the team because I think I was also really lucky because the humans on my team are just amazing. They just... they believe in the mission, they practice the right values, and they care about each other. There's a value at Pluralsight called, "Create with possibility." and I always say that we hire very strongly against that value.

Asking questions

Jorge: If I might reflect this back to you, what you're describing sounds to me like the journey from someone who is perhaps in more of an individual contributor role, moving to a role of leadership. And I suspect that a lot of designers can empathize with this notion that, I am stepping into this role of leadership in an environment where I don't have the same qualifications as some of the people that I'm leading. You said that search was a very engineer-driven position. We haven't talked about your own background, but I'm assuming from that, that you're not an engineer by training, and I'm wondering how does one overcome the... I don't know if to call it insecurities or the sense that, like, "who am I to go in and lead this group of engineers, when I, myself, am not an engineer?"

Hà: Yeah. I think that the experience I had at GoPro really provided me with... I'm not sure if it's a practice because people always ask me to teach or train them on my practice, but I don't know if I have one. I think it comes down to asking good questions and figuring out like a way to answer their questions. So, for example, if you think about what design does is that we ask questions about the problem so that we could define the right problem to solve, and then we might do design explorations or prototyping, so on and so forth to test those hypotheses. However, the design toolbox leaves a lot of holes you know, like, on the technical side, maybe our prototype doesn't include real data or can't include real data just because the toolbox we have. On the engineering side, they can build things, but they lack the human centered side. Or at least that's not the question that engineers tend to ask. When I was working at GoPro, we were trying to build experiences, for example, for 360º video storytelling. So, when you think about a camera that captures 360º, it's a mental model that humans don't have, right? So, all of us who were asking questions, "well, what does storytelling for 360º look like?" Any assumptions we make is incorrect.

So, what the process of trying to validate or to research what the engagement model might be like, it's just a lot of asking questions. Design might come up with some prototypes, engineers might come up with their own prototypes, but it's that process of working together where everything is an assumption and you're standing on each other's shoulders, one question at a time. That's really the secret sauce. And so, in order for you to have that you have to build a culture, where the team trusts each other, and the team is grounded in the question they're asking.

When I came to search, I didn't have any experience with search, nor do I have an engineering background. I just knew to ask questions and I understood the kinds of discovery behaviors and motivation that our learners have on our platform. That was what I had. I understood like, there's another piece of experience I have, I think most people don't have is, I really asked the questions about motivation and behavior.

About 20 years ago, when I started in my career, I worked on an edutainment type of product. And there were some game mechanics in the product that we were building. And so, I understood this triggered response you know, that's ingrained in every interaction. I understood that if you feed the user something, you shift the framing. And that basically pushed them to react a certain way. You can see this in search auto-suggest, right? If you just type in a query and nothing happened, you're going to type in your query because it's what you can recall. But if you suggest something, then you can shift the user's behavior because the query they put in might not be something that they are looking for, but it's only what they can recall in their own knowledge. But if you suggest something tangential, then suddenly you've shifted the user's behavior, right?

So, I felt like the questions I was asking engineers helped them to kind of set like the milestone for the next thing. And the advantage was that I had this team who had never worked in search either, so they didn't assume they knew anything. And I think sometimes like when we reflect back on our journey, I used to tell the engineer that it was great because you didn't know any better. So, we didn't have any assumptions that we knew more than the other person. We were all on this journey together, and that was really great. It was just us asking questions, one on top of the other.

One of the first question the team asked was — we were replacing the previous search engine — and one of the engineers asked, "what is the success metric? How do we know that we've achieved our goal?" We said, "well, of course it has to be relevant." And then one asked, "well, what does relevance mean?" Right? And that's really, really hard. So, I said, "well, what if relevance only means that it doesn't suck any worse than the previous search?" Right? So, then one of our engineers, what he did was he created the script that you compared the top 10 results of our search, the previous one, that was the first — kind of the first, very, very early versions we did, right? — but I just brought up the example that when you're building a product and you're building a team that works really well together, you're really building the practice of asking questions and your questions gradually get better and better and better. So, that whole experience, I felt taught me so much about building good products and building good teams.

Exploring the domain

Jorge: I'm very excited about this parallel trajectory between building products and building teams. I have a sense that there is a strong correlation between the two: great teams make great products. And I would expect that the converse is also true? Without a great team, it would be difficult to make a great product. And I also love the idea of asking good questions being at the core of making progress with both. Have you discovered any practices for developing better question-making abilities?

Hà: Yeah, so, I'm really old, so I've lived through a lot of failures. But I noticed when you start a new product or when somebody has a great idea or like sales comes up with something they want to sell, things like that. A lot of times when people think of new ideas, they think it's like this moment of Eureka where it's so clear what we have to do. But it's really muddy. There's a lot of word salads being thrown around, right? People have meetings, they each provide their perspective, but there's a thousand assumptions between the starting point and that end goal. Or when you're building something like search... I keep going back to search because there were so many unknowns. And when you're building something with technology that you know nothing about, where do you start?

I have to qualify this by saying that before the team joined, I had done a ton of qualitative research. I had a point of view around our learner's motivation and their context. So, I felt like I had a good grounding on the problem that we're trying to solve, right? The problems continue to change because we get the problem of scaling all the time, but generally I felt like I understood our users. So, that guided me a lot. But when you're faced with a lot of unknowns, whether it's feasibility or just the problem is vast, what I normally do is I try to get the engineering team to build something, anything. And I also learned this again, from my experience at GoPro, because you're working in emerging tech and you know, nothing. So, what engineers usually do is they will try out things. Sometimes when you work in a sprint, sometimes you see engineering doing these spikes, right? They're like, "oh, I'm going to go do these spikes so they could research something." A lot of times when people are just brainstorming or whiteboarding, they're making assumptions about what they think they know, but actually it's not true reality. And then, when we design, we all have this experience, right? We have an idea, we sketch it on a piece of paper and then we go "Oh, this is a great idea! I'm going to go and I'm going to explore it." And then we go into our design tools and we flush it out. Sometimes when you flush it out, you realize, man, that was a stupid idea or here's why it doesn't work, right? Or what often happens also is that in the process of you doing that, you come up with other ideas that are better.

The problem with the process that we have today in many software companies is that designers are this, but engineers just look at the implementation or the feasibility. Engineers don't get involved at the beginning to push the boundaries or to just play. And you know, engineers also have a problem with ambiguity because sometimes when I push teams to do this, they're "like, what do we do? We don't know what to do. Like, there's too much ambiguity. We can't handle that much ambiguity." I did this with our team previously, where I got them to prototype the structure of the browse fly-out menu. And I didn't make it a requirement. I just said, "we have this constraint to build this menu." And I said, "let's take two hack weeks. Like, you have two weeks and just go and play. Like, just... prototype. Ugly prototype." And one of the engineers told me this story. He said that he was having a conversation with the rest of the engineers and I didn't require everyone to do this. I just kept it open. Anyone who wants to do it, can do it. And the other engineers said, well, I don't get it, what does Hà want us to do? And this one engineer said, "she just wants us to have fun."

But that exercise actually got us the solution we needed. Other teams had tried to solve it, and they keep hitting this constraint. So, what we did was we actually provided a hack that was a creative solution in the interim. And that also... those prototypes enable the rest of the team to ask additional questions, like how do we surface these topics in the menu? And data science took over and data science did their own prototypes. So, it was prototype, prototype, prototype. So, I really believe in getting engineers involved at the onset of big problems. But usually, I try to boil it down to like some core constraint that I want them to explore.

And even if the prototype doesn't work out, it answers additional questions that we didn't realize, like what you want to do if you want to identify the unknown unknowns as fast as possible. And sometimes the unknown unknowns provide you with additional questions about the possibilities about where you might go. And sometimes it just surfaces the risk immediately, where you're like, okay, that's not going to go anywhere. Let’s eliminate that, right? Versus design doing all this stuff, and then you hit the constraint and you have to do all these work arounds and then you have a compromised experience. So, that's been my practice and I always think that if you get engineers involved early, you will unlock their technical imagination. And so that's the battle that I fight all the time at any company, is I try to push back on deadlines and arbitrary constraints, so that I can give my team space to play. Because I know that if they did that, they would build a better product.

The bounds of identity

Jorge: What I'm hearing there is that we are somehow bound by our self-identities, whether it be as an engineer or as a designer. And when you were talking about engineers gravitating towards trying to solve a problem versus this more designerly approach of tackling the uncertainty that comes in that first part of the double diamond, right? It sounded to me like what you're doing is you're helping jog these people who self-identify as problem solvers to reframe their own role as one that maybe is not so much about problem solving but can be also about playing and about tinkering with different directions. Is that a fair a fair reflection?

Hà: Yeah. I also think that in every problem there is time for divergent explorations and there's time for convergent explorations. And some people are good at one and some people are good at others. So, I want to make sure that I provide the space for any practitioner to contribute wherever they feel that secret sauce will be applied. And a lot of times we just peg designers as the ones who were always working on the divergent ones. But really data scientists are amazing at doing that. And some engineers also. They ask questions that we would never ask. And I think that's the valuable part about innovation.

Closing

Jorge: That sounds to me like great advice for everyone, to just give yourself opportunities for both types of thinking, both divergent and convergent thinking. Thank you for sharing that with us and for sharing your time. Where can folks follow up with you?

Hà: I'm on Twitter. I try to limit myself to one social media network because it's too much work. But yeah, I'm on Twitter, @hpdailyrant. People ask me where that handle comes from — the @hpdailyrant, or sometimes people call it "the rant" — began when I worked at a startup and was ranting about every single problem that came up every single day at the start up. But it's evolved. Yeah, so follow up with me on Twitter. I answer most questions I get on DM also.

Jorge: Fantastic. Thank you so much for being with us, Hà.

Hà: Thanks Jorge! Thanks for having me on.