Speaker 1: Hey there product lovers, welcome to the Product Love Podcast hosted by Eric Boduch, co- founder and Chief Evangelist of Pendo, and super fan of all things product. Product Love is the place for real insights into the world of crafting products, as Eric interviews founders, product leaders, venture capitalists, authors, and more. Let's dive in now with today's Product Love Podcast.

Eric Boduch: Well, welcome lovers of product. Today, I am here with Kandis O'Brien, who's the co- founder of The SIX. Kandis, why don't you kick this off by giving us a little overview of your background?

Kandis O'Brien: Sure. Thanks a lot, Eric, and I'm so happy to be here today. As you mentioned, I'm the co- founder of The SIX. It's an innovation and design strategy consultancy. We started The SIX about three years ago as a team of six women, just in case you were going to ask me, what was the reason for the name. My co- founder, Diana Lou and I, we were management consultants, and we led an offering called Design For Digital at a large consultancy, our focus was really about how do we leverage human centered design, and approaches like design thinking, design sprints to help enterprises accelerate their digital transformation initiatives. That was everything from helping them build new business models and customer facing digital products or applications, setting up digital factories to support rapid prototyping. Sometimes it was about helping them jumpstart their AI or their agile journey. The range of projects was huge, but everything was focused on empathy. Really understanding who the user was and what mattered to them, and experimentation. So, creating processes that supported rapid prototyping, user testing, and getting insights that would give directional information that could be used for strategic decision making. That really was the basis of our offerings when we decided to make the jump and start The SIX.

Eric Boduch: Tell me about your earlier background, what got you into product, what got you into design?

Kandis O'Brien: Prior to consulting, I spent several years doing product and program management, rolling out enterprise eCommerce and content management solutions for companies like Uniqlo and for Heinz, but probably my first real exposure to the principles and practice of product management was as a trade marketing manager at a global CPG. I was responsible for, among other things, creating physical products. So, creating special packs of rice, of all things for big box stores. If you happen to have a 12 pound bag of Uncle Ben's Rice in your pantry, you probably have me to blame for that. Definitely CPGs were in hotbeds of innovation. There's a lot that was flawed in the business and innovation model, but what was great for me was that it was an opportunity to really learn some of the most important aspects of product management, even if we weren't calling it that. The importance of understanding our customers, the importance of leveraging user research and customer insights in decision making, ensuring that we're defining product strategy in line with overall business strategy, creating a product plan, developing go to market strategies. These were really elements that we focused on, and I had the opportunity to learn from fantastic brand managers. Again, my background isn't design. My degree is actually in accounting and economics. My focus has always been on strategy. Getting those insights and being able to run large scale projects was really invaluable. I really benefited from working with that team.

Eric Boduch: No desire to having a career in accounting?

Kandis O'Brien: I did it for two years, and quickly decided that it was not my jam. But what was really interesting about it was that working in marketing and brand, it was the most useful degree that I could have, because actually people think marketing is creative, but it's all about managing P& Ls. It's all about managing strategy. Having that background was actually super valuable.

Eric Boduch: Tell me a little bit more about The SIX. What inspired the six of you to start it, and what big problems are you solving there?

Kandis O'Brien: Yeah. I think all of us had some experience with management consulting, we'd had opportunities to work together, we really liked each other. When we were thinking about The SIX, and we were thinking about the team that we wanted to bring on, what we were really focused on was how could we have real impact for our clients? How could we make them effective much faster? Traditional management consulting can actually be really inefficient and slow, and that's by design, because the model is based on maximizing your utilization, maximizing your billable hours, versus client outcomes or business value. For an example, we had a telecom client, where I was leading a research project, and it took three months for us to do user research. Two of those months were just spent figuring out who we wanted to talk to. Then we took another three months to do design mockups before we could even start talking to the developers and actually build something with engineering. All of those delays were compounding upon each other. So, building a mobile app actually took about two years for it to release. Now, when we run a design sprint, depending on the types of questions, or the problem that our client wants to solve, we are able to do just enough product research or just enough user research to really understand the opportunities, to really understand the user needs, and to get some directional insight upfront. We're able to run a design sprint, a five day design sprint, get the team aligned and working on a high fidelity prototype, and we actually test with users all in five days. When I think about how long it took us to actually release anything, versus what we do now, it's really incredible. I think that, that was definitely one aspect of it, we really wanted to create some impact, we wanted to do something different. The other thing that I think was important to us was, we wanted to be part, both my partner and I are people of color, we wanted to be part of a movement and innovation, where we were more directly creating opportunities for other women and underrepresented groups. That was about staffing them, providing mentorship, providing more community. The SIX, our company, we're actually coordinators of Google's global design sprint chapters. Today, there are about 20 chapters around the world, and my partner, Diana Lou is the global community lead. I run the New York City chapter, Design Sprint NYC. That's free, in case there's anyone who's interested in joining. We're really interested in building communities of practice around sprints. So, we provide designs participants with opportunities to learn, practice their craft, access ongoing coaching and support. We also curate leadership, development groups diversity and inclusion events and activities for underrepresented groups. It's our way of trying to give a more diverse voice, and encourage more people to come into the innovation process and maybe have their chance of working on the whiteboard as well. Then maybe the last one is probably not as high minded, but I think it was definitely a factor, we were actually just sick about flying around the country, and it just seems so inefficient. I asked a couple of my friends who were still in consulting, what it's been like with COVID, and they'd be like, actually, they're kind of more productive, and their quality of work has increased just because they're not jet lagged half of the time. I think that was actually a real third reason for us, how can we be home more often?

Eric Boduch: Yeah, avoiding jet lag is good thing. I do think, consulting has been interesting through COVID because not only do you have less of the travel issues, because let's face it, traveling, especially plane travel is not fun for 99% of us. But you also have all the costs associated with that, and just the disruption to your life, where it's this new remote world, it's kind of interesting, and how much we get done, how productive it is, all without getting on a plane.

Kandis O'Brien: Yeah, it was actually really interesting for us. We had a design sprint, actually, we are doing a design sprint with that client today. But very first, totally virtual, five day design sprint was with this client that was focused on building an AI assistant to help people consume video more effectively. What they realized was, everybody is now on these million coils; their triple book, there are all of these Zoom videos that you need to see and catch up on or whatever. Maybe there's an opportunity to serve that more appropriately. But what was interesting for us was this particular design sprint happened at the start of April, just as New York had gotten locked down, San Francisco had gotten locked down, so there was new opportunity to travel. We really scrambled really quickly, and we were able to make the design sprint absolutely remote. We were very worried that, people were going to get exhausted five days, seven hours per day, that's a lot. We were very concerned. But it actually was this really amazing collaborative experience. I really thank some of the collaboration tools that are out there inaudible that have really made it possible for us to run our business without meeting to be in front of a whiteboard with someone.

Eric Boduch: Let's talk about that a little more. At The SIX, you're using human centered design approaches like design thinking, and you've talked about Google style design sprints, you're solving problems, give us an example of how you use those methods to solve really complex business problems.

Kandis O'Brien: At The SIX, ultimately, what we're about is focusing on helping teams achieve faster innovation cycles. That really starts with moving them as quickly as possible from initial questions and ideas to insights that are going to allow the team to make strategic decision. Our goal is to get teams to do directional insights as quickly as possible. Today, in many enterprises that we work with, it takes weeks and months for them to get insights, and we want them to be able to do that in hours and days. The other thing that we want to do is focus on helping teams identify where there are barriers and bottlenecks in their processes today, and what kinds of resources and tools they need to build their product and their product management capabilities. As you mentioned, we run design sprints for both enterprises and startups, and it really starts with us helping them define a product challenge or a problem statement. We might have a recent example of a client who wants to redefine access and permissions management across their enterprise platform. That's our initial problem statement. We'll use the approaches of design thinking is kind of an umbrella framework for what we do, because it's really focused on the ideas of empathy and experimentation. Within that, one method that we use is design sprint. We might run a five day design sprint, where before the sprint, we will conduct some user and market research, we'll do stakeholder interviews, and then over the course of the four to five day design sprint, we get stakeholder alignment on the customer problem to solve, we'll ID on the solution approach, and then work together to create a clickable, high fidelity prototype that they can test with real users. It should be at sufficient fidelity that they can get really user reactions to the experience. We're not just creating sketches, if we are creating an app, we're simulating the facade and how it would work so people can give us real feedback. We found sprints to be incredibly effective, in terms of getting people closer to insights. They're fast, they're time boxed, teams are working together, but in a way where it's collaborative, but we're putting focus on individual inputs, as well as the group work. Then we're also minimizing ineffective brainstorming so people get to a decision much faster. What we found... I mentioned this client that we had done our sprints with in April of last year, when we went fully remote, they were creating this product... We started the sprint on Wednesday, and by that Friday, the team had really aligned on who their user target was, they had sketched and storyboarded the solution that they wanted to create, and the founder had enough additional insight that he was really able to re- articulate what the value proposition of their solution was, in a compelling way. He was able to update the pitch deck, and he actually secured funding from his first angel investor that we kept. That was even before the prototype was done, and it was actually tested. Since then, they've created their MVP, they landed two of their first customers. Now, the reason that we're having another sprint with them is that some assumptions that were made about the target users based on the initial testing haven't been borne out because a lot of those target users aren't signing up, they're not buying. What's really necessary is how can we reevaluate our assumptions? How can we tune up their vision and then pivot as necessary? I think that's really an important aspect of the sprint, it's not just a one and done. What's really important is that you need to keep validating your assumptions with the user, you need to ensure that the things that you believe are true for the success of your product are really true. Sometimes... As I mentioned, we do product sprints, but sometimes the problems we're solving are not just about products or platforms, often where there's the biggest challenge is around alignment. At the enterprise level, when we're working with clients, we're often brought in because VPs, or senior directors, maybe they're in product, maybe they're part of an innovation and transformation team, or an operations and IT, and they might have multiple product teams that are working with them. Sometimes those teams have cascading dependencies, and they really realize the teams are stuck, or they just can't get started. Then leadership starts feeling the pain. They've got questions and frustrations like, I can't get the data I need to make strategic decisions. I don't really know what all these different teams are working on, or if they're actually making progress. We're not able to ship anything, and we don't even know if we're building the right thing. Those are some of the kinds of questions and frustrations that senior directors, SVPs will come to us. We had a recent engagement for a software company, where they were trying to scale this internal analytics platform. At the start of the engagement, the problem statement that they were creating was around, how do we deploy this platform to make data ubiquitous, and to make data as a service possible in our environment? We went in with this premise that we were going to be working on the product or the platform. But when we got there, just within one or two user interviews, we realized that there was a much bigger challenge around team alignment. There was an IT organization that already owned a competing platform that they thought should be the standard data platform, there was a product research organization that were hiring their own engineering resources, because they felt their platform should be the appropriate standard, and then there was this enterprise analytics team, that should have been responsible for data strategy across the entire organization, and the data product strategy across the entire organization, but they weren't empowered, they weren't funded, they didn't have any real authority. Here we had three different teams that needed to solve this problem together, but they have different P& Ls, different leaders, different visions for how things should work, and they had a very impressive list of JIRA tickets, I think there were 1000s, but they had not been able to develop their product roadmap, or the platform operating model in over a year of trying. We see a lot of variants of this when we work with enterprise clients. Product teams that are working in multiple functional silos, completely different goals, completely different incentives. Before we can even attack a product or a platform problem, we needed to address the organizational issues and the organizational problems, and really help them reimagine themselves, not as three different organizations, but one team, how do they become one team that's aligned on what is the problem to solve, how do they move forward with a common vision, and a common operating model? We ran something that we call a vision sprint, maybe some people call it an innovation sprint, and the goal of the vision sprint was to really help them develop their North Star. When we do vision sprints, we take elements of design sprints, so we've created our own package of what a vision sprint means. It's elements of design sprints, particularly prototyping and testing in a short timeframe, combined with other business model and strategy canvases, to help the team uncover where are the big friction points today, and then align them on things like their strategic vision, their operating plans, and their product roadmaps. Really, the purpose of the vision sprint was to help the team identify the right problems to solve, and then develop an inspirational and clear vision of what they wanted to achieve. Cascading from that, we could move into, what's the strategy? How do we develop an actionable roadmap? After the vision sprint, everyone was pretty much aligned on what they wanted to be able to achieve. One of the tests that we did with them was asking them if they could take any priority ticket in JIRA, and were the members of the team able to articulate how this existing ticket tied to the business objectives, tied to the vision that they had created? If it didn't, should it be deprioritized, should it be moved out of the backlog? Really trying to align what the team is doing, to what the vision and strategy is going to be.

Eric Boduch: Do you find... You mentioned you work a lot with both enterprise clients and startups, do you find that a lot of the problems you're solving in enterprise around alignment, where maybe the startup problems end up being more product problems or product market fit problems?

Kandis O'Brien: Usually, when we're working with startups, they're in very initial stages. It's generally about product problems or product market fit. At the enterprise, what we've been doing a lot of work on... There are product problems, but it tends to be more of these kinds of visions sprints that we're doing, and we also do something called organizational design sprints. There, we're actually working with the client to figure out, what are the right structures they need to have? What are the appropriate roles and responsibilities? How does the team make decisions? What are the appropriate processes and ways of working they should be following? What are the rewards and the incentives that are important to the team? Because teams talk all the time, or organizations talk all the time, about the fact that they want people to experiment and learn and fail fast. But actually, the incentive and reward structures in the organization don't support that at all. Then we're also thinking about the people, do we have the right people with the right capabilities to really achieve this product vision and deliver on the product portfolio? It tends to be like what we've seen again and again, in organizations is most of the problems are around alignment. They are around how do we scale our product organization? They are about how do we create some consistency in our roles, for example. The product manager role is one that tends to be very loosely defined in most organizations. Sometimes you have product managers who are tech people, sometimes you have product managers who are MBAs, sometimes you have product managers who maybe are actually project managers or inaudible who have no background with product management. One of the important things is really understanding does the team understand what the role of product management is? Do they understand the role in relation to the importance for driving the strategy? Then what kind of coaching, what kind of upskilling do they need, what type of tools and resources do they need to support moving the team to a higher level of product management efficiency?

Eric Boduch: When we're talking about organizational design, what do you see larger enterprises getting wrong the most?

Kandis O'Brien: I think, continuing to have people work in these functional silos. A lot of organizations, I think, they look at startups like unicorns, and they speak sometimes in these harsh tones about pizza pie teams, and or squads, and they act like it's impossible for them to actually build small, empowered teams that are really able to own product strategy and able to own all of the elements of the product, and it's not impossible. It's hard, it's very, very difficult, it takes time, and it does mean realigning your organizational structure, it does mean realigning your incentives, it does mean training people. But it is possible, it's a structural problem that can be solved if leadership is willing to do that, and if they're willing to really put focus and attention behind some of the buzzwords. Like you hear, oh, we are product focused, we are customer focused, but really translating what that means and cascading it down the organization is something that often doesn't happen. I think it's actually really important that if organizations want to be product focused, that they are looking at these kinds of structural challenges and thinking about how they can change their organizations and how they can change their cultures.

Eric Boduch: We talked about a lot of different problems that you guys help people solve. What are your favorite problems to solve?

Kandis O'Brien: I like working on alignment challenges, because if you can get the team aligned, and you can get this team moving towards a mission and the core attributes of the product team; strategy, design, engineering, they're well aligned, they're well balanced, you can achieve incredible things. The more that we can do to align product teams, or the more that we can be part of those processes, we're actually really excited by and excited for. I think the second thing is aligned to that as well, it's helping companies take a systematic approach to building their product management foundations, and building foundations that can scale. Because when you're a seven person team or a five person team, communication is really easy, alignment is really easy. But once you start moving, even as a startup, if you're a 50 person team, it becomes much more difficult. Then if you're a 5, 000 person enterprise or more, it becomes even more so. Helping corporations understand or enterprises understand what are the capabilities that they need, what are the tools they need, what is the data they need, so that they can scale their product management functions, so that every time they build a new widget, it's not about reinventing from scratch. Every time you set up a new product team or new scrum team everybody doesn't have to figure it out. I think there are like three phases to that where we focus on, it's like helping the team figure out, do they have the right strategy that aligns to their overall business strategy, and are they actually backing that up by evidence, market research and validation? Are they actually using the information that they're getting to make decisions? How can they standardize some processes? Our background is in consulting, a lot of our work was about process improvement, so we're always looking for opportunities to standardize processes, whether it's strategic alignment, can you standardize things like roadmapping and prioritization processes? I think the other aspect of that is product organization design, do we have the right people, as we were mentioning earlier? Do they have the right skills? Do they have the incentive structure to really achieve what you want to do? Then product operations. Do we have the right information to make strategic decisions? Do we understand what data is important? Do we understand what metrics are critical? It's about ensuring that the team starts thinking about, what is the business data and insights that they need to have? What are the numbers that are important? Maybe that's internal numbers about revenue and cost, maybe it's stuff like usage numbers around the product, maybe it's around churn by customer segments, but what is important from a data perspective for this organization? Then, from an external data perspective, it's, are they capturing the customer and market insights? Do they understand what's really important to their users? Do they know who their users are? We want to really set the stage and have people focused on those things. Then how do we actually create systems and tools that allow people to self- service the types of information that they need?

Eric Boduch: I want to talk a little more about design. Talk to me about why design is so important in product management, tech products really, in general, and how it's underrepresented in today's processes? Because I do think it's underrepresented, especially at the enterprise and to some extent, at startups too.

Kandis O'Brien: I'm trying to pull the quote from Steve Jobs. He said something like, design is a super loaded word, and what's important for people to understand is design is about how things work, and not how you things look. I think that there is still this bias and this tendency to look at design and designers as people who make things pretty, and that's all that they're focused on. But even if that was true, and I don't believe it is, there is room for making things beautiful. When you think about it, the market is flooded with products that are really similar, and sometimes the only thing that differentiates those products is the design, the look and feel that design experience. I don't know if you've been on Instagram lately, but there's the always pan. It's an $ 145 saute pan that comes in pink, and spice, and colors like this beautiful pan. Do I cook? No. Do I own and always Pan? Yes, because it's beautiful.

Eric Boduch: That's awesome.

Kandis O'Brien: It's just a nice looking pan to have on my stove if somebody happens to come by, which I don't have to worry about during COVID. There's definitely value from the visual aspect of design. Honestly, I do think there's been a rise in the stature of designers, and I do think especially because of Apple, especially Facebook and other places, there are more and more people who are taking a seat at the table. But there's still this perception that designers only care about user experience, that they don't understand or care about business needs, they don't design for business needs, they only care about the user problem, which is ridiculous. I have a friend, Aaron, who runs UX strategy, and he says... We have a term for UX designers who don't incorporate business needs into their design process, we call them unemployed. Good designers are actually really focused on both the business and the customer. I think another challenge, actually around design is what does it even mean when you talk about it being underrepresented, especially at the enterprise level? When we talk about design, are we talking about visual design? Are we talking about UX design? Are we including UX research? Are we thinking about industrial design? Are we thinking about product design? Is product design and UX design different? Are they the same thing? Is it about UI? Is it a combination of everything? I think because there's still so much ambiguity around what is encapsulated in design, it's really hard to understand what the designer in product should do and what they're responsible for. Maybe that makes it hard to understand how they add value to the process and how their work contributes to the final product. Then I think the other challenge around design and UX in general, is it tends to be really under funded. I saw an article maybe two years ago or so, it was something like the typical ratio of designers to developers was 1: 20. Then in terms of UX researchers, it was one UX researcher to 100 developers. Just think about that. Then, in addition to that, the organization was not investing in research, so, they wouldn't hire a researcher, unless they had about five designers. That was the ratio, but that was really shocking to me, this idea that the UX researcher/ designer who is responsible for helping to bring all of these market insights, that should be directing the momentum and the approach of the product, there's one of them, but there are 100 people who are ready to code. If they're not bringing in these insights, and you have this feature factory, where people are just creating new features without really thinking about, does this actually serve my customer? Is this aligned to my business strategy? It's just about output. It's not in any way about impact and business value. I think that, that is a big challenge.

Eric Boduch: What do you think the ratio should be? I think about it as like, 1: 4, 1: 5, 1: 8, it depends on a little bit of what the product is, when you're looking at design to engineering resources. I think some of it depends on the product context. I don't know that I have a good ratio for researchers. I haven't spent as much time thinking about that, and I probably, because I work with UX researchers and have done so less in the past, I probably am off, meaning I don't think of it as enough because I would probably be the one for 40 engineers or something like that. I think 1: 100 is a little off. Is it every 30, is it in 25, is it 40? I'm not entirely sure. I've never really thought about it a lot.

Kandis O'Brien: I haven't thought about it a lot, either. But, I do think, as you said, what's really important with those ratios is... What determines them is the nature of the product that you're creating. Then I think the complexity of the questions that you have is really important as well. Then, as important is how are you building this research feedback loop into your organization? Research, again, is not a one on done, that you just do at the start of the project to get some initial insights. But you're actually having a framework and a process for ongoing user research, for ongoing user interaction, for ongoing user testing, and getting that feedback into the organization. That being said, is it 2: 40? Two researchers to eight designers, to 40 developers? I don't know. But the gap is way too massive in terms of the ratios today, because essentially, what you're doing is creating this really industrial mentality around development, where it's about, we need to keep developers busy, we need to just feed this feature factory, and we're not spending sufficient time thinking about, are we building the right thing? We're just in the cycle of building all the time.

Eric Boduch: I know we don't have too much time, I want to jump back to sprints. Let's talk about how we run sprints today. What do you see that teams get wrong, and how can product teams do a better job with their design sprints?

Kandis O'Brien: I think what we often see with teams getting wrong around design sprints is the idea that they need to use a sprint for everything. One of the things that's really important is knowing when is the right time to use a design sprint, and when is the right time to use something else? A design sprint really begins with a well defined, and important problem to solve. If as a team you don't know what your problem is, you need to do some research and investigation, and you should spend some time doing upfront problem framing, ensuring that you're coming into a team, or coming into a sprint with a well defined challenge is really important, because you need to rally people around that. I think the second element to this is ensuring that you are bringing customer and market insights into the sprint and making sure that you are sharing that information within the sprint. Because you need to level set everyone. When we're trying to bring in these customer and market perspectives, in the sprint, we do that with the expert interviews, which are a part of the sprint process. But then we also do things like we might build empathy and inspiration walls, which are not necessarily part of the process, but something that we do as part of design thinking, because we want to ensure that the team has access to see that information, to get aligned around it. I think the other element of the sprint that's really important for teams to get right is making sure that you have an executive sponsor, who has the money, the power, and the influence to facilitate the team to move and execute on the outcomes of the sprint, if those outcomes are agreed to. Otherwise, it's just been a fun exercise for people for five days, nothing is going to happen and it's going to fall into the realm of innovation theater, which is the worst thing that you can do. Because I do think sprints are a really effective mechanism for getting to insights really quickly. But then again, if you can't actually act on them, that's really challenging. Then I think, as a general note, that organizations need to think about how they do actionable experimentation. What's important there is how are the experiments you're doing, making sure that those are actually tying back to the product strategy, tying back to the overall business strategy, and you understand how all of the experiments and the tests you're running through mechanisms like design sprint will actually tie together and can feed on insights that allow you to make decisions. I think sometimes when you're doing sprints, for example, in a vacuum, that might be one of the reasons that it's harder to execute on them, because there isn't the sense that, this was strategically important, or you can show why it was strategically important for you to do that.

Eric Boduch: Few final questions, trends, what do you see happening in software in the next year, that's really interesting?

Kandis O'Brien: Coming out of the last year, I think that we saw that there were a number of companies that were putting their digital transformation initiatives on hold. A lot of people are thinking about, how they can do things like cost cutting, and how they can shore up their P& Ls, if you're a part of an organization. There are going to be restructurings, there are going to be people who are losing positions in different organizations. I think concurrent with that, there are a lot of organizations that are thinking about what automation initiatives that they can begin or accelerate to start gaining efficiencies and reducing costs. I definitely think that we're seeing people who are, or organizations that are focused on that, and thinking more about how they can leverage AI and machine learning. We also see and what we're hearing from some of our clients is that they are very much focused on AI ethics, and thinking about, how they ensure that their AI solutions support diversity, support inclusion. I think that those are great trends that we're seeing where people are consciously thinking about how we can design our organizations and our operations for things like diversity and inclusion, for things like sustainability. I think those are some key elements. I think what we're also seeing is maybe a focus on people creating simpler but more human products. Taking a lot of complexity out of the user experience, of the user interface, and making it very easy for people to engage naturally. Although I had extreme Zoom fatigue, they have a good way of doing that. It's really simple, we're engaging as two people, there's not a lot of technology between us. I do think that we're seeing companies and customers who are thinking about, how can we focus on simpler solutions that really create opportunities for unique and interesting human interactions? I think the other thing that we're seeing a lot of is, especially with startups, is companies that are interested in building their own solutions, and they're looking to no code platforms that will allow them to really move from their initial idea to a working application, days, hours, depending on how good you're at it. We've done some workshops with a company called Platformer that's bringing some of these solutions to the fore. I think it's going to be really interesting because it means that there can be an explosion of new solutions that are not going to be dependent on the costs related to engineering.

Eric Boduch: I think no code is particularly interesting too. That trend's exciting to me. Two final questions. First, what's your favorite product?

Kandis O'Brien: That is a tough one. They may not be my favorite, but they come to mind right now. The first is Robin Hood. It's specifically because I actually set up a Robin Hood account for one of my young cousins. He's a teenager, we want him to become more financially literate, we want them to understand the stock market. For Christmas, I set up an account and basically said, here, you've got a few bucks in this, do with it what you want. It's been fun, it's been exciting, because he's been really into it. He'll text me his gains and his losses. He'll send me ideas about where I should be investing. I actually love that interaction, especially from a jaded teenager who is mostly not interested in talking to me. I think that's fantastic. But just in terms of the app itself, I think it has a great value proposition. It has a really great user experience. It's just really easy to understand. The design is very minimal, but very beautiful and very engaging. They're actually doing a really good job with things like notifications and education. I think it's been really interesting. When I compare it to some of the brokerage accounts that I use, it's blowing them out of the water in terms of usability, and design. I think Robin Hood's been particularly impressive. The app that I'm using the most right now is Duolingo. Every year I say I am going to learn Spanish, and every year I don't. My focus this year... I'm very proud of myself, I am now hitting an 11 day streak, and spanish excited.

Eric Boduch: I get, but you're very excited. One final question for you today. I was going to guess that first your favorite product might be your pan, but then I'm like, no, she doesn't cook. So, it can't be a favorite. She just likes seeing what it looks. But one final question for you today, three words to describe yourself.

Kandis O'Brien: I think curious. I'm very curious about the problems people have, and I'm very curious about different ways of solving them. I think open- minded. I am very much about learning, and I think that makes me adaptable as well. I feel very comfortable being an adult learner, and I hope to continue being that throughout my life.

Eric Boduch: Awesome. Well, thank you. This has been great.

Kandis O'Brien: Thank you. It was a pleasure. Thank you so much for having me.