Design Thinking for Data & Analytics (How to Understand Your End-Users)
MindSpeaking Podcast Episode 11 - Brian T. O'Neill, Founder of Designing for Analytics
▶️ Watch the podcast with video on YouTube:
Timestamps:
00:00 Introduction
00:24 Introduction of the guest
01:33 Who is Brian T. O'Neill?
05:32 What have you learned about working with engineers
10:50 How can Data professionals think more about end-users?
18:50 Should we work involve designers in Data & Analytics?
24:52 Is there any place for aesthetics in design for analytics?
33:01 Lessons from your music career
37:54 Writing: what you want to write vs. What your audience likes
44:01 How do you balance your company and being a musician?
47:01 What are you working on at the moment?
50:51 Main takeaway for listeners
53:11 Where to follow Brian T. O'Neill?
54:24 Subtractive Design
55:38 Conclusion
🎙️Listen to your favorite channel:
Introducing Brian T. O'Neill
Gilbert Eijkelenboom
Have you ever been frustrated that people were not using your dashboards or your audit data products? Then today's guest Brian T. O'Neill has something to tell you. He has a technical background, but it has been a product designer for over 20 years. He's a consultant speaker trainer, working with companies all over the world, specifically data leaders to help them leverage the principles from human centered design. He's the host of the experiencing data podcast and next to all of that is also professional musician. So we talk about the human in the loop, how we can understand our end users and make a big impact with your data. So let's dive right in. I hope you enjoyed this episode, about the human side. of data with Brian T. O'Neill. Hi, Brian. Thanks for joining us today.
Brian T. O'Neill
Hey, what's going on? Good to be here.
Who is Brian T. O'Neill?
Gilbert Eijkelenboom
I'm really good and I'm looking forward to this conversation today. I was like speaking to people who have a diverse background to combine different fields of interest to see what they look and learn from each each area. Yeah, I'm looking forward to to dive in here. But to start, of course, I know you a little bit. But my listeners also are interested in hearing from you about your background. What's your story? So can you tell us a bit about that, please?
Brian T. O'Neill
Oh, sure. Well, my I have an interesting story that has nothing to do with data or technology at all. So I'm actually my training is as a musician, and that's one of my other careers. So I'm a classical and jazz percussionist drummer. That's what my degree in School is in and back in college. I was doing exposed to the internet through some guy in my dorm and kind of got me into that whole world. And long story short, I picked up web design as a career while I was in music school, and eventually moved to the east coast of the United States and ended up working at startups and then in the enterprise space, while also having my music career and 20 years later, I've been here doing both of these things. And over time, I was a product designer and user experience designer and various both enterprise companies, small software startups, range of companies, but I seem to get keep getting drawn into these fairly technical domains. With companies doing work in the analytics or information design space, a lot of financial services, worked at Fidelity and JP Morgan Chase and E trade and a lot of stuff with early live streaming of charting, technology for traders, stuff like that. And yeah, for some reason, those architects and engineers seem to like to work with me if I seem to kind of get them. I understood that world and got involved with data visualization. And anyhow so I decided to really consciously focus on that space about six years ago, since I my portfolio and work and client base have kind of been in that space unintentionally. I decided to double down and say, you know, there seems to be a need for a different approach to making all this analytics and data useful to people. And data vis isn't quite enough and analyzing the data isn't quite enough and modeling, it's not quite enough. The last mile is where a lot of these projects die. And so my focus is really on helping companies that are using machine learning and analytics, particularly in software. Tools, applications and what I broadly call data products to increase adoption of these tools in a meaningful way, largely by focusing on the humans in the loop. Looking at these are experience and remembering that I tell my audience there's no such thing as a business like a business is just a collection of human beings. And so ultimately, what user experience about is like making a change or an impact on someone's life that's going to be using some of this technology. And if we don't create a meaningful change for the individuals that use this stuff, then we're really just in rehearsal. There's no concert. We're just rehearsing and practicing our chops of building models and building dashboards and building tooling and thinking that we're creating value because the paycheck usually rolls in unless you're the senior leader, and then you've got probably a shorter timeline. So it's the outcome piece and the last mile which is where the rubber hits the road. And this is this is where projects either succeed or fail, because you can't get the business value if you don't get through the adoption piece. So that's really my passion is trying to help people close that that gap when building self service applications where there's not going to be a presenter there to take them through what the data means. And all of that. Instead, the idea is, oh, they're supposed to be able to use this application or tool to make better decisions, and we're not going to be there to tell them what to do. So how do we design that in a way that it's useful and usable? And ideally, then they make decisions with it and therefore the data actually drove some business value. So that's that's kind of a nutshell of my journey. Two minutes or so.
What have you learned about working with engineers?
Gilbert Eijkelenboom
Awesome. You do a lot of work in closing, closing that gap. And you mentioned that engineers like working with you. And I think there are a lot of people that find it difficult to work with engineers that they struggle or especially if they're not on the engineer side, or you say you kind of get them. What do you think is important for engineers, and collaborating with them?
Brian T. O'Neill
I mean, collectively, I don't think I can stereotype quite enough between like, the data crowd and I've kind of learned over the years like I was talking to my buddy Mark Matson who's been on my show and works at Teradata. He's the lead Distinguished Engineer one of these guys that gets basically gets paid to like go and think and find holes to fill in problems to solve and he's like, no, no, no, no, the data world's really different than the software engineering world. Candidly, I haven't really seen that difference yet. And maybe some of you will argue that there's clearly a difference between kind of the mindset and the thinking and my experience, I kind of see a very analytical mindset a very, tends to be sort of black and white approach. To thinking a lot of times they don't understand the human piece super well as to why someone doesn't find something obviously easy to use, or why would they not use this and the game they're playing is different. And so when the example I give all the time is this idea with like data science, we talked about modeling and creating predictive models that technical accuracy is the thing that you're scored on in competitions and sometimes in school and you can write a paper about it. And in business, sometimes the 51% accurate is a home run, because it's better than a coin toss. And since time started, has made us decisions, flipping a coin, and now they have a little bit of an edge. We got a 1% edge here that a little bit more than time we're actually right if we trust this information, that could be a big win, but letting go of the feeling that I put sloppy work out there, this model could be so much better, letting go of some of that baggage I think can be could be difficult for and part of the reason I think to that and again, I'm really broadly generalizing Dr. met wonderful engineers with great product sensibilities, and I've watched what I call the flip happens, which is when they've worked with diner designers enough and I start to hear that question. They're asking in meetings that have nothing to do with the architecture, how it's going to be built and instead, how are we going to know we did a good job like, do we really need to add that knob? Do we really need another filter here like once we took it out? They start thinking subtractive ly, they start asking what the tasks and scenarios are that users are going to use this technology with. They start changing the questions and when I see that button to be I call that the flip. And it means they're no longer just talking about building the code and getting the requirements down and kind of what I call the drive thru delivery McDonald's model of data projects right like drive thru to I like to dashboard for the side of French fries. And would you like to supersize? Yes, please and then on to the next year a ticket? I have no idea where that drivers going with that food. I don't know if it tasted good. I have no idea not my problem. I'm just here to deliver the food through the window and then the next car dries up. That's not the audience I'm talking to and if you're happy doing that, and you're you're successful doing that, that's fine. But if you're listening to the show, and that works for you, great. You should probably hang up now because that's not the audience that I want to talk to today with you. I want to talk to people who are they know that the technical work is good. They probably have really good technical talent, but there's something missing and that last mile where they don't understand it, they they don't know how to use it, or the status quo wins the game every day. The status quo continues to beat them no matter how much better the thing that they made is, or even sometimes we gave them exactly what they asked. And then they said no, that's not what I meant, or they didn't use it at the end or the data was too scary. And so they went another they didn't really want to face the truth. All this kind of stuff. If you've got great tech talent, and you realize that there's something in that human integration part that's missing and sometimes it's called Change Management and I we can talk about that. I think that positioning as well as operationalization that's another one of the words that can't stop designing these things, these ideas, change management and operationalization. That stuff from a design perspective, we would consider that part of the requirements. You design all of that solution from the beginning, and you test this stuff along the way, using prototyping methods. failing fast, increasing learning velocity, you don't do it at the end of the project. You don't stop visualization on at the end. You don't think about the dashboard last you think about the people at the end first, and then you work backwards from that. The people that want to get better at this. That's what I want to talk to today with you.
How can Data professionals think more about end-users?
Gilbert Eijkelenboom
That's really awesome. I would love to have and I cannot stress enough how important this you would be this in data. And you also mentioned the flip starting people starting to changing the questions and looking more at the human side. Well, what have you seen what have you noticed what have you seen that people helped make that flip or how have you seen that development in people? What do you think helped them to make that flip?
Brian T. O'Neill
so candidly, I the I think the fastest way it happens is when they're exposed to working with designers and they've been exposed to the process of working with designers, the thinking that goes with it, when they start to see that it's not all about the ink part, the user interface part the visual part that we tend to we usually come to data versus what the first word that comes into mind when we think about design. So I think when that exposure has happened, that's a big part of it. That the place I usually like to try to start is to get empathy. Get people exposed to this idea of empathy in the business context, which I think is sometimes a little bit foreign, but getting engineers and technical stakeholders exposed to real users actually trying to use these solutions in the wild. There's nothing better than that to create change. And it's the difference between looking at a study that said, you know, we surveyed 150, you know, finance operators, and they said the dashboard was useful. That's self reported behavior. You don't know what to change. What like, Okay, what if it was 79%? Like, what would you change that that kind of feedback doesn't help us make any difference? We actually watch this salesperson or whoever this model is something like a marketing analyst whose job is to run ad campaigns that spend the money smartly, right. And we're building a dashboard that's supposed to tell them about their ad spend or something like this. Watching that person do their job using this tooling that we built for them that's supposed to help them seeing where they fail. Individual human beings monitored by a team of makers, and I'm going to call all of you designers, because there's no such thing as no design choice. So if you're putting out stuff into the world that other people are going to use, you are already a designer, you can't run from it because there's no results. No no choices, right. So the game is really about getting better at design. Not to become a professional designer to get paid at it. But to make sure that your data stuff actually gets used. That's what the game is. And that's what I'm trying to do is like just enough to get your great technical work used and relied upon and so they say, Gilbert, that was awesome. Can you give me more? Can you help me with this? Now they're coming to you with more strategic stuff because they've seen the value of the work. And the way to get to that is to understand what's wrong with it. And by putting people observing people trying to use our solutions ideally at lower fidelity, earlier stages of the design, not at the end, not in Tableau with final data, not in Power BI not in your app way at the end when it's too late to do anything about the feedback we get, but earlier in the process, and when you see people struggling and saying I don't know what this number means. I have no idea what a p value is like. I just want to know if I spend more than $5 per click. Like that's a yes or no like in this tell me and you've shoveled pounds and pounds of evidence at them. No conclusion, no insight, just lots of evidence that they're supposed to then go make a decision about should I spend $5 or not? Like, that's my question here. And you see that friction about what they're trying to do. And then maybe you watch them mentally try to what we do with the mental math model, right the eyeball analysis and they're flipping charts and downloading data and putting it into Excel and you're scratching your head like oh my god, the tool does all this for them. And they're going back into their old habits because they can't figure out how to make sense of that information. That creates change, because all of a sudden, it's like your work has sort of just been judged. And it's not used to judge. It's the design that's being judged. And just like we're not testing the user, we're seeing the design. And that feedback can be so clear. It's hard to argue with it when you when everybody's watching this person saying I don't get it. And I just I probably would stop and just go back to the old way of doing it. It's really hard to argue with that kind of feedback and it kind of stings a little bit the first time you get it, but over time at least, at least for me. I love this feedback because it what it does is it's I'm learning something and it's telling me where I feel like this is weak, but I just I want the competence of seeing someone else get through it to learn something to say, yeah, that little model works that I do that which like, like I didn't think they would understand what this index was. I was really concerned that they the index would be this big thing. They totally got it. That's a pattern I can maybe we can reuse that pattern. I just learned something about the world today, at least a world of my audience there. And so it's it's kind of exciting. I kind of like it when my stuff fails because I like to be not feel so confident that Oh, I know what all the right design choices are because I'm a professional designer. It's the learning that that? I don't know. It just kicks off something for me. So I think that empathy exposure to real people both in the research phase the prototyping phase, getting those people involved early and often a great way to do this. And this can be difficult, like especially if politics, the climate, that the team may be more as a servant. They're in a servant role, where there's not a lot of credibility there. And the business owners like if we're talking about and I'm talking about enterprise, no context here. This can be hard because the, the strength it takes sometimes to ask probing questions and to have the time to go do this and like why do you need to talk to me for an hour and even to set up an interview? We don't don't even want to do it. Like a lot of times, you know, the analytical types that they don't really go talk to a bunch of people and listen to their problems and all of this, those people don't. Really they're kind of like, is this worth my time? Like, I thought I already wrote a requirements document. Like I already told you what the dashboard needs, like why do you need to talk to me there's a lot of hurdles that Ross to get to get this thing going and I don't I don't deny that that can be difficult. But if you want to keep playing yesterday's scrimmage over again fine, but there's a reason as you I saw on your training, I was living training PDF and you had the the stats about high failure rates in data science and analytics projects. And it's like to me, it's like, yep, that's the Manchester United Spain game. We're like, replaying all and yesterday again, again, again, again, and you can keep repeating the way you do stuff yesterday. You're gonna get yesterday's results. So I'm saying for aspirational leaders who believe that creativity matters, and that the human loop matters. And that outcomes are what really matter in the business context, not outputs, not making the things but making the change that comes as a result of the things that we made. If you're playing that game, too. I want to help because I don't know how to help the other people I don't I don't know how to how you keep creating outputs that nobody used and expect to get something new. It's just not you might get lucky occasionally, but you're gonna you're not going to know what to recreate. Right. So excited. For the outcomes that matter, not the output.
Should we work involve designers in Data & Analytics?
Gilbert Eijkelenboom
Right? Yeah. And I see a lot of frustrated people who say people aren't using my work and my work is so good look at the accuracy. And I think it's a big, big problem in the market. And what you opt for is people getting better at design right? And that makes me think, should we also work together with designers in that process? Or she will do all the steps ourselves as a maker? Yeah.
Brian T. O'Neill
Well, a lot of teams don't. I think the journey depends on you know, budget appetite for change culture, all these things. So a lot of teams designer, like why don't I have them in my data team. If you're starting with that, then at best, you're probably looking at getting training and trying to upskill your own team. Other teams that maybe have some more exposure to they're a little bit more digitally native, whatever that means, or they've they have people that come from the software sphere. Having a designer in the team is just part of the three legged stool of doing great building great data products. You have technical leadership, usually in software engineering, it could be a data scientist, but you have some kind of technical leadership. You have product management leadership. And you have defined leadership. Those three things are the cornerstone of building great software data products. And I guess the weird thing for me having come from that world is how that's not normal in the enterprise data teams when they are building applications and tooling, and some of them are using Power BI or Tableau or some kind of BI tool that what we're not really building software, we're taking data and putting it into tools. And I'm like, the user doesn't care whether you hand built, they don't even know if it was something you coded or it's a tool they don't know they're in Tableau. I don't know they don't care. Right. That has nothing to do with it. So if you're building solutions that are on screen that involve maybe online and offline things like imagine a factory floor or some kind of service design thing where decision making is just part of the step but there's some real world decisions that get made that involve software or looking at screens. Well, you're doing software development, you effectively are so you can copy the way Silicon Valley does it or the way mature software companies do this, or you can choose not to, and there's a reason why the early hires are in product management and in design, most any kind of company that involves humans on the loop, like our customers are human beings. And we need that the users to understand how to use the stuff in order to value it. They usually have that skill set involved. So you can either hire for it or you can train for it. And I do think that non designers can have people who are not professionally trained designers can learn this stuff. I've watched it happen. I
About another study that was in the same solar system of studies like this and it's like it's getting worse
Lessons from your music career
Gilbert Eijkelenboom
even worse Yeah. And I think I think a lot of people without knowing I think your metaphor in the beginning a lot of people without knowing are behind the counter you know, shipping out hamburgers and being proud of the number of burgers they they sell and deliver every week, but they don't really know what makes the difference for them. And I think a lot of people fail to build trust or at least build trust early because it takes so much some time. Right to build immediately that you wouldn't trust if you ship something good. And it's all started with the user. Yeah. I think it was very insightful. I also would love to talk about a little is your detected your message, because I believe that there's always so much to learn from different fields, your decision, a musician, or entrepreneur, your own company and you're a designer, you're maybe also a data person. How what have you learned from music that you can apply in your work in data design, or entrepreneurship?
Brian T. O'Neill
It's a great question. I think. Probably the number one thing is getting caught I'm comfortable with degree of risk. I'm comfortable putting stuff out into the world that's not going to work. I've done it with the current business I'm in I'm trying to like right now I'm putting together this data product leadership community. I don't know the first thing about starting a community and go read what other people do. I get some advice from some other community leaders. I've asked my audience I tried to get feedback from them on what they like and don't like about these kinds of things. Why do what I'm doing, but I feel like there's an audience here that wants to connect. So I will put it out and try it and see what happens if it doesn't work. Well, what did I learn? And do I if the timing wrong? Is the idea wrong? What's wrong with it? Learn something from that and I'm, I'm comfortable putting that stuff out and it's the same thing as an artist, especially when I'm doing my music work kind of spreads from being a freelancer where I'm hired to come in and play with orchestral parts. There's some of my individuality that comes into that, but a lot of that work is very execution and precision oriented in that kind of space. Last night, I played with a big band, big band and that's there's a lot of interpretation that goes with that and some of it might be good and and I don't know what's gonna happen maybe I'm gonna get called back to play with them again, that uncertainty in the end the risk and putting out records of my own material and shipping and then saying, Dear World here it is, and in that case that a little different because it was probably tangent, you're talking about art versus design here for a second. As an artist, as a musician. I'm not trying to get followers and trying to get I mean, yes, I would like to build my audience and I want my music to connect, but my goal is not right. To compose music that I think people want to hear my job, the music that's in my head, and hope that it finds the right people that say, that spoke to me. It's not to try to change people into one. It's an artistic expression, and it's what Brian wants. That's also true for visual art in my in my opinion. Of the artist has a statement that the artist matters. That's why the Leonardo da Vinci painting is worth so many painting, and it couldn't be looked the same. But if there's a different story with art with the VINCI painting, because it's his because he touched it because of the story. That goes with that. Design is completely not that design is all about them. It's not about Leonardo, it's about the person it's for the total difference here and this is a problem with designers too because a lot of artists and so early in the career, this is something we have to listen for. Designers says that we're not hiring artists. An artistic designer is fantastic. But we have to be careful that they're not there to try to put their primary goal is declare their mark on the company their individual thing because that's now about them. That's fine, but that's the wrong game that that game you play at home, in your own business and I'm doing your own thing. But here we're playing a different game, and our game is about and so everything I'm talking to your audience about to listen to you, it's about them, not you and your team it's about them and service mentality. And that's the art of design is really about connecting with them people and making it for them about making a difference that way. We have time as designers, facilitating groups of people getting them to think about them and focus on those human beings because that's the path to the business value and that's my kind of riff on our inverse versus design. And what I've learned there, I guess the comfort with ambiguity.
Writing: what you want to write vs. What your audience likes
Gilbert Eijkelenboom
Yeah, and I love two points that you're mentioning because when I was younger, I was thought about risk, as in financial risk, right? If you start your own company, you're not sure if he's gonna work out. But I think the intellectual risk is a much bigger component actually in entrepreneurship because you need to put yourself out there and do a presentation and then not having enough content yet but not sure if it's gonna work out that do it anyway. That's what you do as a as a musician as well. I was I was wondering because I, I like to write it for business, but also personal personal writing. And I put it out there and often when I write something I thought deeply, it doesn't resonate as much with my audience compared to a more business like piece. So sometimes I'm thinking, Hey, what should I write? How should I write this stuff that converts or should I write a piece that is really more about me or expressing what is in my head? What are your thoughts on that when you look at writing
Brian T. O'Neill
I'm still learning this myself, but I I know that you probably know a lot about habit forming. And so I really sold on this idea of writing as a way to develop the expertise. And getting good at writing happens as a result of writing, you don't premeditate and then you write it down, which is kind of what I thought the process was. So you have to first become a bad writer before you become a good writer. So this is probably ironically, the habit that I've probably stuck with the longest so I've been publishing since June of 2016. It's 20. It's almost June now as we're reading, so for six years, every two weeks and I have not missed a single tuesday and last night it was 11:35pm. I almost forgot to publish. And so you got an email from my list about 1130 bio on May 10. Was because I could not I was still cooking. I'm starting to cook my dinner. It was a long day. I stopped dinner I turned the burners off and I went and wrote because this just I can't break the streak. Now. It's habit. And over time, I'm hoping I'm getting better at writing. And I don't and one of the challenges that we do is that we don't always know if it's working. And this this is true with technology too. We all have users we don't always know and they don't always tell us the negative feedback. It's hard to know. And then occasionally you get these anecdotes, you get responses from people when says I pass this along to someone on my team, or this really like clicked and that's like the fuel that keeps me going. And so it's something that goes into the oblivion you hope it makes a difference and the best item to do is is to wait for those little signals there to tell you where to go next, just some time learning about how to become a better writer. One thing I'm trying to do more is to have more in my writing and take more of a stand and that's why I told the listeners on this audience like hang up now if you want to do it this way. That's fine. That's a different game, though, than the one I want to talk about playing. And I mean game in the spirit of we're sort of all spending our time playing this game. And I want to work with leaders that think a different way that they understand the game that I'm putting out here. It's okay if it's not for you. I'm talking to those them that them over they're not put them over there. But these people over here and I'll track those people with my ideas and hope that they make a difference and it might not totally candidly Gilbert, I don't think a lot of data people give a Shi t about the work that I do. I think it's like it sounds vague and floaty and a little hand wavy and and it's like fine, and that's okay because you but I think some other people have seen what happens when these giant initiatives die for utility and usability and customer complaints and it all comes down to like what they're interfacing with. They don't understand the architecture and the plumbing and they don't Oh, my God, we migrated to the cloud and look at our our eye ops and look at last the ETL is load and all the technical stuff. They don't have any idea what that stuff means, but they do understand I have a station due next week. The numbers don't make sense to me. But that stuff means that you pulled together for me and I'm stressed out. I have a storage that doesn't tell the story that I thought it did or not because I need to be ready or make a decision. We're making a giant investment here should we or simply not what does he tell us? To can we automate this thing or not? Like what's the risk? What's the risk if we don't do it? What do we not even know about this thing? I don't know what data science I mean, you guys are like magicians to me. Help me understand what the risk is. That's when you understand that this human stuff really doesn't matter at the end of the day. I think change can happen there. And so that's that's what I'm trying to write to. And it's a journey is learning. I'm not a professional writer. I feel like you we all have the impostor syndrome I'm sure I'm sure a lot of people working here maybe feel that if you don't, if you're not self employed like we are we're totally tangent on this. But I got Asperger's syndrome was real. But the best framing I've heard for that is when you're feeling that it means you're bumping up the edge of the up against the edge of the unknown. And you're starting to push your comfort zone and what you you think about the world and it probably means you're now doing some real new work and that might not be meaningful, that might not matter or it might really important, but you're now starting to do something new and you're not playing yesterday's match again. And I and so I try to jump into that even though it might be the lizard brain is kind of like Tony and this is yes, and this is going to work and blah, blah, blah and the other. The other part of me is right. No, you're you're you're scratching at the door, and you're pushing and you're pushing, and that's and we have to Seth Godin calls. It's like dancing with the resistance, you know, and that I really liked that framing because it's a positive framing instead of a negative framing. I'm kind of just jumping in, because I'm like, Well, I don't I don't have anything else to lose and I don't know. Part of the creative process. Yeah,
How do you balance your company and being a musician?
Gilbert Eijkelenboom
that's, that's great. And I really liked that go to you. Because he's a master at verbalizing that that feeling right and feeling of fear and unknown and then dancing with anything going for it anyway. It's a fantastic habit to build and get more people to to do things and dare to to do what they want to do. You have a lot of things on your plate right you have your own company or a musician you have a you have a child of the life that plays in the same orchestra, I believe. Yeah. And how do you balance all that? How do you combine it or how do you make sure you're not getting stressed and anxious? What do you do? Um,
Brian T. O'Neill
to be honest, I thought it's, I'm not great at managing. I have a fair fair amount of stress that I carry with me and the lie, the anxiety comes with me. I don't share that with my audience because that's not helpful to them. But I have that I'm not gonna lie about that. I would say that probably helps me assistance. So systems, automation of low low task as much as I can. Having habits like you know, when I published the podcast is out this Tuesday, the next Tuesday, right? Podcast right podcast, right saying over and over again, the timing might move a little bit, but there's a rhythm to it. It just becomes part of what I do. So I try to have for that kind of stuff. I use a lot of automation where I can where it's safe, and it makes sense with some things in my in my business that I mean Zapier. I don't know what I would do. Without Zapier, I would need to hire somebody without Zapier to like manage my calendar and all this kind of stuff. So I try to use those kinds of tools to offload as much of that stuff as I can. But yeah, it's probably hard and it's hard to keep the velocity of with this many balls in the air all the time. But I think being organized and having sets of time where I block out time that's that's something I do is block the calendar out for certain kinds of work. And yeah, just kind of learning how to tune the schedule, right. And making sure I'm saying no to the right things is a big part of it, too. And I think that's something data teams also need to be are we working on the right projects, and what do we say no to here? What's the risk level if we get this wrong? And I think part of that is not just to you deciding but it's working with the customers and clients and again, I'm talking mostly mostly to the enterprise teams at this point. I think learning how to say no, as a way that's kind of a gift which is it's no because we're not going to deliver on this. Yes, we can build a dashboard. But can we build a tool that's going to help you make decisions about price? Not in not in three months. So yeah, the dashboard is easy, but not the decision making you want to do with the dashboard that part's hard. So do you want a crappy dashboard or do you want help? Making decisions? Like, what is it and really you want the decision making what you want? That's a nine month project and so we're gonna say no, right now. This is a gift and it has to be framed that way. Exactly.
What are you working on at the moment?
Gilbert Eijkelenboom
I like a frame it's very positive and focuses on the other person right? focuses on them and their desired outcomes. Alright, so we're close to the end. I would like to ask a few last questions. So first of all, what are you working on at the moment? What is something you would like to share about your work right now?
Brian T. O'Neill
What am I working on? So right now I again I think I mentioned earlier, I'm trying to start this data product leadership community. So the idea here is that I think product, the idea of product of the different framing, it comes out of the software world. It's not present in the enterprise, data science and analytics community a lot. And I think the framing of thinking about products and for and I'll tell you what, I what I when I say that what do I mean? It means two things. Products almost implies someone's going to buy something and use it and they're paying money. They're handing over money because the value is there. So even if customers don't pay you to use your tableau dashboards or your internal application that you wrote, or your shiny app, or whatever it is, How good could it be? Or would it have to be to get that people would actually pay to use it? What if we had that mindset that like, this has to generate revenue for the data science team or else it fails? Literally, like someone has to pay us a license monthly seat fee? What if we approach the work like that? How good would it be? What would we do differently? That's the first part. And the second part is that products, unlike projects don't end like products are on a continuum. And projects kind of usually have an endpoint to them. And I'm not saying that every project that you do can go on indefinitely. But if we think about it as products and shipping, small increments of work, and something that someone again, might be willing to pay for, it's a different way of approaching the work. And it suggests that like this MVP mentality, which is minimum viable product, which I actually like minimum valuable product, this kind of approach to small change, learning quickly reacting to feedback, and evolving it over time. And when they say this is awesome, or Yeah, it's good, but like, we spent a lot of time with this tool. Could you make it easier or could you bring this other thing and yeah, we can do another iteration and make that better? It's this product mentality. And so for people who think this way, and maybe you don't have it all figured that out, but you feel like that's the right kind of approach to this to starting to make a difference in the work that data science and analytics can do. That's what it's for. It's for people that are leading teams that do that kind of thing. So the community is on is on my plate as well. As you know, I teach a training seminar called Designing human centered data products, largely for non designers, so data science leaders, analytics leaders, and I have an opportunity to do that at twi conference in Munich coming up in June, but I need to squeeze that down into a half day format from my current eight week format. So that's what my other project is. And this actually gets to this idea of subtractive design and you were talking about this earlier, and I meant to mention it but one of the great things that approaches to design is like not just the pencil but the eraser like what can we take away? How can we reduce and remove to make something easier, more useful? Could we take data out that's actually creating noise or creating friction, or it's evidence that's being shown at the wrong time and it's changing the story that we really want to tell. So the eraser is also one of the key tools of design. So I'm in the middle of starting to erase part of my seminar and bring it down into a half day in person format, which is also new for me. I've never actually given this training before in person. It's always been digital. Because I do all do remote work. My whole business is remote. So I'm looking forward to jumping in and hoping hoping the Germans are up for a gringo from Boston to come in and work with me so yeah,
Takeaway for listeners
Gilbert Eijkelenboom
I'm curious what your experience will be like being being in person again. And like now it sounds sounds sounds like a lot of different exciting things you're working on. So what what is what one big takeaway you want listeners to take away from this episode today? Yeah,
Brian T. O'Neill
well, there's two. First of all, it's outcomes, not outputs, that matter and that's not my friend and there's a book on that I haven't read and I forget the author's name. But you got to remember that really, the impact of the work comes from the outcomes of the work, not the outputs. So that framing is so critical. And if you don't understand that, I bet if you stand back and look at your projects, you're going to see that yes, we built this model that nobody used it. So tactically for a conference. Yeah. It's worth writing a white paper about did it make a difference? No, because it didn't create an outcome. First, that's the first one and the second one is that you can't get to like this whole data community. I'm going to rant here for a second business value and insights and all this kind of crap. I hear this I've been hearing this for since I got into this field. And what I what I rarely hear spoken about is that how do you get to business value which assumes some human beings made some changes and created some kind of impact on revenue or cost or some business metric? How do you do that if those people never interact with the solution that was built? The data tool, the widget, the application, the model, the whatever it is, if they're not using it, how can you possibly get the business value? So you can't you can't just jump from data to business value and skip over the human adoption piece. First, let's target the adoption piece and the utility and the usability piece at the point at which it becomes it has a chance of becoming business value. I don't know how you do that unless you're talking about fully automated systems which still have some human beings involved. But most of us are not working on completely automated AI systems. And that's if you are great, and if you don't need humans, great. And if everyone's happy, that's nice, but I don't think that's the majority. So you have to think about this. If you ever want to get to business value. I don't know how you do it. Consistently at least you might get lucky some of the projects might be easy, and that's fine. But consistently doing it. You got to think about that.
Where to follow Brian T. O'Neill
Gilbert Eijkelenboom
Absolutely. Absolutely. I completely agree. Brian, thanks so much for for being here today. I I also want to ask you about where people can connect with you or follow you. I've been part of your newsletter for maybe two years by now. So yeah, so people can sign up for your website. Where can people follow you or connect with you? Sure, sure. Yeah, the
Brian T. O'Neill
website is designing for analytics.com. So yeah, I have a mailing list insights mailing list there. And also if you join the list, you'll get updates on my podcast, which is called experiencing data. So if you don't want to join the list, but you want to listen to the show, it's on all the major platforms just typing experiencing data. Best place to probably connect with me is LinkedIn. That's that's where I'm most active. I am rhythm spice on Twitter. I'm not super active on Twitter, but like that, feel free to connect with me there.
Gilbert Eijkelenboom
Fantastic. Well, thanks. Thanks so much, Brian. For me, it was very exciting to talk today with a fellow human being who really cares about the human in the loop and and making it work right. A few things that stood out for me was the not the pencil but the razor. I'm going to keep that in mind. I think it's a it's a great quote, and I think it applies to too many situations. So thank you for for doing your work and for being here today. And spreading your insights. Yeah, by the way,
Subtractive Design
Brian T. O'Neill
Gilbert Can I just tell you one thing about subtractive design a grader and I just heard this example. That's like my favorite example. So if you've ever taught a little kid how to ride a bike before, if you notice that the new bikes that you buy for a little kids don't have pedals, because what was the problem with riding the bike? It's not the balance of the pedals with moving the legs and keeping the feet on the pedals. So what did they do? They removed something they didn't add training wheels to the bike, they took the pedals away to get the kid comfortable with the learning the balance of these first and then you go in you add the pedals later and that's a great example of taking something away to make it better. So I just wanted to leave your audience with that. What can you take away?
Gilbert Eijkelenboom
For example? Yeah, maybe in a few years, I will get kids or try it out with your own kids. Yeah, I'm curious to see how that's gonna work out. Yeah. All right. Thanks so much, Brian. All right. Thanks for joining today, and we'll speak soon. Take care. Thank you so much for having me. Thank you.