Today I’m going solo on Experiencing Data! Over the years, I have 
worked with a lot of leaders of data-driven software initiatives with all sorts of titles. Today, I decided to focus the podcast episode on what I think makes the top product management and digital/software leaders stand out, particularly in the space of enterprise software, analytics applications, and decision support tools.
This episode is for anyone leading a software application or product initiative that has to produce real value, and not just a technology output of some kind. When I recorded this episode, I largely had “product managers” in mind, but titles can vary significantly. Additionally, this episode focuses on my perspective as a product/UX design consultant and advisor, focusing specifically at the traits associated with these leaders’ ability to produce valuable, innovative solutions customers need and want. A large part of being a successful software leader also involves managing teams and other departments that aren’t directly a part of the product strategy and design/creation process, however I did not go deep into these aspects today. As a disclaimer, my ideas are not based on research. They’re just my opinions. Some of the topics I covered include:
Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill, and today I’m doing a solo episode. This is the first time I’m going live to talk to you directly, myself. And today’s topic is going to be—well, I’ve actually titled it, “Good Versus Great: What Distinguishes the Best Enterprise Product Management and Data-Driven Software Leaders with Data Science, Analytics, and Machine Learning.”
So, I wanted to dig into my experience working with different product leaders—and by the way, when I talk about product leaders, today, I’m going to bucket together, anybody who’s in charge of a software initiative, whether it’s a commerc—if you’re in the tech industry, and you’re developing a SaaS product or some type of commercial software for sale, or you’re working inside a business, and you’re responsible for a digital experience, it might be a free tool that’s still customer-facing, or even something for your fellow colleagues, other business departments, et cetera. Point is, you’re in charge of delivering some type of value and not just building out the tech, so the buck kind of stops with you. And so, I’m going to call all these people ‘product managers’ for the purpose of this episode because the titles are all over the place in my experience. I’ve had clients that generally fit into the, “We have analytics software, some kind of data-driven product or solution,” the titles and people that have come to me range from software architects, data science and analytics leaders, people that are on the engineering side—this is particularly true in enterprise software areas where engineering is often running the product function—directors of operations, GMs, and of course founders, and chief data officers, chief experience officers, chief product officers, et cetera. So, I don’t want to focus this so much on the titles, but more the activity of being in charge of producing some type of value.
And since we’re talking about data products, this often means decision intelligence or decision support. So, with that in mind, I’ve got about 10 facets, or 10 things, that I think separate the good from the great, and so I’m going to bang through those in just a second. I also wanted to mention in this episode, I will primarily focus on the success of the product or the technology itself as it relates to value in the eyes of the customer or user, not so much on the people management aspects of being a product leader, which of course is a big part of it. If you’re in charge of running a team and hiring a team. This often can mean hiring designers, hiring engineers, hiring technical experts, whatever it may be.
This isn’t always true outside the tech industry, the departments and structures can be different, so I’m not going to really talk too much about that aspect of it, but more on what I think separates the good versus great product leader with a real focus on the product piece. So, without further ado, I’m going to jump in. And again, these are my personal perceptions, having worked with many different leaders, a lot of very strong technical people that may have come from a different background, originally, and they’ve, kind of, landed in that position, as is true with many product leaders; they didn’t get formal training. They kind of landed there and may have started in a different area. So, just my personal experience, and here we go.
So, the first one is vision. Great leaders have a strong sense of strategy and vision, but they retain skepticism until their work has been validated by customers through direct conversations, observations, research, and/or the market itself. I don’t think all product people have this skill. I think this is especially true if you’re not the chief product officer, if you’re not the top of the ladder. Perhaps it’s a very complicated or large-scale product where it may have different aspects.
Like, “I just run the analytics portion of this overall service,” which itself might be an entire application, a very complex thing, and you just own a part of that. But I still think that vision is important, even if you’re not the top of the mountain. And sometimes even the person that’s at the top there, I don’t feel like all leaders necessarily have that sense of vision in mind: the daily work can sometimes get in the way. So, I think one of the—the first thing here is really that sense of vision for what the product needs to do, or what value means to the customer. They have something there that’s special and unique, and they’re passionate about that.
The second one here is that ‘PM’ is a vague term, meaning two entirely separate jobs. So, what I’m getting at here is when a true product person hears the word PM, they’re not talking about project management, and they think project management and product management are entirely different jobs. They’re not even in the same solar system. And they are not the same job, by the way. So, there’s a real distinction here, and I think, again, a good product manager may be doing a little bit of both of these, but a great product manager is really focused on the product, and not as much on the project.
There’s often overlap here, sometimes in much larger organizations, you may have people that are directly, of course, responsible for program and project management. But the lines are somewhat blurred here, and I think, to really excel here, you need to be focused on the product aspects of the job more than the project ones; it’s easier to outsource the project part of the work. I think no one can replace the product aspects of that role, and so that’s another one of the things that distinguishes the good from the great.
The third one is embracing diverse teams and tapping expertise when necessary. So, great leaders look at user experience professionals, designers, engineering, tech leads, data leads, whatever it may be, they look at them as critical partners as opposed to subordinates. And they also seek to partner with engineering and technical people who have the ability to separate implementation from strategy. They know which people to pull in who can wear the right hat at the right time. This is especially true with complicated or complex enterprise software, data products, there’s so many technical things to get right, that it’s easy to lose sight of what the big picture is.
And so I think the great product managers know, they just have a sense of who the right people are to bring into the room and maybe which people are probably not the right people to have in the room when it’s time to do ideation, when you’re kind of in this innovation mode, when you’re thinking about the overall strategy piece, they just kind of inherently know which types of people to tap for those skill sets. And this is partly about knowing that they need to avoid building a solution that’s too informed by assumption and not enough by research and intimate connection with the people that are going to be served by the technology that’s being built. And particularly here, I’d also say that the great product manager who, perhaps, has direct experience in the domain, or the area that they’re currently working in, doesn’t assume that their own experience is necessarily that of everybody else’s. So, they retain a sense of skepticism and they seek to validate those assumptions and bring in outside people whose full-time focus and role may be in those areas.
So, let’s—I don’t know what it is; maybe it’s, like, health care. Whose job is it to predict the number of beds or resources that we need, and make sure that the proper supplies, and that we’re routing patients properly or whatever. And maybe there’s like a distinct product for that. And let’s say that this product owner here used to do some of that work themselves.
Well, that can be fantastic because they’re bringing a ton of very deep domain knowledge about what it’s like to do that work, and that can be really powerful. But the issue there is, you only know your own experience—and maybe know that of your peers—but you don’t necessarily represent what everyone else needs or does. And the way you might have done it through your earlier career doesn’t necessarily line up with how your current customer does that work. So, I think having that sense of skepticism, even when they have a sense of what the job entails of the users that are going to use the solution, I think that skepticism is really important.
Then number four here is a relentless focus on customer empathy in the problem space. And you might recognize some of these things I’m talking about because I think the line between product design at very senior levels and product management, especially when we exclude the sales aspects, marketing, pricing, and some of those pieces, the line between product management and design is somewhat vague here, so you’re probably going to hear some of what I talked about here as sounding familiar. And to me, that’s normal because a lot of these roles and responsibilities need to be shared; they need to be owned by the team. So, again, a relentless focus on customer empathy in the problem space. So, good leaders focus a lot more on building solutions, but often without a rapid enough learning cycle to understand if they’re improving.
So, they may be focused on shipping the sprints on time, shipping the code on time, something is coming out on time all the time. So, they’re great with the time management aspect, they’re great with showing, “Did we make progress?” Well, they measure the easy thing around progress, which can be things like showing features being built and that type of thing. I think that the great product manager in this—the distinction here is that the great product owner is eager to know what the gaps are and where their solution is lacking, and not just looking for reinforcement that the solutions they’ve put out are right. So, they’re always kind of—again, this kind of comes back to that sense of skepticism about whether or not are we actually doing a good job or not, and they’re constantly seeking to validate that. And so that deep sense of customer empathy, and really understanding the problem space, there’s something distinct between the good and the great product manager in this area.
The fifth one is that they smell like product people. What the heck does that mean? I don’t know. I just know that there’s a distinct quote, “product-ness,” about the great product leaders that I have worked with. This is true even if they came from other disciplines: sales, marketing, analytics, engineering, whatever the heck it is—and this is very true because so many people in product did come from some other area first.
What is the product-ness? Again, I don’t know exactly what it is, but I know, when I see a product manager in title only, they spend most of their time doing the thing that they learned first, or they spend the time in the current product management job doing the thing in their previous gig. So, what do I mean? It means, “Well, I’m now in product and I’m running the overall product, but in the past, I was an engineer.” The good product manager often is being dragged or pulled back towards the engineering thing because that was what they did before.
Or if they’re in marketing, they spend a lot of their time focused on thinking about how to market the product, but they’re not involved enough in the actual product creation and innovation piece. They’re not in the weeds with the designers, participating in all the millions of little detailed decisions that overall determine whether or not any of this stuff actually matters or not. And so I think being aware of their natural pole or tendency to go backwards and to kind of be drawn back into where they came from, I think being aware of that, and kind of remembering that the job is is very much a generalist kind of job, and they can’t get too locked into one aspect because that’s what their roots were in. So, the great product manager, I think they’re very strong generalists, and they enjoy the challenge of finding needs within the market, or within the business, and satisfying those needs, and not just building out the tech.
And this is true both in commercial software, but also if you’re working inside a business, this is that—that strong product person is asking questions. They’re not just taking in requests for dashboards, or some application, or we need some machine learning, please send it over here to this department. They’re not just saying, “Yes, sir. How many data sources would you like us to use when we build the model out?”
They’re not asking questions like that. They’re relentlessly seeking out the problem. “Why is this person asking for this dashboard? Why are they asking for an AI thing? Why are they asking for this? What’s behind that?” They are seeking out those needs, and there’s something distinctly product-ness—product-like about that whole behavior. And I can just—I typically can smell it.
So, I know that one’s a hard one if you’re trying to aspire to what it is, but I think the main signal here is to not get pulled into your old job and your old training, and to remember that if you’re the product owner—the product manager—you have a leadership position, you need to be more generalist in your mindset, you need to let your subordinates—if they report to you—or the people that at least own the different facets of building out a successful technology initiative, whether it’s engineering, analytics, data, design, marketing, whatever, you need to let those people own that and empower those people to make the decisions, even if you kind of know what that job is, and you have very strong opinions about how it should be, ultimately, I think you need to empower those individuals and remain the hub of the wheel: you can’t go down one of the spokes too far. So, anyhow, that’s my kind of idea what product-ness is.
The sixth one is great product management leaders believe that design matters. And they also understand that user experience may make or break the entire endeavor. As we move into AI, this becomes even more important because now when we talk about design, we’re talking about ethics and we’re talking about the possible impacts of our solutions on people that are not even in the room. So, for me, ethics is just design at a larger scale. And I think great product managers are aware of not just, now, satisfying the business and satisfying the customer, but also that third tier of people, and they understand that this isn’t something you do at the end; you don’t tack design on to the end of the project, to make it quote, “look good,” or to try to fix the visualizations, or the charts are too complicated; we need a data visualization expert, or whatever.
The great product managers are thinking about the experience from the beginning, often because they’ve been through a process in the past, or a project in the past that did not go well because this was an afterthought, and so they ended up building out a bunch of technology that didn’t serve the people who needed it, to do whatever it is that they needed it to do. And when that make it or break it thing is adoption, or the tooling is too difficult to use, or the value is not obvious, or it was too hard to sell and explain what the value was, these are all signals that something’s wrong with the design and the great product management leaders are seeking to get ahead of that not to deal with it at the end, I think we, kind of, talked about the aspects of like waiting until the end, bringing in the finished product to the designer than asking them to clean it up or make it look good, et cetera. It’s totally the opposite of that. So, I know this is probably something new for people who are typically working inside an internal organization and servicing other lines of business, particularly, perhaps in a non-digital native company.
I know that may, perhaps, sound weird, or it sounds like it’s not necessary, but I think if you go through a process of building out months and months of technology, or a large—especially true in the enterprise large businesses—and you find out like this model never got used. We did all this stuff, we created a predictive algorithm or whatever, and it can help us tell us whether or not to turn right at the corner or turn left at the corner or whatever it may be, and no one actually uses that. The business continues to just make decisions the way they used to do it. Well, you just spent a lot of money and you didn’t provide any value there. And understanding that the human aspect was critical to the technology being successful, that’s what the great product manager understands is that a lot of the challenge here is not just the tech piece, but it’s the behavior change.
It’s the adoption. And it’s that word that I kind of hate with machine learning and AI, which is ‘operationalization’ which I just don’t like that because it sounds like it’s something you do after you’ve done—like, “We built the model, and now we have this model. Let’s go operationalize it.” To me, this is like, “I built a wheel for a car in isolation. I’ve no idea what the car is going to do, where it’s going to go, who’s going to drive the car, but here’s a wheel for you.”
The chance of the wheel fitting properly on the car and actually enabling the overall result—I don’t think that’s the way to look at it. I think you need to think about the adoption piece as being inherent to the solution. The usability, the utility, the adoption, those are integral facets of the solution, and it’s something you do at the beginning. You don’t try to do this at the end of the project. So, that was number six: great product managers believe that design matters and UX may make or break the entire endeavor.
The seventh one is great product managers see a human challenge, and I think good product managers often see a technical challenge. So, great PMs see the pursuit of value with AI, analytics, and data products as being human challenges, often around trust, adoption, decision making. If you think about those three words that I just said, those have nothing to do with, do we have the right data? Can we actually build this? And, do we have the pipelines in place? Are we using the right models? Is it accurate enough? Et cetera.
Those have nothing to do with that because if you’re building a human-in-the-loop system—especially with these very advanced analytical techniques—the trust and the adoption and the human decision making based on what the tooling or data was to provide, that is the point at which you make it or break it. And so the great PMs really frame the problem as a human one, and not necessarily a technical one, I think the good product managers are going to be adept at the technology, they may be good at like managing the engineering, they’re good at completing a technology initiative that has been well spec’ed out, and there’s an assumption that we need—the model needs to be 62% accurate, it needs to be performant like this, it’s going to be used by this person. And it’s kind of a… there are some bullets and success criteria that you can kind of hit, but they’re looking at that as being the ultimate goal is just kind of checking the box on those aspects, but they’re not really inherently thinking about this as a human challenge and not necessarily a technology challenge.
And I would say another aspect between good and great, I think good product managers are living in the trenches—and this is especially true with enterprise software—they’re living in the trenches with their engineering and technical counterparts, trying to unblock them trying to get sprints, completed on time, sometimes falling back into the project management mode, or just kind of thinking about managing up. Like, “I’m building a space shuttle. We own the booster rockets,” or whatever, “And I’m just relentlessly focused on just my part, which is the engines, and whatever, the booster itself. It’s not my job to think about the other piece.”
Well, I think there are places where—and I understand what systems engineering that not everyone can be focused on the entire big picture here, but I think it’s very easy to get lost in these technical implementation details, and to spend a lot of time just on that and never really pulling your head out of the sand to look ahead to see, “We’re in this ocean. There’s no wayfinding here, we just have open sea. Are we actually still going towards the island or the port that we originally set out to, or not? How do we know if we’re on track to do that?”
I think the great product manager, they have some wayfinding. They know that the boat is still pointed in the right direction, and they know how to check that and see that, whereas the good manager, I think, is just kind of like, it’s on autopilot and they’re assuming that it’s going to hit land, or the island, or whatever the next port of call is, they just assume that they’re going to get there and so they stay below decks keeping the engines going, and that, to really bully the analogy, I guess, here. So, that’s my take. So, the great product manager sees a human challenge, whereas the good product manager, I think, is looking at it, often, as a technical one.
Number eight, good product managers have vague definitions of success. I’m sorry to say that, but I find that to be true a lot. Whereas great product managers can often provide distinct, quantifiable measurements of what success looks like for the product and for various iterations. So, they might understand, ultimately 12 months out, this is what great looks like based on our assumptions. Now, in the next four months, this is what a successful iteration looks like.
They know how to define success in a way that the team can totally get around and understand. One area that I find is sometimes difficult across the board with product managers, and sometimes why people come to me for consulting help is the translation of vision into what I call a design actionable strategy. So, a design actionable to me means that the team that’s involved can all picture what a viable and valuable solution looks like, usually from a very brief document, even if the pictures in their head of what that solution is aren’t necessarily the same thing, since there hasn’t been any execution yet. This translation from vision to strategy is really important. And we don’t need to have everybody aligned on what the solution looks like, but we all understand what the problem looks like, how we’re going to measure it, and we can all picture what that valuable, viable solution looks like in our heads.
I also think great product managers can often explain to me in just one to two sentences what problems or needs is this technology going to solve and for whom. They can do it in a distinct, short, succinct way. I think good PMs often struggle to do this succinctly, or they load up the strategy with tons of buzzwords, and of course, it’s going to say it has AI in it, and blah, blah, blah. I think the ability to be very brief and clear about the problems you solve—dumb it down to me, explain it to me like a five-year-old so that I can understand, “Oh. This is what you’re trying to do. This is how it sucks to be this user today, this is the challenge they have, and oh, I can see, in just a couple sentences, you’re trying to fill this particular gap.”
And I think it clicks. You know what it sounds like when someone comes to you, they’re like, “I’m trying to do X, Y, and Z.” And it’s just very clear immediately, and it’s not a long word salad of explanations filled with buzzwords: “We’re going to use blockchain to do whatever. And then we’re going to have a machine-learning-based something.” The strategy is loaded with tactical assumptions about how you’re going to actually do that. So, again, to summarize this one again, good PMs have a vague definition of success, whereas great PMs can provide succinct and often quantifiable measurements of what success looks like for the product and its iterations.
Number nine, great PMs have lived the pain of their customers either directly or through significant research driven by empathy. So, their knowledge is not only driven by third party research alone, but they’ve had direct interactions with customers, and they deeply understand the needs of those customers and users. This could be, again, because they might have come out of—sometimes you’ll see someone in customer support might eventually move into a product management function. Those people can be super-powerful product managers because they know what it’s like; they know what the frustration sounds like on the phone; they have talked to these people, they have a deep sense of empathy for what an angry or really disappointed customer sounds like, and it’s through that one-on-one conversation, the one-on-one touch, the one-on-one observation of these people trying to accomplish their job, or their work, or their tasks, or making the decisions they need to make. That’s the difference there.
It’s not just, “We bought some research that backs up this technology that we would like to try. Like, “We think we have this amazing AI model that’s going to do X, Y, and Z, and here’s this market need that we’ve found.” But they haven’t actually gone out and talked to anyone. It’s just a hypothesis. And so the good product manager is kind of like, “Well, let’s throw this out there and see what happens.”
And while I am a fan of prototyping, and I am a fan of shipping fast, and I’m a fan of fast, rapid learning, which can be designed, build, test, learn, and refine, I am big on that, that’s not necessarily the same thing as going in with no strategy: “I’ve never talked to a human being before prior to ever showing anything.” You’re taking lots of risks, spending time building out stuff when you haven’t had a single conversation with somebody, or you’ve talked to one or two people and you assume that you now understand that whole world. So, again, deep empathy, they’re actively participating in what I would overall call UX research. They’re not just passing that off to the research team, but they’re in the call. They’re in the research sessions.
They’re often—often what happens in the tech industry, and especially places that are organizations that are design mature, is that the user experience group—and I’m not talking about market research, I’m talking about user experience research—the UX researcher will probably lead the initiative, but you might have a product owner who’s sitting in on all of these studies. And the UX, people are going to eventually provide an overall recommendation, or an overall report on, like, “We talked to 12 different people, here’s what we heard.” But the great PMs are sitting in these calls, and they’re not just on their laptop and whatever, doing other work, they’re actively participating in the listening and the observation. So, they’re not just passing this off to the design team to do because what happens then is that the information often doesn’t get used.
That research information, people start to doubt it. It’s like, “Well, you only talked to five people.” They don’t have any of that empathy that gets formed when you actually participate in a direct contact, or at least you’re observing from the one-way mirror or whatever; you’re at least actively participating in that session. It’s not the same thing as just kind of reading a third party report and you weren’t participating. It’s not the same thing.
The color, the voice of the customer, the emotions that come out, the level of frustration, the patterns that you may hear, you may see different patterns that the UX people don’t see. Or maybe you have engineers or technical people there that are hearing other patterns. Part of the reason we do, we talk to multiple people, right, is to listen for common themes or patterns here, but we don’t always all hear those things the same way. So, anyhow, so that’s my number nine, I’ll just restate it again, great PMs have lived the pain of their customers, either directly or through significant UX research, driven by just a deep sense of empathy for the people that they’re going to serve.
And then number 10, the last one here is along with focusing on accelerating learning through prototyping, great PMs—especially ones building data-driven, intelligent solutions, so this is for the analytics product people out there if you’re working with machine learning and focusing on producing decision-support solutions—the great PMs are really focused on producing indispensable support for the people that are in need of help. Good PMs are focused on the application, the outputs, the models, the analytics, the things. The outputs and the outcomes are not the same thing. I think with data products, it’s especially important to focus on the decision making aspect: the thing that happens in the last mile. Will this be used? How will it be used? What’s required to get the trust? All those human things we, kind of, talked about earlier, they are relentlessly focused on the decision support aspect.
Did we create useful, usable, indispensable decision support? Or did we create a software application, a model, an output, some code, a new algorithm? Those are things, and those things are easy to manage. But that intimate focus on the decision support piece, it’s a different focus, and that to me separates the good from the great. A simple example here might be focusing on, “Is this model going to be completed on time? What are we getting—we’ve stood up a private cloud, you know, and we’re now in the cloud, and I heard we’re building these models, and they’re going to do something for us. And is the accuracy can be really high?” and all this kind of stuff.
The great PM is looking at, “How fast can we learn whether or not the model or this AI solution is actually going to get used for decision making or not?” They’re looking out much further, they have the big picture in mind. They’re not focused on some of the technical aspects there of making sure they can kind of report up that we’re checking the box on all the technical things that are supposed to go right. And there are many of those, and I’m not saying those things aren’t important, but there’s a big difference here between producing human-centered decision support, and simply producing the technical outputs that theoretically allow you to create human decision support. They’re not the same thing. And the gap there is the design and the experience, right? It’s understanding what the glue is that connects the outputs to the outcomes that we seek.
So, anyhow, I hope this episode was useful to you, I was excited to, kind of, do a solo one for you. Just to give you my personal experiences. Again, this is not based on any research. This is just my experience from having worked on a lot of technical data products, and analytics tools, and decision support applications, and kind of getting a feel for over time what really separated those clients that had a real sense of vision in their role as a product person versus ones that were good, but maybe didn’t have some of the characteristics that I think really set apart a strong product leader. So, I think if you’re someone that has a different title that’s doesn’t necessarily have the word product in it, but, again, you’re responsible for delivering value with data—whether, again, that’s internally for your colleagues or other business departments, or if you’re working at a tech company where your solution, your product actually is a commercial piece of software, it doesn’t matter so much, that piece.
I mean, of course, I understand: Yeah, sales, marketing, there’s all these other aspects if you’re building commercial software that are also important—that’s a big part of the job—but the spirit here, I hope, came out to you about how to think ahead, how to, I don’t know how else to say it, except kind of pulling your head out of the sand, and having the big picture in mind, and understanding, are we on the right path to achieving the goals that we set out to do? Are the goals aligned with what the organization needs and what the people and the customers need? Are we relentlessly focused on customer value, not with fluff words, but we can, again, as I talked about earlier, we can very specifically call out what does it mean to be successful for this piece of technology that we’re going to build? You can state that in brief words and sentences that everybody can understand, everyone can understand how we’re going to measure those things. That’s really, I think, the thing that you want to try to aspire to be, whether or not you have a title of product in your job title or not; if you’re the person in charge of making sure this data initiative turns into a digital experience that’s really valuable, then you need to have that product mindset, in my opinion.
So, that’s my take for this episode of Experiencing Data. If you like this format, please send me an email [email protected]. I’ll probably be doing some more solo episodes in the future, and I hope you’ll consider leaving a review for the show. If you’ve been a listener for a while, I would really appreciate it if you’d leave a comment there, and just a quick star rating in iTunes—or Apple Music—Apple Podcasts, as it’s called now. That really helps spread knowledge about the show and helps push the mission forward here, which is to really produce more human-centered data products that aren’t driven by technology, but they’re driven by putting stuff out into the world that’s meaningful, whether it’s going to make money, or save money, or whatever, but it’s also something that’s looking out to producing value for the people that are going to use these things. So, thanks for listening to the show. Look forward to being back with another episode in the future. So, stay tuned.
“Great leaders have a strong sense of strategy and vision, but they retain skepticism until their work has been validated by customers through direct conversations, observations, research, and/or the market itself.” – Brian
“Great leaders look at user experience professionals, designers, engineering, tech leads, data leads — whatever it may be, they look at them as critical partners as opposed to subordinates.” – Brian
“[Great product managers] have a sense of who the right and wrong people are to bring into the room during ideation and discovery. ” – Brian
“Great product management leaders believe that design and UX matter.” – Brian
Every now and then, I like to insert a music-and-data episode into the show since hey, I’m a musician, and I’m the host
On this solo episode of Experiencing Data, I discussed eight design strategies that will help your data product team create immensely valuable IOT monitoring...
