Pavel Samsonov: Content-First Product Design Leadership – Episode 190

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | Android | TuneIn | RSS

Pavel Samsonov is a UX product designer with a deep appreciation of content.

His content-first approach to design is driven by his observation that navigating digital experiences is about accessing content, not clicking buttons.

Pavel has also cultivated a deep awareness of the semantic environments that he and his colleagues navigate and he uses that awareness to align and motivate stakeholders.

We talked about:

• his design work at Amazon Web Services working on products for cloud clients
• his content-first approach to design
• his observation that the web is simply made up of containers for forms and forms to input the content
• his take on the “semantic environment” in organizations
• the five working backwards questions they use at Amazon
• how he uses workshops to get executives and other stakeholders to “entertain different views of the world”
• his take on the difference between validation and research
• the benefits he sees in working with low-fidelity deliverables
• the “synthesis process” that he uses to guide user research throughout the design and life of a product
• the importance of “working locally,” starting small and focusing on influencing stakeholders close to you in the org

Pavel’s bio

Pavel Samsonov is a New York-based UX leader exploring the applications of design as a decision-making framework for all areas of product development. He currently builds design practice and leads innovation engagements at AWS. His approach to product & design draws on his experience managing enterprise product teams at Bloomberg, design-driven rapid prototyping in the start-up world, traditional graphic design education, and an academic background in human-computer interaction.

Connect with Pavel online

• LinkedIn
• BlueSky
• Medium

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 190. When it comes to designing digital products, Pavel Samsonov takes a content-first approach, observing that navigating an interactive experience is about accessing content, not clicking a button. In addition to seeing content everywhere, he’s deeply tuned in to the semantic environments that he and his colleagues navigate, and he uses that awareness, along with user research and workshops, to motivate stakeholders to entertain new ways of looking at the world.

Interview transcript

Larry:
Hi everyone. Welcome to episode number 190 of the Content Strategy Insights podcast. I am really happy today to welcome to the show Pavel Samsonov. Pavel’s a design leader based in New York City, Brooklyn specifically. Welcome to the show, Pavel. Tell the folks a little bit more about what you’re up to these days.

Pavel:
Thanks Larry, it’s great to be here. For the past couple of years I’ve been at Amazon Web Services, and I know what everyone’s thinking. It’s not really necessarily known for incredible UX design. So my role is a bit interesting.

Pavel:
I work with customers who are in the AWS Cloud, sort of as a consultant, helping them design new experiences in more efficient ways than they’re used to. So we’re effectively bringing a cloud native design culture to those customers, and it’s combining a lot of the things Amazon is known for, like the working backwards process, with some of the design knowledge that I bring from my experience, both as a UX designer and also as a product manager, which was my role before doing this.

Pavel:
It’s been really, really interesting, because unlike a lot of designers, we start really high up in the value chain. We’re right there when the account managers are first talking to these customers about, “Well, you’ve done the what we call lift and shift. You’ve taken all your stuff, you’ve moved the existing apps into the cloud, and now what? What do you do next?” And by the time they’re talking to me, they’re already bought into the value of design to a certain extent, and the value of innovation and doing things differently. But that buy-in hasn’t filtered in through multiple layers of stakeholders and middle managers.

Pavel:
So it’s been a really exciting four years now, just over four years, to apply design practice in a space that you don’t usually get to do, and jumping into research and very, very early stage ideation and the kind of low fidelity work that a lot of designers just don’t get to do anymore. And then taking that, of course, all the way to the high fidelity stage as well. So it really is a very end-to-end role, and you end up doing all kinds of things from day-to-day.

Pavel:
And that’s honestly been a big part of the reason that I’ve done so much more writing in the past year or two than I have for the rest of my career, because there’s so many things going on that it really inspires you to think about, how are things being done today that you see people talk about as a quote-unquote “best practice”? How does that actually appear in practice when you’re dealing with all these different teams? And then trying to find a way from, “How do we get to where we want to be, and where do we want to be?” from where people actually are, and not an idealized starting place from where you have all the resources and all the knowledge to make anything you want possible.

Larry:
Yeah. That sounds like an amazing role, being in that early, and you’re just right there with the account managers as they’re bringing in the new clients, or new… Is that what you call them, clients, or?

Pavel:
So Amazon calls everyone customers, but essentially yes, they’re the clients of the cloud and then we work with them to help their own customers. Which can be.. I do a lot of enterprise stuff, construction, big pharma, things like that. But then there’s also consumer-facing things like insurance or other things of that nature. Small-value finance, things like that, that really challenge your ability to take things for granted, because the assumptions completely change from place to place. And the users also change as well, because you’re looking at massive institutional processes with dozens of people versus just someone on their phone who doesn’t even want to open an app, who just wants to get their business done through SMS.

Larry:
Interesting. Yeah, actually I want to back up just a little bit and talk about how this conversation came to be. You made this brilliant post on LinkedIn a while back about form following function, and I want to get into that in detail in just a little bit. But as I read that post, I remember thinking, “This guy has got a nice 40,000 foot view of what’s going on here.” That was implied in that post, and it sounds like you’re validating what I was taking home from that.

Larry:
But let’s get back into that. Let me go revisit that post, because I loved that so much. You were talking about in particular… Like everything these days, it starts with AI. Talking about the horror we all share at populating designs with essentially fancy lorem ipsum generated by gen AI. And then you immediately got into like, “Hey…” I think I even wrote the post down. The digital equivalent is not the function of clicking the button, but the function of accessing the content. And that was another way you immediately came to my endearing attention, was like, “Oh, here’s a content-first guy.”

Larry:
So tell me about that, though. That difference between, a lot of people think about the interaction, clicking the button or doing the next thing, as being the thing that designers are doing, and you’re like, “No, it’s kind of about accessing the content.”

Pavel:
So I don’t remember who said this first, but there was a designer on Twitter that I really respected, and her tagline was “Fix the forms one at a time.” And she did a lot of posting on that very into the weeds, “What makes a good form?” And then I started thinking about it and I realized, the Internet is all forms. Twitter was a form. You put in your message and you press send, and then it auto-fills all the other parts of the form with your username and your picture and things like that. And everything that’s not a form is text, it’s content. You go on Wikipedia, you read that article, that’s content. You want to make an edit of the article, that’s a form. That’s it, that’s the Internet. Everything else is just styling.

Larry:
Yeah, I love that simplified… It’s just forms and content. That’s all we got.

Pavel:
Yeah. And so if you want to create value, you need to do one of those things. You need to either make it the information that’s being output better or you need to make it easier to input the information. It’s only really one of those two levers that you have. And this is something that I run into a lot, because I work with people who are not used to working with designers a lot, people who work at companies where their developers still work at a IT department, and that’s how they refer to it.

Pavel:
And they come to me and they say, “Hey, can we have an app,” or, “Can we have a dashboard?” People love to say dashboard. Nowadays they come to me and they ask me, “Can we have a chatbot, or a pizza tracker?” And it’s really only four or five things that people have seen as a container for the forms and for the content. And they come to me and they say, “Hey, we want that as well.” And that’s really where the AI thing comes from, and where lorem ipsum before that, I think, was really popular, is you want to make it easier for the stakeholder who controls the budget strings to say yes.

Pavel:
And so if the stakeholder asks you for a pizza tracker or a dashboard, you want to go and make that right away. And all the content stuff from that worldview, it gets in the way, because you don’t know what needs to go there. You’re not an expert in that domain, you’re not an expert in using that dashboard. You’re just going to go and you’re going to try and make as many assumptions as you can so that you can produce a visual. You show it to them, they’re like, “Cool, awesome. So we’re done, right?”

Pavel:
And then you can hand it off to the product manager to chop it up into requirements, and you hand it off to the developers to build it, and it comes out and the content doesn’t fit. Not even necessarily doesn’t fit the use case. Sometimes it doesn’t even physically fit into the interface, because that was a degree of the disconnect between what was provided and what was actually required, what lives in that database.

Pavel:
And I was at Bloomberg before this, Bloomberg Enterprise, and I’ve got some war stories about that, where we put together designs and then we took a deep dive into what the actual content would be that needed to populate those designs around the taxonomy of the products that would go into that, the data products. And those products do not follow any kind of logical, reasonable structure, because they weren’t created by teams that talk to each other.

Pavel:
And we had to redo the whole design, because it just wouldn’t fit. In the meantime, we had people, very high up stakeholders, asking us, “Hey, when are you going to get done? When are you going to get done? What’s the timeline?” Because they were looking at our original prototype, which looks very tidy because it doesn’t represent reality in any kind of way. And they thought we were already done. So.

Larry:
Yeah, right. Well yeah, two things come out of that that I’m really curious about, is one, I want to back up to at the very start, you were talking about how you’re in a situation now where you’re working early on with ideation and early research-based work and working with lo-fi. I don’t know, like mock-ups or cocktail napkin sketches. I don’t know how lo-fi it goes.

Larry:
So there’s that. I’m really curious about, it just seems like you’re in a uniquely great situation to deal with this. But also, a lot of what you’re saying right now reminds me of another thing I’ve heard you talk about, which is the semantic environment in which this stuff is happening. And it seems like that’s related to this dynamic you just set out too.

Pavel:
It’s a hundred percent related. And a big part of it is, people generally don’t assume that they are wrong. We all have a set of unexamined assumptions that we go about in our daily lives, and to a certain degree, they’re accurate enough approximations that we can get through, we can get by day to day in the world. But when those assumptions come face-to-face with something that disproves them, we tend to struggle a little bit. And it comes out of nowhere because hey, up to this point, it was working just fine. How come suddenly it’s not working out anymore?

Pavel:
And essentially all of these assumptions, in an organization, they start clumping together and they start forming what people call semantic environment. It’s the environment in which the logic, the local logic of the place, functions, that it’s all the beliefs and the assumptions and the best practices of a place all come together. And when you are starting to work with someone from a different semantic environment, they are not necessarily expecting you to not understand their environment, and they’re going to come to you and they’re going to say… in my case at least, as a designer talking to a C-level executive, they’re going to say, “This is what we believe is the problem. Can you make us a design that fixes the problem?”

Pavel:
And one of my favorite questions… I love questions in general, and this is part of why I love Amazon’s culture. Part of the working backwards process is the five working backwards questions. And my favorite of those questions is, “How do you knowPavel Samsonov is a UX designer with a deep appreciation of content.

His content-first approach to design is driven by his observation that navigating digital experiences is about accessing content, not clicking buttons.

Pavel has also cultivated a deep awareness of the semantic environments that he and his colleagues navigate and he uses that awareness to align and motivate stakeholders.

We talked about:

• his design work at Amazon Web Services working on products for cloud clients
• his content-first approach to design
• his observation that the web is simply made up of containers for forms and forms to input the content
• his take on the “semantic environment” in organizations
• the five working backwards questions they use at Amazon
• how he uses workshops to get executives and other stakeholders to “entertain different views of the world”
• his take on the difference between validation and research
• the benefits he sees in working with low-fidelity deliverables
• the “synthesis process” that he uses to guide user research throughout the design and life of a product
• the importance of “working locally,” starting small and focusing on influencing stakeholders close to you in the org

bio

Pavel Samsonov is a New York-based UX leader exploring the applications of design as a decision-making framework for all areas of product development. He currently builds design practice and leads innovation engagements at AWS. His approach to product & design draws on his experience managing enterprise product teams at Bloomberg, design-driven rapid prototyping in the start-up world, traditional graphic design education, and an academic background in human-computer interaction.

intro

This is the Content Strategy Insights podcast, episode number 190. When it comes to designing digital products, Pavel Samsonov takes a content-first approach, observing that navigating an interactive experience is about accessing content, not clicking a button. In addition to seeing content everywhere, he’s deeply tuned in to the semantic environments that he and his colleagues navigate, and he uses that awareness, along with user research and workshops, to motivate stakeholders to entertain new ways of looking at the world.

?” And that question really smashes up every single one of these established semantic environments, because people realize, “Well, it’s common sense,” but they can’t point to anything that would actually lead them to believe that way, because it’s their aggregate experience and the experience of the people around them that seems to suggest this would be true.

Pavel:
And that makes it really difficult, as you go into the research phase, to shake that assumption. Because any research you find, any data points, you’re just going to be told, “Well, you talked to 10 people and you found out this. I have 20 years of experience and I believe the opposite.” So the outcome is going to be, “I’m an exec, you’re not an exec. What I say goes. Find a way that your findings can be reconciled with what I already believe.” And it’s very difficult to engage with that.

Pavel:
Most designers don’t have the organizational capital within their company to push back against an executive and say, “The thing that you believe is not true.” And it’s really difficult to do that with a couple of data points. It’s even harder to do that if you’re not able to do research at all.

Larry:
Yeah.

Pavel:
And I think that’s a big problem with trying to change the semantic environment from the top down. I think a lot of us come into an organization thinking we’re going to create a design-driven organization, we’re going to prove the ROI of design, we’re going to show that design has all of this value. And then we find out that we can’t change the minds of executives. We can’t change the minds of highly placed managers. And we kind of burn out and give up because what’s the point?

Larry:
As you’re saying… Sorry, I’m just fascinated by that. And it sounds like just that working backwards framework, is that what gives you permission and a gateway into that conversation? Because that’s the way… And I’ve never heard the problem articulated so articulately, set out as you just said, like, “Hey, you’ve done 10 interviews, I’ve got 20 years of experience, I win.” And you’re like, “Well, actually… How does that conversation go once you’re in?” Yeah.

Pavel:
So one of the things that we try and do is create that clean break between what they’re already doing and what we’re trying to get them to do. And I think workshops are a really, really good way of doing that. If you think about it, all a workshop is, it’s a meeting with rules. But the important thing is the rules are different from the rules they’re used to. They break them out of their business-as-usual mindset. They’re willing to entertain new ways of looking at the world, and they’re willing to, at least for the duration of that workshop, assume, “Okay, what does this data tell us?” without necessarily connecting that to, “Hang on a minute, my experience is different,” or, “What I’ve heard from others is different.”

Pavel:
The biggest problem is, of course, when the workshop ends and they go back and sit at their big executive desk, they remember that they’re in charge, and the real world comes crashing back. And the trick is to maintain a localized semantic environment that is more responsive to that attitude of discovery and innovation. You can’t get the executive to think your way, you can’t get the person they trust to think your way, but you can get the person that person trusts to think your way. And that’s…

Pavel:
Part of the working backwards method is what we call two-pizza teams. Essentially it’s a team that is small enough to be fed with two pizzas. And that team, the only thing they do is they own this product. And that kind of super focus is really the secret for me, because when you’re working at such a small scale, it’s a lot easier to put a lot of evidence in front of people and put a robust process in front of people and get them to arrive at the conclusions that you can see on their own time.

Pavel:
Because I think that it’s a fundamental mistake to believe that only UX designers are on the side of the customer. My experience in the industry shows me that everyone wants to build something that is valuable for the customer. Product managers want to build something that’s valuable for the customer. Engineers want to build something that’s valuable for the customer. Salespeople, marketing. Everyone knows that their job will be a lot easier if the thing they’re building is valuable, because pushing something that’s not valuable is massively an uphill road.

Pavel:
But it’s very difficult, because tied up in all of those other systems and all of those other semantic environments, to get that done on a large scale. The smaller the scale, the smaller the interference from those other systems. And if you put the evidence in front of people synthesized with a responsible method, you kind of let them come to the conclusion that “What I believe doesn’t fit this evidence. And so either all of these users are wrong, or I’m wrong.”

Pavel:
But you really have to have a good synthesis process, because that for me is the difference between validation and research. Validation is something that a lot of low-maturity design teams often practice, where they will have that opinion. The executive says, “This is true,” and they go out, they start looking for evidence, they find the first piece of evidence that confirms that the executive is right, and they stop. Or they’ll gather a bunch of evidence and they’ll find 10 items that prove “We’re right,” and they stop.

Pavel:
And a responsible synthesis process doesn’t let you stop. You have to go through all of the evidence holistically, ideally as a team. I don’t like doing it in my own cave, I like everyone doing it together, because we can take a look at it and figure out, “This is what the data is telling us individually with individual data points, but brought together, that data creates information. That data creates knowledge.” And that knowledge starts to displace the assumptions that exist in our old semantic environment, because we can see that what we believed, at least in this case, is not true.

Pavel:
And this, I think, is something that some teams miss, because what we believe, oftentimes, is broadly speaking true, but you can’t build a product, you can’t build a valuable service, through broadly speaking. You need to engage with the context. When I formulate a research hypothesis, I don’t expect my research to tell me, “You were right 100%, good job,” or I don’t expect it to tell me, “You were completely wrong. Why did you even do this for a living?” Usually what I get back is, “In these cases, this hypothesis holds up. And in these conditions, this hypothesis falls apart.”

Pavel:
And I think this is a situation where the line between product management and design and the different responsibilities is a bit clearer than in others, because that is really a contentious topic. But for me, the job of design is to say, “These are the contexts in which this is going to work. These are the users that can use this. These are the problems that can be solved with this.” And the product manager’s job is then to say, “I can live with that. It fits into the product strategy.”

Larry:
Interesting. Yeah, I was going to ask you about that. Because I was going to ask, I love the way you said that everybody wants to serve the customers, and I was going to ask, what’s the unique role that design can bring? And that’s what you’re getting at there, is that design context. And it sounds like it’s as much about the persistence of staying in that synthesis process. How do you keep people on board with that, I guess might be the big question.

Pavel:
Yeah. It might be a bit of an odd approach. And I think part of what helps me work this way is, I do probably a lot more low fidelity work than many other designers. I don’t believe that the fact that we have design systems and better design tools means that we can just skip to high fidelity, because the low fidelity work helps you formulate the conceptual fidelity without which the visual fidelity makes no sense.

Pavel:
And so when I organize a team from my colleagues and then my customers are product and development people, I like to take them through… Essentially it’s a cycle, and the cycle looks the same through every stage of the process. It starts with, “What is that hypothesis? What questions do we want answered? How are we going to answer those questions?” And then you run the test and you figure out, “What do the tests tell us, and how does that data help us answer those questions?”

Pavel:
And you’ll notice I’m being very vague about what that test is, because this works for everything. And so week one, we start out with, “We’re just going to do user interviews. We’re going to write a list of questions. We’re going to ask people those questions. We’re going to take that data, and we’re going to use that data to answer our own research questions.”

Pavel:
Week two, I’m going to say we already have enough information that we don’t need to just keep asking interview questions. Our research questions now need to be answered by something more sophisticated. And so I make a storyboard, and I put the storyboard in front of a customer in a customer interview, and I tell them, “Do you see yourself reflected here? Does this describe an experience that you have? Does this accurately capture the pains that you experience? Is the outcome that’s described here a desirable outcome for you?” And oftentimes they’ll tell me, “No.” And that’s the best part, because then I get to ask them, “Okay, what does that look like for you? What does your version of this pain look like? What does your ideal outcome look like?”

Pavel:
And so then we go through the rest of that cycle. Week three, we’ll already have enough information to start putting together maybe wireframes. And then we go through the same thing. “Does this work for you? Is this meeting you in the place that you are when you experience this problem? Do you have enough information or enough of a motivation to engage with this solution, and take it all the way through to where hopefully you recognize that outcome as being something that you want?”

Pavel:
And you can keep doing this and keep doing this and keep doing this, up until you get to those high-level, high-fidelity, clickable prototypes or even functional prototypes that are live somewhere out there, and then you can start automating it and doing unmoderated testing. But the framework around it is the same. And I think that that’s really the key of getting everyone on board with this continuous synthesis, because the synthesis process works exactly the same every single time.

Pavel:
You get all of your data. You break it down into the individual data points. You bring it all together and you start seeing how it fits, and you start seeing what it tells you about how your solution or how your design fits into people’s lives and the way they experience the problems. But if you have a quote-unquote research phase, which is the only time you’re allowed to do research before the roadmap says the work has to start, it’s very difficult to do this. Because you’re going to go out, you’re going to find out you’re wrong, and well, you don’t have any more time to fix it, because the research phase is done. And that puts you in a really awkward situation.

Pavel:
So to get around that, you need to move very quickly. You need to have multiple cycles within one time box. Otherwise it cannot work. Unless you have a magic crystal ball that tells you, “Wow, this is going to be really good,” and then you can just go and do that. Or, the other way this can work is if you have a bad solution and you don’t care about the quality, and so you just go out there, “Hey, we tested it. We checked the box,” and then you’re done. So unless you have one of those two situations, you need multiple feedback loops inside one time box.

Larry:
Yep. As you’re saying this, you’re reminding me of… It comes up all the time. Every discipline, every practice, everything in the world, wants to move left. And to me, the implication of that is, “Okay, we all got to collaborate better.” But what you’re saying now is, and the benefits are clear, of, “No, we got to keep doing this. It’s not like we haven’t moved it left and done it, and we just haven’t done the research, and now we’re done and we just are executing.” This is an ongoing process, that… Does the synthesis ever end, or does this continue after… How iterative is it, I guess, in the long haul?

Pavel:
So, for me the ideal is always that you never stop doing synthesis because you never stop iterating. There’s a ton of instrumentation work that goes into a product launch, and the moment you stop looking at that data with a responsible attitude, then you might as well not have it. Because all of that data, if you’re just going to look at it and you’re going to let your bias inform what you see, well then you’re not really seeing the whole picture.

Pavel:
It’s like, “Oh, these are users. They’re going up, they’re going down. Why is that happening?” You can come up with an assumption and then it fits on a surface level, or you can actually look into the data and you can think about it deeply. But ideally to me, it never ends, because you need to align everyone who’s going to be working on this thing, that two-pizza team, at the very beginning to all think like researchers. Because while we all want to build something that’s valuable for the customer, we don’t all have all the required skills. I mean, almost none of us have all the required skills.

Pavel:
So one of the things that I found in my practice, if you do just do a clean handoff at the very end of a workshop, you’ve got all of the artifacts, they’ve got your service blueprints, you’ve got your user stories, you hand them over to delivery teams, they will most likely not be able to ship that product. They won’t even build it wrong, they just won’t be able to build it, because you haven’t created the mental model in their minds of what that thing is supposed to look like and why they should care. But if you all start together and you have a very gradual, “Well, now we are leading and you’re observers,” over to, “Now it’s your turn to lead, because you’re the experts in actually getting this thing built,” it’s very easy to take those habits, the good habits you’ve built, and just keep it going.

Pavel:
You’re going to have developers receiving requirements from a product manager, from an executive, and thinking, “Hang on a minute. This doesn’t fit with the mental model. This doesn’t fit with the research we’ve done and the design we’ve done. I’ve seen people respond positively to this. Now I’m being told to change it. I’m going to think long and hard about how I can respond to this.” If you just did a clean handoff, anyone can come in and say, “Priority change, we’re doing this instead.” And all they can say is, “Okay.” Because both of those requests are equally anonymous. They have no emotional attachment, and they have no professional attachment to this product. They’re just doing tickets, and every ticket is just as good as any other ticket.

Larry:
Yeah. I love that. I got to say, I love that it just keeps going, and it’s a process that seems to natively transcend these cross-functional teams that you need to pull together.
But hey, Pavel, I can’t believe that we’re already coming up on time. These things always go way too fast. I could literally talk for two or three hours about this. So I need to wrap up. But before we wrap up, is there anything last, anything you want to revisit or reinforce from conversation, or just share before we leave?

Pavel:
Yeah. I think that for me, this emphasis on working locally is the most important part. I can’t change the minds of C-level executives. I can change the minds of 10 people in a room with me. And one of the valuable things to make that work is, and this is a popular topic these days, the democratization of user research.

Pavel:
I think that you can democratize it by teams. You can’t make everyone be a user researcher, but if there’s at least one user researcher per room, that’s when you can really make it work. And the responsibility of that researcher, it’s not only to go out and ask people questions, it’s also to go out within the company and gather all the previous things that have been tried. In the same way that when you’re going out and doing a user interview, you never want to ask, “Would you do this?” You should always ask, “How have you done this in the past? Last time you did this, what happened?”

Pavel:
In exactly the same way, if you want to build a successful product within an organization, especially an organization that’s not necessarily very good at it, you need to go out there and need to ask, “Last time we tried doing this, what happened? Did we actually succeed? Did we learn what we needed to learn? And did that learning influence decision makers?” And if not, you need to solve that problem exactly the same way as you would solve an interface problem or a product problem or a content problem. You need to figure out, “How can we do things differently this time, so that rather than blaming this executive or blaming this process for our thing not shipping, we have a better chance than those who came before us?”

Pavel:
And I think that is honestly the key to this whole thing, is you need to work small, but you also need to look at your process just as much as you look at your product, if not more. And that, to me, is the key to making any of this work.

Larry:
Yeah. Yeah, I love that emphasis on process over product. And also, I don’t know if you’ve ever listened to my tagline at the start of this, that this podcast is all about democratization of content strategy and content practice. And so the fact that… I know there’s been some criticism of the way UX research is sometimes democratized, but I think the way you’re approaching it is kind of like the way I’m doing it, the right way.
But anyway. Well, thank you so much, Pavel. This is a fun conversation. One very last thing. If folks want to stay in touch, what’s the best way to connect online or to follow you?

Pavel:
Absolutely. I think probably LinkedIn is the best way. Pavel Samsonov on LinkedIn. I’m on BlueSky as well, pretty easy to find. Used to be on Twitter, now not so much. And I’m on Medium as well, spavel.medium.com. So it’s a good place to find my longer writing. LinkedIn is where I write some of my shorter pieces. Either way, you’ll probably see cross-referencing between the two. So either way is a good place to keep up with what I’m working on.

Larry:
I’ll link to all that in the show notes, and I will… A lot of people know that it’s really good stuff, too. That’s why I reached out to you. Well, thank you so much, Pavel. Really fun conversation. Really enjoyed it.

Pavel:
Likewise. Thanks for having me on.