Episode Thumbnail
Episode 123  |  45:25 min

Daniel Scrivner, CEO of Flow: user research

Episode 123  |  45:25 min  |  03.17.2021

Daniel Scrivner, CEO of Flow: user research

00:00
00:00
This is a podcast episode titled, Daniel Scrivner, CEO of Flow: user research. The summary for this episode is:

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. I am back with part two with Daniel from Flow. We're talking about feedback. As we were wrapping up last time, I thought it might be interesting to talk about feedback, specifically at Apple, and how you deal with real world customer feedback in the development process. Because at a place Apple, you're getting feedback from such a large swath and a huge quantity of people.

Daniel: Yeah, absolutely. Happy to jump into that. Just wanted to say as well, thank you so much for having me back on. It was awesome to chat with you the first time around, so I've been really looking forward to this. Thanks, Eric. Yeah, so on the Apple note, I mean, I got to work on two separate pieces of the design team or design challenges at Apple, and those were the marketing site. The reason I call that out is I think the way Apple approaches marketing is they are not looking to incorporate or really, for any external feedback, to validate any of what they're doing. It's very much internally driven, and they're really trying to have a singular point of view and trying to... They're able to nail that because they have it down to a science, and it's really an art. So it's incredible to be able to take this art form and make it something that's repeatable. But they have that down to a science of how they can take a product that I think to consumers can be really mystifying. Maybe an example of that would be the HomePod. If you look at it, it's not really clear what the heck it is or what features that is, and yet they're able to, one, design a product that has this amazing experience and attention to design. Weave through it, but then they're also able to break that down from a marketing perspective, and as we talked about before, weave in really incredible copywriting, really great just high level sales and marketing thinking of how do you position this? How do you describe it? What do you call this? Where do you show it so people understand how they might use this in their house? Just on the marketing side, I just wanted to make the point that I think, and this is generally more true for marketing and product work, but Apple definitely was not looking for feedback on that marketing side. It was very much confidently driven internally. On the product side, there was a good mix of feedback. I would say the one thing that I really appreciated, especially in hindsight, about the way Apple approached incorporating customer feedback is I think today a lot of the startups that I talk to just way over index on customer feedback, and I think what... If you've built up a body of experience of working on different products, working at different companies, you realize really quickly that there are times where customer feedback is immensely helpful. Sometimes it's you're looking for more quantitative feedback, sometimes you want more qualitative feedback. But there are times where it's really important, and I can give some examples of that, how we've approached that at places like Flow. But then there are also times where it's just not super helpful, or where if you listen to that feedback, it technically all cancels out. I think what Apple got right was, you don't want feedback to fill a void of a lack of vision, a lack of clarity about what you're building, or to replace an internal point of view about how you want to build this and why you think that's the right approach. For me, I think what I took away from Apple at a really high level is you want to be opinionated. Why is that important? Because the best products are singular. They feel like a single voice or a single idea, as opposed to this cacophony of different things that are interacting with one another, and you're not really sure what to take away from it. I think it you need to still be internally driven, but then what you want to do is bring in customer feedback, especially at the earliest stages, and I can give an example of that after I share this bit. But especially at the earliest stages to frame up how you're going to build, and almost just gut- check that you're approaching it the correct way. I think it's so important to be opinionated.

Eric Boduch: Yeah. The example.

Daniel: Yeah. The example that's probably the best illustration is one of the projects I got to work on when I was at Apple was... This was shortly after the iPad was released. I was brought on to think about what the Apple Store experience would look like as a native app on iPad. At that point in time, take everybody back in time, iPad had just come out, Apple did not have a ton of native apps, and they definitely didn't have anything from Apple. com as a native app. Today, there's the Apple Store app, you can use that in your iPhone or your iPad. That didn't exist at the time. They knew that they wanted to bring that experience in a native app to iOS broadly. What we worked on first and foremost was the thing that we needed to be nailed in order for them to move this over. This is important, and I think something I'll try to come back to today a few times is just blending in how to look at something from a business perspective, and then how to look at it from a design perspective, and how to blend those two things together and why that's important. But the experience that we worked on related to that app was customizing a MacBook or customizing any... It could be an iMac, it could be a MacBook Pro, MacBook Air. The reason we did that is because that was the number one revenue source for Apple. I don't know if this is still true, but at the time, they made more money off of people customizing computers than they made off of any individual sales. It was also really complicated. You had to... They have refined this relentlessly over the last 10 plus years now. But you have to make a lot of choices in quick succession, and you want to try to make sure people don't get fatigued, people feel like they're moving forward, people feel like they're being presented with really simple options. They don't end up in this quagmire of, " Oh my god, now do I need to take an hour and go do research on processor." It's a complicated job to do. We were brought in to basically explore that and try to figure it out. The way that we approach that was, again, we started as a small design team. This was another core thing at Apple was, if you were working on a problem, they were huge proponents of small teams. I think there was maybe five or six of us in the room, and maybe one or two art directors, maybe a creative director and a handful of designers working on, and then we'd have copywriters and people that would pop in and out and be working on other projects. But, and I think this is really important, goes back to my earlier point, we started first by forming our own opinion about what we wanted to build. We all came into that project with a ton of pretty strong opinionated ideas about what we didn't about the current experience doing that online on the Apple online store. We had ideas of cool, interesting ways, almost at the form factor, wireframe, UX level of different ways to structure the experience. We had a bunch of ideas there. So we did a bunch of design explorations. What I didn't know at the time when I started, but it's how we approached it on this project and my understanding is it's pretty common at Apple, is they tried to bias for feedback earlier on in the process rather than later. I think there's a couple things, there's a couple reasons that's interesting and it's important. One is if you withhold sharing anything with customers or potential customers until very late in the cycle, you just get very different feedback. People are reacting to stuff that's very high level, very fleshed out. People are.... They're more likely to give you super granular, almost nitpicky feedback, as opposed to high level, helpful, broad, open- ended questions and ideas. Then there's logistically. I just don't think it's great to have poured in a ton of time, energy and effort to then share it with customers and maybe figure out that you're off or on the wrong track and you need to change things around. What Apple did was they did really early on in the process. We had done all these design explorations, and then we put together what's basically user research study that happened over two days in San Francisco. What we did was, and this... When I say we, I really mean the company that we worked with to do this user research. But what they ended up doing was finding two cohorts of customers. One was people who had recently gone through the customized Mac experience on the Apple online store. What we were looking for from that group is what did they like, what didn't they like, and how did this new experience that we were thinking through compare and contrast with what they had just gone through? That's super helpful, but if you just interviewed that group, obviously you're going to get certain bias feedback. The other group that we interviewed was people who intended to buy a new Mac at some point in the next six to 12 months. We knew that they were going to go through this process. Some of them had bought a Mac before, some of them hadn't. What was helpful about that is you had people who were anchored in the current experience, and you had people that didn't have any of that anchoring, but really intended to buy a Mac. We knew that they weren't going to quibble or fight over, I don't know, any of the Mac versus PC stuff, and they were going to just have helpful stuff about, well, when I do this, this is what I would like to see or this is what is really confusing. We got those two groups of people, we interviewed them over two days, and all of the design team, it was one of those like if you've ever seen a TV show, or it's like an FBI or police interrogation room. It's like that. Basically, there's a user researcher in the room. It's not us on the team, which is also really important. It's an objective person who's really approaching it almost as like a journalist, like a journalistic endeavor. They're walking this customer through the experience, and we're showing largely wireframes, it's not really anything they can click through at this point in time, and basically asking them to do two things. One, narrate, and this is not going to be surprising for most people, but narrate what's going through your head, what you're thinking, what you're seeing, what you're feeling as you're going through that. Then two, they would just ask really big open- ended questions. So not leading questions, not questions really trying to seek for an answer. Just questions to elicit a broad range of feedback from people that we could take in and process on our own. We were all behind this double- plated piece of glass. So we could see what was going on and we could hear what was going on, but they didn't know we were there. It was really helpful. I think what was great about that process is, one, it was very objective. We weren't in the room, we weren't showing our babies to these customers, and I don't know, being defensive with any of that feedback. We were detached from it in a way, which is really helpful. We had this broad sense of feedback from these two cohorts of different customers, and just the idea of making it a really comprehensive review, where you have multiple cohorts that are going to have different perspectives. You have someone interviewing them, that's an objective party, I think all those things I took away as just really good, best practices. I can share one other story about one really interesting insight, if that would be helpful-

Eric Boduch: crosstalk It's sounds great.

Daniel: ...but I'll pause there.

Eric Boduch: Let's do it.

Daniel: The thing that was... One thing that surprised me, maybe I'll phrase it that way, going through this process was I... I don't know. I still see this so often when I talk with designers, when I work with design teams, especially in startups where it's almost like people, when they're going to customers and sharing something, they're really looking for customers to give them some sort of an answer. They're not looking for just broad feedback that they can then take and percolate on and try to read between the lines and find patterns between what different kind of customers are saying. They're almost looking for this is what we're grappling with, or this is what we want an answer for, answer this question for us. I think that's totally the wrong way to go about it. I think if you approach it open- ended again, like I said, you're not asking leading questions, you are asking very broad, open- ended questions. I think an important thing in the back of our minds as we were going through this process is we were doing this to gut- check what we were doing. We had already done the piece. The super important piece of the design process were we did broad exploration, we formed our own point of views about what we wanted to try, what we thought would work, what we thought could be interesting. Now we wanted to gut- check that and see how far off we were, or see what we might be missing. To do that, I think doing it really on the process, doing it this open- ended way was really helpful. One thing that came out of one of the interviews that was just fascinating to me, it bubbled up across a number of different customers was, one, just things that I would never have thought or uncovered that really shaped a lot of how I approach that problem that came directly from customers. One of those was... Repeated theme for many of these customers were that they didn't really feel like reviews from customers in the Apple online store, if we showed those during the checkout process was going to be helpful for them because they felt like, " Why would I trust this? I want to open up a separate tab, maybe go to Amazon, maybe go to Google. Look up different types of reviews." I think even though... Sure, for most people listening, you think of Apple and you think, that's the best brand in the world. Of course, it's trustworthy. The majority of customers I think are just a lot more skeptical than you might think they would be. What's helpful to know in that regard is it made us understand that a natural part of this checkout process was people are likely going to come back multiple times. So maybe we should allow them to save something that's midway through and come back to it later on. Customers are also likely, because it's a very big purchase, and what we found is people that were older, say someone in their 40s or 50s, they loved being able to go online without any pressure, look at all the options, put something together. But then as soon as it came to putting in their credit card information, they were like, " Absolutely not. I'm not going to hand over thousands of dollars in this huge purchase for me, and I get nothing in return. I want to go to the store, I want to talk with somebody, I want them to hand me this laptop." I think it opened our eyes into the fact that, yes, we're all obviously younger. For our generation, I think doing this stuff online feels really natural. For a lot of people, it doesn't, and you need to keep that in mind because I think whether you like it or not, that stuff is going to happen. Even if you want people to complete this checkout process online, it's likely not going to happen in all those cases. The things that we brought up was it really helped clarify what data should we show people around reviews and what shouldn't we. How do we make sure that people feel like these reviews are third party objective reviews? How do we make sure people can potentially save something so they can come back to it multiple times? Then how can they, if they want, how can we make it an easy option for them to do all the customization online, but then almost print out a ticket or send it to the store, or be able to print out an order and carry that in and have somebody make that computer for them? I think those were things that... The reason I share those is all super interesting, all super unexpected, and I think everyone on the team unanimously was like, " Wow, that's really interesting. I didn't see that happening." Third, all we would have only uncovered if we had done this early on in the process and if we had done this very... we're just looking for broad qualitative insights in order to shape our process.

Eric Boduch: Yeah, that's really interesting. I have enjoyed all this discussion about your time at Apple on the overview of Flow. Now, I think it would be interesting to talk about Flow a little bit more, the product team, how many product managers are there, and how you look at frameworks for building and shipping products. Maybe, let's start with the first question there. Tell us about the product team at Flow today.

Daniel: Sure. It's a very small product team. Our team in general is pretty small, and I think that one experience that... A couple things that maybe help explain that is I've always enjoyed... I want to try to have the smallest team possible, and something, term, that I always constantly come back to is this idea of talent density, where if I can choose between having a 25- person team where everyone's pretty good at their job, or a 10- person team where everyone's 10 out of 10, I would much rather do that smaller team, everyone's an expert at what they're doing. I just think that leads to better results, and I think as long as you can get away with a smaller team, I think it's really important. We have a small team at Flow. Our team is under 20 people at this point in time. We have two people on the product side that act as product managers, and I can talk about that. Something that's been interesting to me at multiple points in my career is just how almost empty the word product manager is, one that... Even if that title exists at 10 companies, it's likely that the job is different at all 10 of those companies, and in some organizations product managers set the vision. In other organizations, they act as a producer, making sure that everything's happening really well and freeing up the engineers and the designers and the copywriters to focus on what they do best, and handle all the logistical details. That's part of... I think how we approach it at Flow is it's probably 50% producer, and that's a term people may or may not be familiar with. It's super common in the advertising and marketing world. But a producer is basically just... It's a role and it's a recognition that shipping anything is incredibly difficult. It takes a huge amount of coordination, you have to constantly be debugging, are we going fast enough? Are we going slow enough? This thing's taking forever, what can we do to speed it up? We have questions over here, we need to change this approach. There's all this stuff to navigate. I think that's definitely how we look at our product team, is probably 50% of their work is just making sure that everything's running really smoothly and making sure that what we're working on is ideally going to ship on time, but more than that, it's just going to be a great experience for everyone on the team and no one's going to be banging their head and frustrated and feel like they're battling up against problems or have to debug stuff on their own. Then the other 50% is our product team does a lot of initial research, putting together. We call them specification doc sometimes. Yeah, it's probably the best word that we do. But the way that we think of what the product team can do is they're not going to have necessarily final say on what ships or what doesn't ship or what the best approach for this is, because I think that is better left to the designers and the engineers that are on the frontlines figuring that stuff out. But what they are going to do is I think the... Part of this is probably unique to our company. It's also part of just how I think the product role works best based on my experience. But what I often find is engineers and designers are experts at what they do, they enjoy doing that, they want it, they typically... In my experience, I'd say 80% of engineers and designers I work with, they don't really want to handle anything else. They just really want to focus on what they do and make sure that they can be great at it, because that's where they draw a lot of pride and satisfaction in their work. They also tend to be pretty disconnected from customers, and that's not a positive, and I think there's a lot of things that you can do to try to mitigate that or help that. But the way that we think of the product team is, one, they handle all of our customer inputs. We have a feedback board and a bug report board, we use a product called Kenny that we really like. That's a whole thing that has to be managed. At any point in time, there's hundreds feedback items and feature requests and bugs that are inside there that are all being submitted from customers that we have to look at and triage and merge. There are also the other big piece of feedback that we have is coming from support requests, coming... Some of that is very specific, and it's typically bugs. Bugs will be a very specific thing that will come from a customer request. Or it'll be this thing that no customer has ever said this, but here is a type of thing we hear all the time, and here's the root of that problem and how do we try to solve that. They handle our customer inputs into that process, and then what they'll handle is putting together the specification docs. What that is, give you an example of something we did recently, is in our app, whether you're in a product board or a task list, something that is super common that we want to make a great experience is for people to edit something in- line. If they're looking at a task list, they have 50 tasks, you don't want to have to click into a task to edit it there. You want to be able to edit things in- line. We had some support for that in some places, but it was missing in other views, and it just wasn't cohesively great. So we wanted to make it this cohesive thing that anytime you saw something in the app, whether it was an assignee or a due date, you could click on it and edit it. What the product team did there is, one, they looked through Kenny, they looked through trends and customer feedback we were seeing through support to try to look at what are the problems that we hear from customers today with inline editing? That's one piece of data. Another one was going through the app themselves and basically owning here's where it's inconsistent, here's where it's pretty great, here's where it's bad, almost just an analysis of how it works today. That's another data point. Then the third one was where do we want to go? The way that we handle that is discussions on the design and engineering side, and then they'll ultimately try to weave those together into a document. What this specification document looks, at least at Flow, is it will lay out what we're building, it'll lay out if there are multiple phases of work, which is at the tail end of planning. But something that sometimes is in the world of product managers but often isn't is things should this all be worked on at once? Should this bucket of work be broken up into two sprints? Can we do that? Does that even make sense? Can we ship half the features and functionality and then another half? What that product spec looks at is what are we building, why are we building it? What are the problems that exist today ideally with exact word for word quotes from customers? I could talk more about that. But I found over the course of my career that it's super, super important to just have feedback shared in customer's own words whenever possible, because it gives you a sense for how they're feeling, how they're expressing it, how angry or upset or okay, or whatever they're feeling about this issue with your product. Then what's the potential solution, and how are we going to approach it? At Flow, we work in weekly sprints. So we'll sprint for one week. It's a little bit more complicated than that. We have what's called a four- week cycle. Then in within that cycle, there's a sprint that will happen, and a sprint is always one week in length. They'll basically try to take this bucket of work that we're going to do, work with our director of engineering to basically break that out into something. The output of our product team is, what's the feedback we're hearing from customers? What's the problems that exist today? How are we going to be solving that, and how are we going to be able to execute on that? Then once that stuff is handed off, then they're in debugging producing mode.

Eric Boduch: Yeah, I think that's helpful, and I think we covered most, if not all, of what I asked. We even got into the story on why you want feedback in the customer's own words. I think that is really important, right? Because anytime you have people interpreting the feedback, there ends up being inevitably some unintentional bias added to it, right?

Daniel: Unintentional bias, I find more than anything, it just people tend to soften it. In my experience, go inaudible for anyone listening, if you have a support team at your company, go and make friends with one or multiple people or all of the support team and talk with them, and they will share with you super honestly and openly just customers hate some stuff that exists in products today. What typically happens is when that feedback makes its way from a support team or a feature request to the product team, it's softened, so that it's like, " Oh, this isn't perfect today. But here's what it is." I don't think that's great because I think it's just really important that people understand viscerally, how do customers feel about this, warts and all?

Eric Boduch: Yeah, I think that is a good point. I think it's good for product managers, product leaders to actually interact directly on the support channels sometimes-

Daniel: Yes.

Eric Boduch: ...because then you hear it direct too.

Daniel: Well, here's a... This is partially because we're such a small company like I mentioned, but our actual head of product, also, the support team reports to her. She manages a support team, so she's hearing, every single day, all of the feedback and all the stuff that we're getting from customers. Then she's also managing a team of product managers that will then put that stuff together. That definitely will not work forever, and it works really well at our scale. But that's been pretty magical. I think whenever structurally you can try to improve or solve a problem that way, it's not a bad thing to do.

Eric Boduch: Yeah. No, absolutely. You're talking about the team. Talk to me a little bit about hiring, and specifically hiring product managers. What do you look for?

Daniel: Yeah. In my experience it's super subjective, and again... Yeah, I guess maybe I'll try to back out into what are the things that I look for and why? I think I feel really strongly that product managers are not product visionaries, and I don't mean that in a negative way. I think, again, any company building a product, any team building a product needs to have a point of view. But I think just a classic leadership principle, whether you look at the military or whether you look at corporations, is making sure that people have buy- in, and how do you get buy- in? Well, it means that everybody is able to contribute and feels like they have some of their fingerprints on the solution and on the thought process of how do you solve this problem? I think one thing I am against is this idea that that shouldn't come from the team, it shouldn't be a team discussion, it shouldn't be something that everybody buys into, and it should just come from one individual. Just to be super clear, I'm equally opposed to the design visionary that comes and shares an idea and has to be implemented this way. I think anytime you have an environment where there's one person or one party that has the vision, I don't think it's super great. I'm not looking for product visionaries, and that immediately, at least in my experience, that eliminates a decent portion of product managers. I think then what I'm looking for is people who they, one, have a sense for what a great product is, or what a great experiences that syncs with how I view the world and how our team views the world and the products we're interested in building. That's super subjective, but some of the questions that I asked there, I think you actually asked me one of these, is what's a great product experience you've had recently? Walk me through something that you use recently that just delighted you or surprised you. Just talk to me about that a little bit. What are some brands that you admire? I think in that question, I definitely give bonus points when people have an original answer because I think it takes a little bit of guts, and I want to work with people that have their own point of view. I'm definitely going to appreciate an answer to those questions that's surprises me, as opposed to something like Twitter or Facebook or Instagram or something that, I don't know, just doesn't... I don't know if you've really thought through that enough. That's one type of crosstalk

Eric Boduch: Yeah. I love Tesla, I love iPhone, all those crosstalk

Daniel: Yeah. It's like everybody does this. inaudible Tell me something that's surprising. Also, I want to definitely get their understanding and understand their perspective of how they see their role. How do they... Where have they seen things go really well for them when they've worked on projects as a product manager? Where have things gone poorly? Just to understand how they see it, because again, I think, and I had this experience probably most prominently at Square, but at Square there was two positions that we were hiring for, all the time, that were just so difficult to find great candidates for, and that was someone on the information architect user experience side. Those, again, are like vapid titles, and we would find that we would get 10 candidates that all had that title, and then we would talk to them about what they do. Sometimes you'd be like, " Oh my God, you're a graphic designer, how do you have a user experience title?" There's just a lot of title mismatch. Then the other one was product manager, because again, it's different in every company. I just want to understand what that is. Then the last piece that I would say is I'm really looking for somebody who sees their job and is excited and will excel at. It's almost like the product manager role, in some sense, like the United Nations. They need to bring together all these different contentious parties. You've got somewhat heavy- handed customer feedback coming from support, people that are really angry about something. Maybe what you're hearing from customers completely disagrees with your own sense internally of that this is a great solution, but customers are telling you that it's not. You need to have... That needs to have a seat at the table. Engineers need to have a seat at the table, and I think typically there it's like how can you make it so that things are as baked as possible? When they make their way to engineering, how do you make sure that they're involved early on in the process so that they know what's being built and they understand the thought process behind it, and they're not just being handed stuff to implement? You have to bring designers to the table. I think they need to be really good at facilitating those discussions, making sure that where we land is something that people are excited about. Sometimes people are less excited, sometimes they're more excited. You're not always going to land on something where everyone feels equally excited about it. But I think they need to be a party that can intermediate all of that and get that group to function really well in practice day in and day out.

Eric Boduch: How does the skill to pull out or create differentiation as part of a product line fit into that, especially in some of these markets that might be very competitive?

Daniel: Yeah, it's a great question. I mean, again, I think... I'm not saying it's impossible, but I have never seen it work well where there's an inaudible... Say, you're getting ready to kick off work on a project and there is already a really crisp idea in this initial brief of how things are going to be differentiated. I feel like the differentiation always has to be discovered in the process. In my mind, I think the way that I think about that is you... This goes back to I think some of my previous comments about Apple, is you need to bias for having a lot of time upfront for exploration. Why is that important? Because exploration equals serendipity, and you'll find unexpected answers and unexpected solutions and interesting ideas that you wouldn't have if you just have to go from problem to solution in a straight line. I think you want to give people the time to zigzag. There's this concept that I really L in Chinese philosophy that you orbit around the problem. You're understanding it from 360 degrees. If you imagine almost a planet and a moon going around it, you're the moon. You're orbiting around this problem, around this idea. You're seeing it from different perspectives and you're slowly getting closer and closer and closer to it, to having what you feel like is a really successful solution. I think it's a really great analogy for why you want to build in time for exploration, because you just want to give people a lot of reps, a lot of time to approach the problem from different perspectives and see where they land, and a lot of time to synthesize the best ideas from the team into something that's coherent at the end of the day. I would say it's something that's more found in the process and something that's defined up front. But I would also say, too, I think, again, that goes into that initial hiring and screening of... I think it's a very... Some people really philosophically are bought into the idea that differentiation is important, and some people don't think it's important at all. I think in my mind, that potentially comes from I think differentiation is more important from a business perspective than from a product perspective, or at least it's felt more when you're looking at a problem from a business perspective. Now, what do I mean by that? I mean that for anyone who's in a CEO chair, you just have a really visceral sense of the need to be different from competition so that you can market something that's different. You have something that's different at the end of the day. You have to thread that through a lot of different layers in the company. I would say, too, it's also part of that initial screening, and it should be part of that philosophy at the company of whether differentiation is important. Then is that a value you're willing to feel some pain for? A lot of times with differentiation, you're going to land on something that some customers will love, some customers will hate. You need to make sure that if you buy into the mindset that differentiation is important, that you're willing to feel that pain when the time comes in order to live out that value.

Eric Boduch: Awesome. Well, thanks. I know we're getting towards the end already to part two, amazingly enough. Talk to me a little bit about the future. Trends in the product community, what do you see?

Daniel: Yeah, that's a really good question. Yeah, I've been thinking about this. I mean, I've been thinking about this a lot recently, especially in the vein of Flow, to share a little bit of a story. When I took over, I had this sense that we needed to not redesign, but basically just take a fresh look at every part of the product and try to figure out what is the best manifestation of all these different features that we had. That ended up culminating in something that we shipped in the middle of 2020, which will be called Flow X, which was this big update. In my mind, what we're really trying to do there is surface everything that was happening in the product in a better way. As always happens and has happened every single time I've done one of these projects in my career, you're merely in that and you suddenly have all these fresh ideas of ways to do what you just did better. Or you have all these sudden realizations of, oh actually, these two things can be one view, and this can be a separate view. We're going through a process right now where we're basically still building on top of that foundation that we set with this broad rethink, remanifestation of Flow, and what we're really focusing on is speed, simplicity, clarity, stuff just to make sure that it's a 10 out of 10 experience every single part of the app that you interact with. I've been spending a lot of time thinking about what does that mean for us? I think they're... I don't know. It's probably a little bit of a biased answer. But for me, I've always... I think the way I've always tried to think about it is what product would I want to use as a customer, and what sort of product do I want to create as a piece of art? That last piece probably sounds a little bit silly. But I think that companies like Snapchat, companies like Xinli, companies like Apple, maybe I'll stop there for now, but do something where they are creating something that is a great piece of software, meaning it's like it does what you expect it to do, it's really easy and intuitive to use. But I think, one, if you're in this because you just want to create something great, that's not good enough. You want to amp that up a little bit more. On that realm, some stuff that I've been thinking about that I'm continuing to push forward at Flow is things like sound design. How do we bring in really great sound design to the web app, to the desktop app, so that interacting with Flow is as visceral as possible? I think that can sound a little superficial or a little silly on the surface. But if you really understand, for us, we're building a productivity app. Productivity app inherently means that you have something you're working towards. You have to expend effort doing all these individual little tasks. If you understand human psychology, you know that you need to give people little rewards as often as possible so that they feel motivated and they feel they're making progress. I think a part of a productivity app is giving people a sense of progress, and sure, in a simplistic sense, something goes from being an outline square to a checkbox, but in a better sense there's a really wonderful, delightful sound effect people can have on, there's some elegant transition, there's ways of parroting that back to somebody to give them context of how much they've accomplished over the last week or over the last month. That's on the art side. That's some of the stuff I'm thinking about is, broadly, how do you make something involve as many senses as possible when someone's using the product? Then another one is just how can you make your product feel like an extension of somebody's body and mind? How can you make it feel like they're superhuman when they're using it? Not a super crisp answer, but I don't know. crosstalk

Eric Boduch: No. I think it's a good answer though. I was going to make a joke about how you incorporate smell. But the sound-

Daniel: Good luck.

Eric Boduch: ...is interesting. Can you imagine Slack without the beat? Right? Both good and bad, right?

Daniel: Yeah.

Eric Boduch: I was thinking about that as you're answering, and I was like, " It just wouldn't be the same. It wouldn't feel as Slack."

Daniel: No, totally, totally.

Eric Boduch: There's good and bad things for that. I think I've developed a Pavlovian response to Slack sounds. But yeah, it's interesting when you're thinking about how you can think of your software as an extension of a person, right? How you can engage more senses? I know, I talked with Rahul from superhuman about making business software more fun, making it more like a game, right? And giving some of those rewards, both visual, and in this case, audio. Right? Right? Pleasing sound when things that are good get accomplished.

Daniel: Yes.

Eric Boduch: There's ways you can engage with people across a lot of different senses. I think that's really interesting to think about. Now, as we're wrapping up here, we talked about the question you asked, which is a little bit about great products, and I want to know what's your favorite product?

Daniel: Yeah. That's a hard one. I have a such a hard time answering that question because there's a lot of digital tools that I use. There's apps I have on my iPhone, there's apps I have in my iPad that I really enjoy. But I think, for me, what I always come back to is what... I guess the digital products I aspire to build are real world things that I really enjoy. Maybe it's a cheesy example of that. Think about something like Disneyland, where again it's beautifully designed, it's a great experience, you have tons of fun while you're there. They incorporate all these different senses into it. If you really geek out, you can find out things like... There's whole books just about the mailboxes that are at Disneyland. You can actually take letters and go and drop them off at Disneyland, and they'll process them in their own post office, give it this cool special little stamp, send it off. Just through that little lens, and I've just scratched the surface of that example, they've just thought through every single detail. It's beautiful layout, beautiful individual items within that park, amazing ways that you can thread that experience together, all these little hidden gems and Easter eggs that you can find along the way. I would say experiences that I enjoy or things just... I turned to architecture, I turned to fashion, and I turned to things like hotels, things like... This maybe a little bit of a boujee answer, but if you go to Four Seasons, and you see what that level of service is like, it is pretty awe inspiring for someone who wants to create great experience for customers through software. I think the future of software is doing more and more for customers and making it this really all intensive visceral, three dimensional thing. I don't know if I have a single answer. But the things that I turned to definitely are not software. I think just over this weekend, I went down a deep rabbit hole of Louis Vuitton. I don't own anything Louie Vuitton. I think it's an incredible brand that they've been able to build, if you go in and look at their creative process. I was just reading a Harvard Business Review case study from the'90s with the CEO of LVMH, which is this parent company of Louis Vuitton. But what makes... Something that literally at the CEO level that they understand is what I talked about earlier, just how important it is to have a super open and generous creative process where people can try a bunch of different things. The rabbit hole I went down was I think there's a bunch of interesting things in terms of what they built, how they approach doing it. But they also... Not only do they build clothes, but they're building retail stores. One thing that they just opened up is this coffee bar. I think it's maybe in Osaka, Japan. You look at photos of it and it's like... Imagine being the designer on that, where it's like you have to take a fashion brand that typically is only experienced by a clothes and models and fashion, and turn it into a physical space. You have to figure out what your menu is going to be. They just did all these classic like it didn't need to happen, but we should go ahead and do it because we're Louis Vuitton. One thing that they did was, if you get a cappuccino at this bar, they do this crazy, beautiful... I have to literally be some sort of robot that's drawing this pattern on the top of the coffee, but it's this amazing little concentric ring pattern that's going on top of it. I think again, as... I'm a designer by background, so I think I identify with this a lot. But that just speaks directly to me, because I'm like, " Not only I'm sure have they thought about this being a great cup of coffee, but they're doing it with just this extra generous little touches and details on top." I think places like that is where I go to get a different point of view and get inspired, and that's what I aspire to build crosstalk

Eric Boduch: Yeah, it's interesting to point out some of the little micro experiences, right? You were talking about mailing something from Disneyland, right? And the whole experience around that. I think about my iPhone, which is a great product. But what was life changing for me, and maybe that's a strong word, but really changed how he did business was the AirPods. The fact that I was like the destroyer of old headsets and cords. They would get caught in things. They just were so inconvenient, and now there's these little things that stick in your ears. Great sound quality, great audio quality, and they're just always there, and they're not inconvenient, they're not getting in your way, and you can walk around with them, and you can inaudible They were amazing for me, and I didn't... I thought it would be good, and I didn't realize how good to the point where if I leave them somewhere, if I leave them in the office and I go home, I was like, " I can't use my phone until I go back and get them." It's gotten to that point.

Daniel: Totally.

Eric Boduch: Which is totally crazy. Sometimes it's unexpected too. Keeping on the iPhone thread, when they came out with Siri and the little fingerprint to open your phone, I was like, " Oh, fingerprint, that's nice, whatever gimmick kind of thing. Siri, I'm really excited about." Turns out, I never really got into Siri because it never really worked really well and never really did quite enough. But the fingerprint thing was just changing because now I don't have to type nine characters all the time. In fact, I like it way better than the current one of there's no way to get to the home screen. There's nothing like... That easy navigation, that easy turning things on, that easy work with a mask, right? I was like, " Really wish I could get that back."

Daniel: I know. Just to build on that AirPod bit that you just shared a second ago, I would totally second that. I have Bose noise canceling headphones. I've always really enjoyed them for working, and I got AirPods, and mostly I was like, " I take a lot of calls, it'll allow me to go outside walk around, take calls so I can just walk more during the day and sit and stand less." I got the AirPods. In this latest model, I don't have the crazy headsets. I just have the AirPods Pro, but they have a feature on it where you can choose between transparency. It does kind of... Either you hear all the sounds around you even with the AirPods in, you hear nothing around you. We have a two- week- old at home now, and so at night now I'm getting a lot less sleep than I used to, and I need to be listening for cries and just stuff more often. One thing I just discovered the other day is, man, what a lifesaver it is to have this transparency mode on AirPods, because if I had my noise canceling headphones on, I'm not going to hear the baby, not going to be a bad dad. But now I can listen to music, watch a show, have the transparency on. When my baby starts crying, I can immediately go over to it, and that's something we're again asking an unexpected question. People hate pulling their headphones, putting them on, taking them off. Well, what can we do to allow people to keep them on and still interact with the world around them? I think again, that's an insight that likely came from serendipity rather than some perfectly constructed brief.

Eric Boduch: Yeah. No, absolutely. Absolutely. Anyway, inaudible our last question. Three words to describe yourself.

Daniel: Maybe curious, obsessive, and optimistic. I think just to expand on all those really quickly, but curious for me I think it's just such an essential quality in life especially in the time that we live in where anything you want to learn about is seconds away in a web browser. I think it's a superhuman gift to be curious and to lean into that curiosity. The optimistic side. I had a really great chat recently with Kevin Kelly, who's the founder of Wired, and he's done a bunch of incredible stuff. But in my mind, he's one of the most optimistic voices about technology. For anyone listening who's at all jaded about the recent Facebook stuff for tech... breaking up big technology companies or is technology good or bad, I highly recommend you go and read Kevin Kelly's What Technology Wants because it's just this beautiful optimistic take on what technology can do, and how it fits into our evolution and in our future and why it's so important. Then the last piece, obsessive. I recognize that there are good and bad qualities to that. But for me, when I'm working on a problem, I just love coming back to it, having it in my brain all the time, thinking of little tweaks on it throughout the day. I'll leave it there.

Eric Boduch: Awesome. Well, thank you. This has been great. Thanks again for crosstalk

Daniel: Thank you so much for having me on again.