Aleks Bass

Rahul Abhyankar [00:04] Hi Aleks. Thanks for joining me on this show, Product Leader's Journey.

Aleks Bass [00:08] Thank you so much. Thanks for having me. Excited to be here.

Rahul Abhyankar [00:10] Aleks, you've been in the area of market research for a couple of decades now, and I'm just curious to understand how has market research evolved over that time? And with the spate of AI and generative AI and large language models and machine learning, where do you see that going?

Aleks Bass [00:31] It's changed quite a bit. I started in market research back when you would have to generate a survey from scratch and then send that over to an engineering team who would program that survey for you, and then you'd go back and forth with changes and things like that. We have come a long way. One transition point was when tools like Qualtrics, SurveyMonkey, and other forms tools started to really come into the space and create an opportunity for people who are not coders and not engineers to generate their own surveys and to be able to analyze them themselves. That was one turning point. It's a turning point that was particularly interesting for me because it facilitated this transition from being in market research wholesale and really working my way into how can these tools evolve to support market researchers, which is kind of how I pivoted into that product management role and space as well.

One element that is really critical in market research is really the content, and a lot of that is driven by how you ask the questions and what order you ask the questions, how you phrase those questions specifically. You're starting from a much later stage in this case by leveraging ML/AI—your first three drafts are already where you're going to start from, based on using some of these tools.

It's also creating so much opportunity from a data analytics perspective. Whereas before, as an industry, we would all over-index on the quantitative data—how many people said X, how many people said Y, and trying to compare those things—now we could actually look at the individual verbal responses that they're providing to some of these questions and analyze them for sentiment, analyze them for themes, much more intentionally across lots of different segments to be able to elicit even more insights out of that context. Stuff that probably would have taken several types of research before. So I think we're seeing a lot of consolidation.

Rahul Abhyankar [02:39] That's fascinating because you worked at all of these companies that have been so influential in the space of market research, customer research. But I want to go back to DirecTV, where you really spent a lot of time on market research and usability studies. Now, when I think about usability studies, that's typically what designers get their hands into. So how did that happen at DirecTV, with you leading usability studies as part of market research?

Aleks Bass [03:10] It's a great question. That research team at DirecTV also focused on user research, and the designers really were focused on designing new experiences and didn't necessarily want to do the logistics of executing large-scale user experience research studies. A lot of that can be a lot of work. You're talking about scheduling conversations with individuals. You're talking about finding the right customer groups that you want to speak to, making sure you're getting a cross-section, so you're not only talking to one type of customer—from a location standpoint, from a segment standpoint, from a price point standpoint. There's lots of different slices and dices that you could do to make sure you're getting representation.

What we found was that typically the designers are working on such granular experiences and projects that it didn't necessarily provide a positive ROI for us to execute a study for every single one of those. At the time, the traditional ecosystem for doing work was really in the office, and we were bringing people into an office to do these conversations with them and do this kind of research with them so that we could observe how they're actually engaging with the tools. A lot of that observation was interestingly nonverbal. Not only could they tell us what they were doing, but we could actually see them struggle with the things we were creating. Put technology images or prototypes and things in front of them and have them actually try to attempt tasks in a safe space where they don't feel judged for not being able to do it.

That is a really interesting skill. That facilitation is critical, and it's fascinating to me because it looks easy. When it looks easy, we all assume that we can do it. I can tell you a story—back when I was doing a project for a well-known tech company, we had hired this facilitation expert that was leading usability testing for us in one of those modern research facilities. I'm sitting in the back room watching, and I crafted this interview guide. I know this interview guide, the prompts, the follow-up questions, everything like the back of my hand. I'd always been fascinated with qualitative research and I felt like I could do it, like it was going to be easy, no big deal. For one of the sessions, after we got the bulk of our answers, the facilitator was like, "Why don't you go try? Go in the room, lead this conversation. I'll be in there with you, I'll follow up and support you if you need any support."

I have to tell you, I struggled. Struggled. For someone who wrote the discussion guide and knew it like the back of my hand, as soon as you're in that conversation, all of these things start to enter your mind. It really reminds me of the fact that it's a skill you have to practice to get good at. We all in tech want all of our teams to be doing customer discovery and doing this kind of user research consistently, but the training and the practice and the experiences are so critical to making people one, feel comfortable doing it, but also giving them the confidence that they're going to elicit that consistent and qualitative feedback that they're going to be able to use with credibility within the organization moving forward.

For us, it was a lot of logistics, a lot of finessing around facilitation skill sets, et cetera. Honestly, in a lot of ways we played mediator between design, engineering, and product, because they each have this slightly different view of what about these experiences was going to work versus not. Most of the time in those rooms I'm playing translator, because engineering is seeing somebody struggle and they think the solution is X. Design is hearing someone struggle, they think the solution is Y. Product is hearing someone struggle, they think the solution is something completely different. It's hearing all of those elements and understanding what the customer is actually going through that allows us to surface really new and different, maybe lower effort, higher reward ideas by facilitating, even in the back room between those three groups.

Rahul Abhyankar [07:26] So how did the transition from there to Qualtrics happen, where you led products at Qualtrics?

Aleks Bass [07:33] Qualtrics was interesting. By bringing Qualtrics the tool into a few different organizations, I built a relationship with that team, and as soon as they had an opening to bring research expertise into their organization, they reached out to me and asked if I would be interested in exploring opportunities with them on their services department. That's how I started.

When I joined Qualtrics, the amount of customers we had on the platform and the number of services requests that came through were astronomically larger than anything that I had experienced before. We might be working on 10 to 15 brand tracking surveys at any given point in time. That allowed me to see how much those things were very similar, and that the level of consistency across the needs and the execution of those different survey projects was so interesting to me that I approached our CPO at the time and said, "Hey, we should really incubate this into a product line because there's a lot of consistency. This doesn't seem like a strong services play, this seems like technology should be taking the bigger lift." So I joined that team and really crafted the beginnings of the brand experience product line. It was one of the most fun and challenging experiences of my life.

Rahul Abhyankar [08:56] Awesome. That's so great in terms of taking the initiative to identify that new product opportunity and then running with it to build that new product. So as you transitioned into product management, how did you navigate that?

Aleks Bass [09:10] I think the background in research really helped me there. All of those individual experiences rely on collaboration, rely on diplomacy, rely on getting to the root cause of what we're trying to accomplish, and prioritization, because you have a fixed amount of time in a respondent's day and you can't ask everything, so some things inevitably have to get cut. That was such an interesting parallel experience to what I experienced when I transitioned to product management, because it was a lot of the same—root cause and prioritization and negotiation with the teams.

The other thing that surprised me was how much we all think we have this clarity of roles in a lot of ways. Product managers are supposed to do X, and if they don't do X then I can't do my job. Designers are supposed to do Y, and if they can't do Y then I can't do my job. Engineers are supposed to do Z. I find that the people that are the most successful in product management, in design, in engineering, are the people who can transcend those seams and almost find a way to overlap your circle with that other team's circle of influence. The handoffs are so critical, and that alignment and that lockstep is so critical, that if I'm not delivering enough clarity around the requirements to design and engineering, please tell me what else can I answer for you. The more you can lean in and support those other functions, the more effective you're going to be in yours, because it's those people that have that true impact-transcending ability.

Rahul Abhyankar [10:50] That's a great point. The analogy that came to my mind as you were talking about that handoff is when you see a team of runners run a relay race and they're handing the baton from one runner to the other. They are running together for some period of time before the handoff happens, so that's a much cleaner way to do a handoff—minimize the risk of things not going right and the baton falling.

So when we look at all the ways that we get data today—so much data about transactions, about customers, their behavior online—do you think at any point that we would get away from asking customers whether they would actually recommend a product? Or would we infer that from all the data and the signals that we get?

Aleks Bass [11:39] That's a good question. I'm not seeing a way to fully get away from asking experiential elements, and the reason is the sense that there's so much context around which people answer those questions. I might be using a product pretty consistently but I might be extremely frustrated with that product, so maybe that's a high frequency usage point and maybe low value. The second I see something that reduces that friction even a little bit, I'm likely to switch. Then there's other things where there might be some friction points, but because of what the brand represents to me and because of my experiences with that platform or that product, I'm very bought in, and so I'm willing to give much more tolerance to those kinds of products than I would be to ones that are just high frequency but low value.

Usage data is valuable, we use it. We can see what people are doing, but it doesn't always give you clarity around intent, around use case, around value, around some of those other things that can help you future-proof yourself against some of your competitors and new offerings that might solve an adjacent problem that then start to encroach into your own product space.

I like to get a balance when I'm thinking about what do I hope that product managers that I work with are collecting on a regular basis for their product lines. I would want to have a deep understanding of the problem spaces and the use cases that the customer that we're focusing on has, and being able to track attitudes towards those over time and usage patterns towards tools over time. I'd want to understand usage patterns of our product line and satisfaction with those and any unmet needs that exist within that ecosystem, and then satisfaction and perceptions of value.

I'd want to understand effort. The other piece that often we forget, outside of just the recommendation piece—yes, this is a valuable tool to do X and I want to continue to use it—the other piece that we forget about is how easy was it to accomplish X? How delightful is that experience? How much effort is involved? I almost don't care which metric you're using, because I think there's pros and cons to a lot of different metrics tied to that, as long as you are getting that experiential read consistently and frequently enough to be able to decide: is this experience good enough to ship? Is this experience good enough to retain within the product life? Is this experience a focus area that we should take another pass at and see if there's anything we can do to remove decision fatigue or high effort from the flow? Those are, along with product usage, things that are critical to fully understanding: are you meeting the needs of your customer, and where can you spend more time and focus to improve that?

Rahul Abhyankar [14:45] Do you feel, Aleks, that product teams are taking sufficient advantage of these tools to the extent that they should in learning about all the different ways that they can learn about customers? What gaps do you see and what advice would you give to product teams?

Aleks Bass [15:05] I would say no, I don't think that they are. It's an interesting problem space because you would assume that companies like Qualtrics, like SurveyMonkey, are actually using their own tools to do this on a regular basis. I think they are in the sense that there are teams designated to use those, like the research teams. But I don't believe that product management has fully embraced tools like this to answer quick questions for themselves through the product lifecycle.

That's being driven by a couple of different things. Perceptions of customer relationship ownership are a major blocker to a lot of product teams being able to feel empowered to do this. On top of that, you layer extremely territorial teams around who owns that customer relationship, and a lot of gatekeeping. Those things get in the way, especially for enterprise products. Even in scenarios where you've got a product-led growth approach, where there's a self-serve optionality that then grows into what an enterprise account might look like, there's still a lot of power and control over who owns that relationship and how do you engage with them.

It stems even beyond. It's GTM across the board. Support teams feel ownership, sales teams feel ownership, marketing teams feel ownership, because every single team is attempting to contact these users to either get them to buy something or get them to do something, or get them to upgrade and spend more money. It feels very much like any additional ask is going to push these customers over the edge and they're not going to want to engage with us at all anymore, and nobody wants to do that. We're all very protective of that revenue and that experience as much as we can, but I think it would behoove product teams to start to negotiate some ownership over either channels or touch points during which they could get this kind of feedback, because it's critical.

Are people using it adequately to their advantage? Probably not, but I also don't think it's all their fault. There's a lot of barriers in the way preventing them from fully harnessing that power. If you're like, "Oh, let's just let every product manager reach out to whoever they want on the customer base side and ask whatever they want," all it takes is one negative experience of a customer that happens to have a good relationship with someone in sales or someone in customer success or someone somewhere, and now you've ruined it for everybody. Now the entire system gets shut down because somebody asked questions that weren't super coherent, or they made a customer repeat themselves, or they didn't look like they were really engaged in the conversation or wanted to be there. Anything like that at all creates friction. That's why I'm not super for "every product manager must talk to high mandate levels of things." I do want to set goals around that, but I want the team to be self-motivated to go see the value and seek the value in those relationships with customers, and not be forced to check a box.

Rahul Abhyankar [18:19] Aleks, you may not have encountered this situation because you've been in companies that build these platforms and tools, but I've come across these situations where an executive does not believe in market research. Have you come across such a situation? How would you address that?

Aleks Bass [18:39] Absolutely. I think that, like anything, market research can be done poorly. You can have misaligned expectations of what's possible with market research, what questions it can answer for you. That's one level of abstraction. Then you go down a level and you can have instruments that are totally not going to answer the key target questions, and I see this probably more frequently than I would like to, especially in the market research discipline as well, where you're looking at the objectives, you're looking at the instrument, and you're like, there's no way that this is going to address what these questions are, because it's like two different people almost generating these different elements.

The other piece is people go into data collection too soon without thinking all the way through and quality checking that instrument to make sure they're going to be able to do the analysis they want. You would remove a decent amount of that—not all of it, because people have truly negative opinions of market research—but you would remove some of that simply by changing up that structure and that flow. You generate the objectives. You almost generate the reporting plan first, the analysis plan first. What do you need to analyze in order to be able to address those objectives or those needs, and how realistic is that? Then generate the instrument from there to make sure you're mapping to all of that.

It actually speeds up execution. When you get that data back, you can start populating those charts already, because you would have thought through what they look like, and you can start to poke into what are the early indicators as we collect 30% of our sample, 50% of our sample, as to what we could do with this. The flow is an interesting one that causes friction, but you can say that about any discipline. "I don't believe in marketing"—I could say that, but a lot of that has to do with what was the objective of marketing and what are the execution channels, the content pieces, the designs, the interaction patterns, the next steps. There are lots of ways to get things wrong from an execution standpoint.

One of my pet peeves is when people in any organization will say, "Oh, we tried that, it didn't work." And I'm like, well, when did you try it? Years ago? How many times did you try it? Oh, just once. I don't believe you can say you tried something if you tried it once. You need to have multiple iterations of trying to improve something and change different variables and adjusting things before you can fully say this does not work. In my context, I think people jump to that conclusion a little bit too quickly. Likewise, probably a negative experience with market research has led some people to that outcome.

I've also seen so many organizations where the market research recommendation is clear, and you can see competitors in the market space doing this thing or starting to act on this thing and starting to drive towards these variables that you've provided in your report, and teams just ignoring it, not taking action on it, putting it on the back burner, worried more about any potential risk or hit to revenue than they are about the long-term viability of the business or the experience that they are generating for those customers. If you've not implemented any of the market research findings that have been provided, then it's hard for you to really say that you believe or don't believe in the outcomes that they're generating.

Rahul Abhyankar [22:12] What I take away from your advice here is that there is an element of working backwards and saying, here is the objective that we have, here is the data that we need, and the instrument is a tool. How do we then use the right tool, the right channel, to get the data that we need? That's the way of working backwards from the end state.

Aleks Bass [22:34] Totally agree. And who are we asking? That's another element as well. Are they trustworthy? Are we asking enough of them? Are we asking enough variety of them with different variables? Are we sizing those populations effectively? All of those elements are important in terms of how to get to some quality research outputs.

Rahul Abhyankar [22:59] You mentioned you are in a new role. Congratulations on joining Typeform. Do you have a playbook for your 30, 60, 90 days in a new role, in a new company?

Aleks Bass [23:08] Yes, absolutely. I tend to think about the 30, 60, 90 days—I like to deconstruct everything into a product. I might have over-anchored on that piece of it a little bit. There's definitely an approach to looking at your first 30 days as discovery, and then your next 60 days as concepting—what are some ideas that you can draft about things that you're interested in maybe impacting as you get going. Then the 60 to 90 days is really oriented around execution and starting to kick off some of those things and really start to get traction with your cross-functional partners. That is a helpful approach for me.

We start new jobs and we feel like we are in this place where we have to contribute value, because a lot of the context from a previous organization is gone. You're not as familiar with the product as you were your previous product. You're not as familiar with the people, with the processes, with the tools, with your cross-functional partners. Every single thing that could be different in context is, and so try to avoid providing solutions in that discovery phase.

Take that discovery phase, protect that discovery phase. People are going to ask you for your opinions. People are going to ask you for your read on things. Feel free to give them an early read, but I would couch it usually in "from a previous context I experienced this. I'm not sure exactly how that plays out here, how big of an issue it is, how small of an issue it is, but I'm definitely going to keep my ears and eyes open to hear more." Things like that are helpful, but trying to solution too early can bite you in the butt, because it really makes it seem like you're not truly listening, like you're solving a problem in a previous organization rather than solving the problem in your current organization.

It's a hard thing to do, especially if you do have context or domain experience in that space and you see some things that are parallels. You really want to jump in and solution with the team. But you have to tread carefully. There might be some scenarios where that's totally warranted and valuable, and others where it might affect how you're ultimately perceived within that organization and you might be jumping the gun a little bit too much.

Rahul Abhyankar [25:36] I really love what you said about the parallels between the product lifecycle or the product process—discovery, concepting, and execution—and applying that metaphor to the 30, 60, 90 days. That's beautiful.

Aleks Bass [25:38] Thank you. It's been very helpful for me to wrap my head around how I should be thinking about these transitions.

Rahul Abhyankar [25:44] As a leader, you are a new stakeholder for a lot of people. You have stakeholders that you need to learn and build relationships with. What has worked for you, what has not worked for you when it comes to building relationships with a new stakeholder?

Aleks Bass [26:02] People have different approaches to this. It's really challenging for me to build fake relationships that are lacking in authenticity. It's just not an effective use of my time. It's not very helpful for the other person either. My goal is to come in and truly listen to the challenges that they're experiencing. As we were talking about those seams between my job and their jobs, nothing bonds people more than working together for a common goal or a common outcome. Even if something that's a pain point isn't my job, I will still lean in with those partners and help them as much as I can to close the loops, because if it helps them, it ultimately helps me as well. Anything that I can do to help support them shows my goodwill as a partner and starts to form that foundation of very positive relationships.

These relationships are going to evolve, and people have different expectations for how they want to work and what works well for them versus what works well for you. It's not an if, it's a when—you're going to get into a situation where someone steps on someone's toes or someone thinks that somebody else is responsible for something that you might be leaning into, or something that you say might seem like it's a little bit critical of the way that that team is doing their processes. Maintaining and practicing positive kinds of open communication, being really transparent about what you're seeing, what you're hearing, is critical. Otherwise, whatever goodwill you would have built up from doing those collaborative projects could be very easily eroded through a few of those interactions that are negative, that make it seem like you're not authentic, like you're not trustworthy.

How conflict should be addressed—I think people typically tend to use conflict aversion as a tactic to avoid being responsible for sharing their true opinions in these relationships that they're building. I've been guilty of it in the past as well. I don't like conflict. I don't think a lot of people like conflict. Let's not take it off the table completely—there are definitely some who do—but most people don't love to engage in conflict at work. They will find another way to deal with that conflict, and sometimes those are very maladaptive behaviors. "I'm not going to tell you, I'm going to go tell my manager, and then my manager is going to go talk to your manager, and then your manager is going to talk to you." Anytime you're doing this kind of stuff as the first interaction, that's not helpful, that's not relationship building, that's trust eroding. Especially if you're aspiring to leadership positions, you have to be able to have one-to-one, honest conversations with people and share your point of view first.

Another maladaptive behavior we see in people is they won't necessarily report up and escalate to their manager or your manager, but they'll go talk to the team and vent their frustrations about you or about something that you said, and often it's out of context. It's usually the worst version of the combination of variables. It's very rarely exactly what happened. That's another opportunity. Don't do those things. Have those conversations with the person that you have the conflict with, and then if that's not working, if you're not getting anywhere, there's absolutely warranted scenarios for escalation and for addressing those things.

Often we use that conflict aversion approach to creating negative noise within the organization about people, and that one erodes your relationship but also erodes your perceptions within the organization, and it creates extra emotional noise for people at a time and in an environment where, post-COVID, I don't think a lot of us have a lot of space for that kind of energy. We've lost tolerance as a group of people oriented around that.

Rahul Abhyankar [30:12] Do you seek to bring that clarity early on in a conversation with a new stakeholder? For example, if we have different perspectives about a situation, how do we resolve that? Is that something that you seek to establish early in that conversation?

Aleks Bass [30:28] Oh, absolutely. As I'm getting to know people, I am saying things to show them that this is how I like to work. I'm sending signals, and those signals are asking questions about what their current problem spaces are, offering help and support, offering working sessions so that they one, see that they can come to me, even if it's not something that's purely product oriented, and two, that I'm not going to make a big deal about it or take ownership, that I will be there to support them through whatever they need to accomplish whatever goal.

I like to communicate very clearly that trust is important to me. Here's what that means to me. I make it clear to people that I am excited about hearing feedback—positive feedback, negative feedback, whatever kind of feedback. My goal is to grow and learn. Often I think people assume feedback is one way, or feedback can also be a temperature check. It doesn't tell you what the problem is explicitly, it just gives you a temperature, and then through the conversation of that temperature check being raised, you can dig into where is the real problem. Often it's not one-sided. It's not that I am doing something completely wrong or the other person is doing something completely wrong. It's so often a misalignment in expectations or roles. That temperature check of "hey, I want to talk to you about something. Here's what I'm noticing and here's how I'm experiencing this" can be super helpful to get the other person's point of view and really start to problem solve.

Feedback culture is interesting because it's so much pivoted into "everyone must give feedback all the time"—structured feedback and all of these things that I feel like make people feel almost less comfortable providing feedback because there's rules around it. "I must schedule a meeting with you one-on-one, I must phrase it in exactly this structure." It forces this perception that my feedback is final. My feedback is not a feeling, it's not an experience, it's not an opportunity for us to bring our expectations together. My feedback is an evaluation of you, of your team, of your process.

Rahul Abhyankar [32:46] It feels like a judgment.

Aleks Bass [32:47] It does. It feels just like a judgment, and I don't think that that is the most valuable element of feedback that we could use. So often the challenges that people have are in this middle space, where it's not a clear-cut black or white thing, and it really just is misalignment of expectations. We have to feel safe in bringing those experiences and topics up and having the language to address them with lack of certainty. If I come to you and I say, "Well, you did this and it's wrong and I don't like it, please stop" as my feedback for you, it doesn't leave space for us to discuss what those opportunities are.

If I approach the same situation a little bit more openly and say something like, "I noticed that at the last couple of times that we have met, this happened, which made me feel this way. Is that your intent? Tell me how you're experiencing this, tell me what's going on, because I was hoping for Y," then you can provide me with context about what you're experiencing on your end. So many times, isn't it true that you get some feedback back like, "Oh, I didn't communicate that clearly at the beginning. I didn't set those expectations." Or, "Oh, I see you needed this from me first before you could really do X, Y and Z."

I encourage you to just have those conversations in a more open way, share your thoughts, and it doesn't have to be in that structured feedback sentiment. It can be more open, and you can use those tools as a temperature check. Here's how I'm feeling. Let's problem solve and get us to a healthier temperature as a group, as an individual, as a person.

Rahul Abhyankar [34:33] I love that way of looking at feedback as a temperature check, because then it allows you to go a little bit deeper into asking, what are the symptoms and how do we treat the symptoms or the root cause, and really go to the bottom of it rather than just leaving it superficial—here's what was said and I didn't like what you said and being defensive about it.

Aleks Bass [35:04] Totally. Too many people bring an artificial level of certainty to these conversations. The more experience you have in the working context—which, by the way, if you're a product manager that's coming from any other discipline, I salute you, because that additional experience of being a solutions engineer or just an engineer, or a designer or a researcher or a marketer, and getting into a different space, that skill set really adds to your ability to do this job.

It also opens up and broadens your perspective, because you can start to see how these things influence each other and how there's different points of view completely than yours that you might not be aware of at all. To you they're speaking incorrectly, but really you're missing some context on how that language has evolved over time.

I have a great example on that. I have traditionally had an unhealthy dislike of finance—sorry, finance people, if there's any finance people that are listening—but it really came from a place of not understanding it. Early in my career as a researcher and as a project manager, I would be asked questions by finance that, to me, made no sense. Why would you even ask this question? This question is silly and it's totally irrelevant, in my mind, to what I'm trying to accomplish. I would mask that a little bit, probably less well than I thought I did at the time.

As you grow in your career and you have more exposure to these different departments and you understand why they need to ask certain things, they need to have certain information, you start to get a sense for, oh, I was the one who did not understand their context. Anything you can do to close the gap of context between you and whatever group you're working with, the better off you are. We often expect, "they should know how to phrase the question so that I know how to answer it." But it's a two-way street.

Rahul Abhyankar [37:04] Excellent. We could go on and on on all of these topics, but let's come to the rapid fire round of our episode here.

Aleks Bass [37:12] Let's do it.

Rahul Abhyankar [37:13] What's a book or two that you've loved a lot, that you've recommended to people?

Aleks Bass [37:19] Yes, absolutely. Continuous Discovery is one that is super fascinating to me. Staying close to your customers and understanding how to get that feedback, get their perspective, get their understanding sooner rather than later, and throughout the entire ecosystem—I really don't feel like there is a place that you wouldn't benefit from getting customer feedback in the product development lifecycle, both from generating ideas, to understanding the problem, to concepting potential solutions, to then assessing the solutions that have been built. Are they usable? Are they truly valuable? What's missing? To even the go-to-market piece of it. Are you talking about the most effective and compelling elements that would draw them to this particular product or to your company and offering as a whole? It's one that, if you haven't read, you should.

Rahul Abhyankar [38:14] That's a great one. One final question: what was your favorite subject in school and anything from there that you've taken into your work going forward?

Aleks Bass [38:28] I have always been fascinated by human beings and people, so it probably won't surprise you that my favorite subject in school was psychology. It was so much my favorite subject that I took it in high school, I took it as my major in college, and then I got a graduate degree in social psychology as well.

How people think, how they perceive information, how they behave in relationships and also in dyads where there's two people within that core relationship, but also in a group, because the dynamic changes once you have a group. That dyad relationship in a lot of ways can be moderated by what ultimately is going on within that group and the different things that are happening there. That has always been very fascinating to me, which, of course, is why I went into market research, where you're learning what people en masse are going to do or how they feel or what they think, and then transitioning that into product management. It's a very valuable skill to be able to think through what could somebody else's goals, objectives, feelings, experiences be, and how can I adapt my approach and my interactions with them based on that.

Rahul Abhyankar [39:36] Wow, excellent. Psychology, fascinating. Well, thank you so much, Aleks. This has been such a great pleasure to hear your journey and all the learnings that you've had. Thanks for sharing that with everyone. Really appreciate it.

Aleks Bass [39:52] Thank you so much for having me. It's been fun.