Aiswarya Kolisetty, Senior Product Designer at Alan, talks to Maze about how to achieve effective collaboration between design, research, and product teams in a remote, async environment and how having a fully asyn culture supports decision-making at Alan.
The Optimal Path is a podcast about product decision-making from the team at Maze. Each episode brings in a product expert and looks at the stories, ideas, and frameworks they use to achieve better product decision-making—and how you can do the same.
You can connect with Aiswarya on LinkedIn or check out her newsletter.
Resources mentioned:
Follow Maze on social media:
To get notified when new episodes come out, subscribe at maze.co/podcast. See you next time!
Ash Oliver:
Welcome to The Optimal Path, a podcast about product decision-making brought to you by Maze. I'm your host, Ash Oliver, UX Designer & Design Advocate. Great products are the result of great decisions, decisions that deliver value for customers and the organization. In this podcast, you'll hear from designers, product managers, and researchers about the ideas informing decision-making across all aspects of product development.
Today, I'm joined by Aiswarya Kolisetty, Senior Product Designer at Alan, a B2B, fully remote European healthcare startup. Before Alan, she worked at companies such as Booking.com, Zomato, Ford, and Tesla. Aiswarya is from Chennai, India and now lives in Amsterdam. She's an illustrator and budding Substack writer and devours audio books in her spare time. It's so nice to connect with you, a fellow Amsterdamer. Thanks so much for being here.
Aiswarya Kolisetty:
Ash, thanks for having me. We met in Amsterdam, actually, just for a coffee. It was so nice to see you in person. It's a small world, so yeah, thanks for having me on here.
Ash Oliver:
So, our topic is around communication and collaboration between design and research, specifically in an async environment, and we're going to take an inside look at how you do this at Alan and how this async strategy supports decision-making within remote teams. I want to have you set some of the context first. Maybe you can describe what the company looks like today, the size of the team, the org structure, and maybe the premise behind Alan's async culture.
Aiswarya Kolisetty:
I joined Alan about a year and a half ago. At that time, I was around the fifth designer in a company of 300. Today, it's a company of almost 550, so double, with a design team of 16. So we've really, really grown and we will continue to grow. As the team has grown, learning to be async with each other, bringing teammates into an async environment is a very unique and interesting experience. And yeah, it's something I've learned to love and enjoy and really become autonomous with. I've found that being async gives all of us in the company the ability to work from anywhere. We're able to be owners of the topics we take on. We are able to be decision-makers. We're biased to action. Everyone is a leader in making choices for the team and for the company.
The culture or the premise of this entire thing is based on really a core set of very unique leadership principles that I haven't seen anywhere else. These are not for hanging on the wall. They're really something we say and use in our day-to-day decisions. So, these are things like we put users first. We want to be radically transparent so anyone and anywhere in the company can look something up and see how they can learn from it. This includes salaries, interview experiences, and process. We also have one that's biased to action. So, you may not have all the data, you may have only 70% of the data or the user research, but can you take that leap to making decisions and owning them?
And then finally distributed ownership. As a team, as we've grown as a design community, if we notice things that are not scaling as the team grows or we notice that collaboration isn't the same that it used to be with five designers, can we take ownership of that as individuals and do something about it? The beauty is it all comes together in a written culture. We're a very meetings second company and writing first company. It's quite an adjustment, but once you learn to read and write your way through decisions, it's very empowering and gives you a lot of free time to just do very deep work, which I enjoy a lot as a designer.
Ash Oliver:
I love it. I mean, Maze and Alan have a lot in common. Maze is a fully distributed and remote company with an async culture as well, so we have a lot of shared values here. But I want to focus on this written first component of async. Is it true that you really don't have any meetings outside of maybe collaboration-type meetings? What meetings occur at Alan and where else does writing cover the rest?
Aiswarya Kolisetty:
Yeah, so I wouldn't say it's no meetings at all because I also don't think that's a very healthy way to be in a company or a group of people working together. I would say the meeting part is removed when you don't have to repeat the same thing more than once. We work with the same model as Basecamp where we have cycles in the year and every cycle projects are opened, and finished projects are closed, some projects continue. But at the beginning of a cycle is a lot of actual in-person time because as a designer, as a product manager, as a data person, you want to collaborate together and brainstorm on the problems you are opening for that cycle.
And so, once we have done some in-person collaboration—and we use tools like FigJam to do that—then we know that, "Okay, here's the mindset everyone's going into the problem space with. Here are the priorities we have and the ideas we have. Now, can we run with this in a written structure over the next few weeks to actually break it down into smaller features we can build and then start opening what we call GitHub issues to discuss piece by piece and go from idea to implementation?"
A lot of that happens in writing once a lot of people are on the same page. And that initial collaboration I think is very important to do sync and not async. There are moments when you try to start async and everyone's on the same page and it's beautiful and it works. But a lot of times a lot of people are not on the same page and to get there speaking to each other really makes a difference. So, when we do have something we want to run with, we open a GitHub issue and as designers we're one of the core members that drive that.
In GitHub, we go through a process that starts with scoping, framing, and then making. Scoping is where we decide the user jobs that we want to do, prioritize them based on the data we have and decide what makes MVP or doesn't. And then framing is basically me going into design, building out the designs in Figma, coming back to the team to say, "Here's how I framed the approach for the user's journey. Do we think we can do this in the eight weeks we have in this cycle, which we've defined as the endpoint to actually launch something?"
And that's where the rest of the team comes into the writing to say, "Okay, this is what I think," or "I don't think this might work. We're missing a critical piece in the design that maybe we should add based on maybe customer service tickets." So, all of that discussion happens in writing along with Slack being there for daily check-ins and to say like, "You wrote this on the issue. I'm not really understanding it. Can we get on a quick call? I need five minutes of your time."
Everything really works together, but that documentation and that GitHub issue is what helps you look back on how the project is going, look at it a year later to see what you actually did—because it's sometimes very difficult to remember all the work you did—or to reference it in the future when someone new has to ramp up really fast. They can look at all the decisions made in the process.
Ash Oliver:
Yeah, I think there's so much to benefit from in terms of that documentation, which I want to talk about in a moment. But coming back to the process and the aspects that you've mentioned in terms of the philosophy and the values, how do some of the things like the users first or biased to action, how do those come into play when you're thinking about each one of these stages that you've just described from scoping to ideation or iteration?
Aiswarya Kolisetty:
That's a great question. When we are looking at something like scoping the problem, the piece of the problem we want to solve, it's not always that you have all the data with you to say, "This is exactly what we want to test. Let's try it out." Or you may have bits and pieces of user research that you use to create a hypothesis, but is that really the right thing to solve? You don't know yet. So, some of the things we look at to take shortcuts in scoping and building an MVP for especially a brand new feature is how we can be biased to action, learn from this, ship it really fast, learn from it in maybe a two-week period, and then revisit our hypothesis in the six weeks we have left in that cycle.
Another example I can give you is around recruiting, which is totally different. So, I'm right now recruiting for designers and one of the things we're noticing is that our recruiting process isn't working the same way for all the roles that we have. So, a product design interview process isn't completely adapted to a senior product designer's interview process or a UI designer's interview process. So, when it comes to distributed ownership, we actually have built a small recruiting team.
Each of us has taken different pieces of it. So one of us is looking at what's on the Alan's career page? What is it that's being shown there? How can we make it more enticing or interesting for candidates? One of us is fixing the entire interview selection criteria and the questions that are asked for a senior designer versus a core designer. Another one of us is writing blog posts and LinkedIn posts to make sure we actually spread the word and get people interested. So, by looking at the aspect of distributed ownership, that's one way we really spread the load between each other and see it through to the end.
And then finally, with the member first or user first mindset, when you're running a business, I think it's very important to understand that the business has to be balanced with the user needs. As you know, all of us in the company—sales, ops, design data, product—we're all doing things in writing. So, sometimes it is on us as designers or researchers to say that we need to take a member-first approach in this particular user job because people are really struggling to get to the end of the job versus there might be another user job where we can't be member first because it's around fraudulent payments or we're not able to help the member because of a systemic or a legal issue. So, there are moments where you have to take the member-first approach and there are moments where it's not applicable and you understand that that's not possible at that moment. Those are a couple of ways we take the leadership principles and the culture and apply it to the daily work.
Ash Oliver:
Yeah. That's really helpful to see how that comes into action throughout the process. I'm thinking about the incorporation of the user in this written environment. Is it typical that the modality or the medium in which all of these insights are shared or documented also takes that written form or are there some places where it breaks from that documentation process?
Aiswarya Kolisetty:
As a designer, I have a better example for that and then I can talk about research. I think one piece where the written formula doesn't always work is when you need to really break things open and think long term, think about the vision that this product needs to be at a year from now. In those moments, the written structure doesn't always help because writing means being very structured and methodical and having a lot of reasoning to the way that you're processing or defining a path.
But doing a design vision requires you to do a lot of back and forth. You need to think about, "What's the problem people are facing? Let me try this path and then let me try that path and then let me try something else. Let me collaborate with fellow designers on Figma in a call." Because we all need to really be talking in the same words and probably at the same time for it to really be an organic way of pushing each other, challenging ideas, and coming out with what we're proud of to be a vision a year from now.
The same thing happens with research. Something I did recently with the researcher I work with was some secondary research. So, I work in the payments team. One of the things we were thinking about is what is the payment journey that a company or a member goes through today with Alan. And that research required us to look at all the different user flows, the timelines, and the deadlines that people have to make payments to us. There were so many questions and so much business logic to the way things are done that we needed an ops person and the designer and the researcher on Figma together on a call to understand, "Why does something work this way? What are the constraints we have?"
And so, building the groundwork for something that you want to explore may not always be possible in a written format because there's just so much to dig into and so many questions and whys that you need to ask to understand why it is the way it is today. So, I'd say those two are very clear use cases for me where I need to work outside of the written experience.
Ash Oliver:
It's very easy to see how this is a philosophy and is the bedrock of the strategy and the culture and the way of operating across teams, but it's not the only way and there's built-in flexibility for these types of situations. More of that open communication and synchronous exploratory work that happens between teams.
Aiswarya Kolisetty:
I also think that when you join a remote company, it's not the same as being in person. You don't see these people every day. What they write may be a very polished version of what they're actually thinking or doing throughout the day. So, sometimes you need to break out of the writing structure to really get to know people better, to build that trust, to have the freedom, to have ideation with each other. And when someone joins the company, I think one of the biggest challenges they have is, "How much can I cross this boundary? Do I have to do everything in writing or not?" And the thing is, it's not set in stone. It has to be something natural. You need to know where you can use someone's time and not waste it.
Once you have that as a boundary or a value in your mind, I think both mediums need to flow one into another. And that's something I've had to learn the hard way. If I'm going into my work, always typing the perfect things and not letting myself look vulnerable, even in writing or in person, it's very difficult to make honest relationships in a completely remote company. You need to take that extra leap and that extra effort to say like, "Guys, this is what I think. I'm not really sure. What do you think?" You need to bring your in-person self into your writing and you need to take the writing out as well to have real fun relationships with each other. And that's something I've learned in the last year that I've changed a lot.
Ash Oliver:
That's incredible. Is there anything else? Any other observations that you've gleaned from this style of working?
Aiswarya Kolisetty:
Yeah. I think at the beginning I joined a company with very, very motivated, intelligent people and it takes a certain type of person to join this place. There's so much self-ownership you need to have that everyone you work with is really, really good and a lot of times much better than you. So, when I joined, it was super intimidating to have to do a lot of stuff in writing. And me not being in Paris where a lot of people do go to an office in person. I live in Amsterdam where I was just alone in my house. My job changed and my laptop changed, but nothing else really changed.
It was intimidating to accept or expect a response from someone and not know how it could be. It could be anything because I don't know any of these people at all. And I've realized that making time to go and meet my colleagues in person is important. And I would say that is something companies should probably support people in and people should take advantage of. I've done my best to go to all onsite and off-sites to meet people and work with colleagues who are in Amsterdam with me as much as I can because that in-person interaction makes up so much of your writing personality. It's important to get to know both.
Ash Oliver:
Yes. It's so well said. It sounds like in order for the writing to really work and for all parties to thrive in this environment that it really predicates on the verbal communication and the relationships and the trust that you're building in real life. What are some of the other rituals or routines in place between these teams, either in written or in asynchronous modes?
Aiswarya Kolisetty:
One of the things we do is we have designers in different parts of the company. We have a few designers on the member-facing product, on the company's B2B-facing product. We have a better health product, which is more about mental health, so it's very important that designers in these little pods are aligned with each other in the way we work, what we prioritize, the level of product quality we emphasize throughout the different teams we work with.
And a lot of our work is connected to one another. There's so many different parts of the B2B experience that are intertwined, similarly on the member side, that we have design pod check-ins once a week. Our researcher also joins these, especially because it's important when she helps us define design strategy and design vision for the B2B experience. We also have often design pairing sessions, so this is when designers come into FigJam. We say, "I'm working on this. It's 20% done or 90% done or it's been shipped, but I want to show you what it is." And we talk about our work and get feedback from one another.
And then I would say we also have a small design system team in place. Their goal is to really look at UI quality. And so, as all of us are working on our projects, we also work with them on UI reviews, on improving the design system, letting them know what drawbacks and problems we have—and these can happen both sync and asynchronously. And finally, we do have things such as continuous learning sessions, so our researchers are the ones that lead that. But as designers, we brief them on really what we're struggling with within the product and where we can have quick wins that are very scoped and do them basically as side projects during the cycle.
Ash Oliver:
I love how for being an async and remote culture there's still such deep ties and collaboration. It's just about which mode is being exercised in order to accomplish that collaboration, which is really remarkable. What do you find works best about this written culture and what are some of the challenges in this way of working?
Aiswarya Kolisetty:
Yeah, it's always changing, but overall, I would say writing basically helps me clarify my thoughts. I'll be in the middle of writing something and I'll get a better idea or I'll get a smarter way of solving the same problem because I am processing the idea that I was already planning to write. So, I think that's one of the biggest benefits. You actually take several leaps of conclusions to get something that could be far more effective than maybe if you just said something off the top of your mind, which can sometimes happen with meetings.
Another thing is if you are someone that works on your time management and uses your quiet time effectively, the writing culture can give you a lot of quiet time to actually think and work on something. This is a challenge also where everything is in writing, so your emails are there with all the GitHub issues waiting for your response and all the Slack messages where people are asking you for input. It's about being more strict about that.
One of my colleagues also said something very interesting, which is when everything is in writing and transparent, you can really learn a lot about the company outside of your profession. I go and learn about how to build graphs on Amplitude by reading documentation from data scientists. I am able to see what types of brainstorms other teams are running, and when the company is raising money, you can actually see the progress and the process of raising money if you follow the channel where they talk about it. And that's such a rare and interesting insight into how our top leadership talks about going after certain types of opportunities or not or discussing the economic climate. I think that is a lot of information I would never see, so I find that very valuable.
Ash Oliver:
Tremendous, and speaks highly to the overall culture. There's so many benefits, individual and collective and business benefits. I'm wondering if we could spend a little time on the documentation side and thinking about like artifacts of design or research. Learnings and insights that might be documented or even that decision log of all of the communication that maybe can then be referred back to in secondary research, maybe a year later. I'm wondering, do you have any examples of how Alan has harnessed this together? What are the systems and mechanisms at play that help this stay organized?
Aiswarya Kolisetty:
Yeah, that's a great question. I think that's something where you have to make that trade-off between, "Do I sprint or am I in a marathon? How much do I structure it so that it's helpful, but also, I'm not spending all my time on it?" So, I'll start with the structuring and finding the information back in the future when you need it.
It's a little bit of a mindset thing of, "If I was completely replaceable in this team or in this company, if I went on vacation for a month, how would I put things in a place where someone can find everything without me needing to show it to them?" If I can do that as an individual, at least that's success at some level at getting things back when I need to.
One of the smallest things we do in Figma is when we open a new Figma file and we're working on a new project, we basically say, "What is the GitHub issue we're pointing to? What is the product strategy document that this project is connected to? Who is the designer that worked on it? And at which cycle in which year?" So, at least, that gives you the five or six basic points to go back and find the stuff you need.
The other thing that works really well is that we use Notion as a repository for all things important. So, in every area of the company, B2B, B2C, there is a place you can go to look at, "What is this area's strategy for the coming year? What are the biggest challenges? What are the top five documents you need? Which can then take you to other places. Sometimes, it's just doing random searches on Slack to see where you end up finding old posts or pings by people, saving random messages that you know you'll have to come back to in a few months. It gets easier over time when you start understanding that domain or the area you're working in.
Ash Oliver:
Totally. And it sounds like there's some best practices and some foundations that are set across the company for this. I want to switch to the challenge in documentation or in writing. And I'm wondering, especially for teams that have a lot of different cultures or just different tone of voice, interpretations, is there any of these same basic mechanisms that are in place or rules of engagement so to speak that help to avoid or resolve some of the challenges that might come up?
Aiswarya Kolisetty:
I think that's very important to process as a person and then apply to really make the best of any situation. It's one of the things I found the most difficult when I joined. Not knowing when I'm overstepping a boundary or if I'm challenging someone but if I'm doing it recklessly and without being respectful or if I'm getting challenged and I'm taking it super personally because that's, "Is that on me or not?" And not knowing where to draw that line and say, "Yeah, they pointed out something to me that I should know or I can use to become better," versus "That was tough to take. Can I grow stronger from this or is this something where I can get help or talk to someone that can help me process a certain type of feedback?"
I think one of the important things that's always stressed in a lot of the weekly recaps by the CEO is always try to assume the best intention from people and try to take it in a positive way and if you don't feel very happy about it, be open about it. Say, "I need to have a quick talk with you." And that's the whole radical transparency and being honest to each other. It does have differences culturally. For example, I think even within Europe, there's quite different cultures in the South of Europe, the North of Europe, and how honest and upfront you are about things, how polite you might be. And I think it does have an impact on people.
I come from an even different culture, which is a mix of Indian and American where you don't always say everything upfront. You try to say it in a very nice way without hurting someone's feelings. But for example, in the Netherlands, that's not the culture of people. And I think maybe that helped me grow thicker skin, for sure.
Ash Oliver:
That Dutch directness will do it, huh?
Aiswarya Kolisetty:
Yeah. It's like a shock and like a virtual slap in the face where you realize that, "Okay, I need to deal with it. It's going to be okay." But in more seriousness, I think in writing, especially when English is also a second language, it's not always easy to put nuance and filler words to your English. I think we need to grow the trust in the team, especially as designers, to say, "Okay, we have each other's backs. Let's go out, put our ideas out there, and then talk to the rest of the community to understand how to find the balance with all the other disciplines."
Not always having English as your first language, which is the majority of our company, also makes it tough to understand the level of intensity or directness someone else might be coming to you with. It's very easy to overthink and just continue to ask, "Is this good enough because I don't know what criticism or feedback might be coming at me next?" And I've realized that it's here to help me become better.
If I'm not able to take it and I don't find myself feeling okay, or if I find someone I'm coaching feeling hurt or dominated by something, I think going to that person and saying, "This is what was difficult for me to take, and maybe we have different interpretations. Maybe writing failed us in this situation," is important to say to people or bring it to your support system and ask for help and say, "How do I handle something like this?" And I think we're still working on that as a company. I think it's something that's a work in progress.
Ash Oliver:
The emphasis on communication that's clearly woven into the company's culture and its fabric. The emphasis is still on creating that human-to-human communication and connection. I wonder if you could talk about some of the benefit in terms of the business in working in this way. Has this dramatically improved the speed across the business in terms of decision-making and moving things forward or have there been other big business benefits that you've gleaned from this style of working?
Aiswarya Kolisetty:
Yeah. I think what has really helped is having one place where the company strategy is defined and also challenged openly, refined to a point where people can read through that strategy. See what was challenged and iterated, and to some extent, get to a point of conviction that this makes sense and this is reasonable and I also feel like I'm behind it. So, there's one clear place where there's a company strategy. When you work on any project or problem, we are very deliberate and product managers especially are very persuasive in telling us, "Try to see how this connects back to that company strategy, so we don't have to go down tangents to understand why are we doing this and what is the benefit."
So, in that sense, a lot of that almost middle management politics is removed when you can talk to each other through documented and explainable rationale where everyone has had the chance to read and contribute if they want. And so, it's a thing where it's like, "I can commit to this and sometimes even if I disagree with it, I'm going to trust someone else who is driving this to take the right decision." And even all of that type of decision-making or thought process is something you can openly see.
It also gives you in some sense a comfort that a lot of different perspectives are coming to the table and maybe someone in the leadership team is saying, "I get all of this. I'm going to take this one decision. Let's try it. If we fail, we fail, but I want you to trust me on this." And so, a lot of that invisible meeting stuff that happens in companies I've been in the past where, "I don't know where we got to this decision, but that's where we got to and I have to now be behind it," I think that is a little bit solved in this case.
The other thing is you can really see the progress of a certain business unit over time when you see their weekly updates or their monthly updates. You can really see a business and the team in that business acknowledging when things are going really well or they're declining or they're struggling or they need to pivot because every single week the progress that's documented and that you read in the weekly updates from every business unit starts showing a picture that helps all of you step back and say, "This is what's been happening in the last six months." And then you have that freedom and that transparency to make it a public story and make sure the right people who need to know have the visibility they need.
Ash Oliver:
There's so much business impact that's delivered through what you've described in overall alignment and trust. Even in the circumstances of maybe being in disagreement, there's still this collective rallying because the barriers have been knocked down in terms of the thought process. And you can trace that back even if you weren't part of that decision in the onset, you might join the company a year later and still be able to have visibility to that, so enormous benefit.
My last question before we transition into some of the personal questions for you is how does this translate to the way that you communicate with your users or members?
Aiswarya Kolisetty:
Yeah, that's funny that you asked about that. One of the things we're working on right now is actually how do we illustrate to our members that writing to us in chat and email is actually more beneficial to them than calling. Insurance is a very dicey, complex, and often sensitive or urgent topic where the first instinct you have, especially when health insurance can be an old legacy ecosystem is to call and figure out, "What are the actual benefits I have? How much do I need to pay?"
We noticed that there's a lot we need to change in that paradigm of saying that we are a digital first company. The people behind the chat team are real people. We're not chat bots that will lead you astray and writing to us will help you also document what's happening. Send us the quotes or the PDFs you need, so that we can check things for you. We have a paper trail, so when someone else in the team needs to get back to you, it's something that we can do quickly. So, it's funny because this starts to have a waterfall effect into how we work with our members, too.
Ash Oliver:
I love that example because it's so clear that the culture internally, it ripples out, it radiates outward. And there's not only a benefit. To the same extent that there's a benefit inside the business, there's a user benefit as well. And I really feel that that could ladder into some competitive advantage or differentiation. That's not the default operation for your industry.
So, we can transition into our hat trick questions and my first question for you is, what's one thing you've done in your career that's helped you succeed that you think few others do?
Aiswarya Kolisetty:
I would say in the past it was being able to adapt to different cultures or different types of companies and the team that I'm with. But in the last year or so, I would say it's more about being intentional about what I work on and having a great reason for doing that. One example is I've been an individual contributor for the last eight or nine years. I know what I can do really well. I know what I don't do really well and I know where I can meander into certain things and handle it as a designer. But something I never did before was more on the coaching and management side of being in a design team.
And one intentional thing I decided I wanted to try was to get into this with recruiting during my time at Alan. I've actually now hired for two positions. So, I think one thing I've started doing better in the last few years is being more intentional about what are my professional goals, understanding how those goals are changing. Every few months I try to write it down on paper. I put it on my Slack bot. I ask it to remind me so that I find opportunities in those ways. And then actually seeking those chances when it's present within the team or the company. I've also taken more time to tell my coach, "Here are the things I want to grow at. And these are important for me, so if you find anything down this path, please keep me in mind."
Ash Oliver:
I love how this active ownership even down to the habits and the Slack reminders that you've set up for yourself. My next question is, what is the industry-related book that you've given or recommended the most?
Aiswarya Kolisetty:
There's one that I've brought up in just talking to other designers and it's very tangentially connected. It's called The Power of Now by Eckhart Tolle. It's more about your mental well-being. It's about staying in the moment, so how the past and the future can put you in a state of anxiety or yearning or lacking. But really staying in the moment helps you not have any thoughts at all. You're just there and you are allowing the experience of right now to be what you are.
And the reason I bring this up is that it's not directly connected to design, but it's connected to the fact that as designers, we really love to create experiences and we do sometimes get attached to the outcome that comes out of that and it can frustrate us when the business says, "This isn't the best thing," or when the user need isn't always exactly met. There's so many things that come up in a team that you can't control everything. So, the book is more about how to be living more in the present and how to have less suffering in your life when you can do that. But sometimes I've recommended it when it brings suffering also to the job or the feeling of not having control.
Ash Oliver:
That's a lovely recommendation. My last question for you is what is an unusual habit or an absurd thing that you love?
Aiswarya Kolisetty:
This is quite weird. I love to clean. Cleaning gives me so much peace and calm. When I just clean and I make something tidy and I feel so fresh and mentally, it's like just a laborious activity that gets my energy out or sometimes my frustration out. I enjoy listening to an audio book or whatever, cleaning, watching maybe a TV show in the background. I don't know why. It's just I love that experience once in a few weeks.
Ash Oliver:
I love this as well. We have this in common and I wonder how many designers also share this in common. Well, this has been so great to take an inside look at the culture at Alan and how this comes together across design and decision-making. I really appreciate you doing this episode, and thank you so much for everything that you've shared.
Aiswarya Kolisetty:
Yeah, thanks for taking the time to ask and making the space for it, too.
Ash Oliver:
The Optimal Path is hosted by Ash Oliver and brought to you by Maze, a product research platform designed for product teams. If you enjoyed this episode, you can find resources linked in the show notes. If you want to hear more, you can subscribe to The Optimal Path by visiting maze.co/podcast. Thanks for listening. And until next time.