Do you ever find it hard to get the requirements, problems, or needs out of your customers, stakeholders, or users when creating a data product? This week I’m coming to you solo to share reasons your stakeholders, users, or customers may not be making time for your discovery efforts. I’ve outlined 10 reasons, and delve into those in the first part of this episode. 

In part two, I am going to share a big update about the Data Product Leadership Community (DPLC) I’m hoping to launch in June 2023. I have created a Google Doc outlining how v1 of the community will work as well as 6 specific benefits that I hope you’ll be able to achieve in the first year of participating. However, I need your feedback to know if this is shaping up into the community you want to join. As such, at the end of this episode, I’ll ask you to head over to the Google Doc and leave a comment. To get the document link, just add your email address to the DPLC announcement list at https://designingforanalytics.com/community and you’ll get a confirmation email back with the link. 

Links

• Join the Data Product Leadership Community at designingforanalytics.com/thecommunity
• My definition of “data product” is outlined on Experiencing Data Episode 105 
• Product vs. Feature Teams by Marty Cagan
• Email Brian at brian@designingforanalytics.com.

Transcript

Welcome back to Experiencing Data. This is Brian T. O'Neil, and I have myself on the episode today. Dropping a solo one again for you. It's been a little while since I've done one of these. But today, there's gonna be two parts to this episode. The first part is based on an article that I recently sent to my DFA Insights mailing list, containing 10 reasons your customers, stakeholders, users, whoever you're serving, and your data product work. Why they don't make time for your initiatives around building the data product that's actually for them.So if you can't get the time of your stakeholders and business partners to help you, help them, There's probably a reason for that, or two or three, or, I actually got up to 10 and I stopped there. So I wanna share some of these with you. Some of them might hurt a little bit, but I'm hoping that hearing these from an outsider, from me might help you see your situation differently so that you can change the culture in which you're doing your work, and hopefully get that time from them so that you can show them how you can serve them with your work.

And then in the second part of the episode, I'm gonna talk about one possible solution and to update you on the status of the data product leadership community that I first talked about in 2022. Last year, as of the date of this recording, you may have heard about that community on the show. And on my mailing list and, and frankly, I have to be totally honest, I just missed the deadline I had set for myself on this, in part due to my workload, but also because of other reasons that I'm sure other founders and entrepreneurs who might be listening can relate to.

For example, is anybody gonna join? And then if they do join, are they going to participate? Like I'm in a lot of different, like, slack based communities where there's very little conversation going on. A lot of it's, it's just not of any particularly good substance either. Most of it I just don't pay attention to anymore. I don't know if that's just a thing right now, if people are burned out or what, but that's a big concern for me. I don't want to create another space like that, which is just, kind of, noise.

Also knowing what it means for the community to be successful. I'm still figuring out what that means for both me, but largely for you based on all the conversations I've had to try to come up with something that, an actual community that will serve you. This is hard. You know, starting communities is a known difficult thing. Everything I've heard about it, it's very, especially at the very beginning, it's very hard to get it going. Once it's going, it's much easier. But obviously there's growing pains there, which is kind of true, if anything. So in a way, I'm less concerned about that now, I guess because I'm used to starting stuff as a, as someone that, I guess I call myself a creative, you know, between my, my music career and the work that I do here on the show and my consulting in the design space, I'm used to starting new stuff from nothing. So that part's a little less concerning for me now. And frankly, I have no idea what I'm doing here. I didn't set out to create a community here, but there seems to be interest in it from some of you listening and people on the list. 

So I'm gonna talk to you more about that in part two. I may refer to it as the DPLC for short, just because Data Product Leadership Community is a really long award, and I do plan to retitle that at some point. But I do need input from you in order to get it off the ground and to make sure it's off on the right, at least on the starting trajectories on the right course there. But we'll get into that shortly. 

For now, let's jump back to part one here. So why are those pesky customers, clients, and stakeholders, why won't they make the time for you to get what you need from them? I might say the word requirements. I always put that word in quotes. I think it sounds like someone's got a list and your job is to deliver the list back to them. I may use that word, but that's not really what I'm talking about here. But I know ultimately, most of you listening here are trying to deliver really outstanding machine learning and analytics applications that will make them happy, that will serve them, that will create value for all of the humans in the loop, your business, their needs, et cetera. Sometimes you're all in the same boat together if you're on an internal team. In fact, this list will probably resonate a little bit more with those of you that are not in the commercial tech space where you're selling data products, actual software. As you are aware, this is probably a little bit more aligned for those of you working in internal data product teams. So anyhow, let's jump into it.

So here's some of the reasons why they may not make the time for you or they give you vague requirements, or they might push you to a subordinate or say, you know, I've even seen really large enterprises where there's like an entire team that's set up that's supposed to do this work. And so you're always dealing with a middle person who's relaying ,they're relaying feature req, essentially feature requirements back to you because they're interpreting the needs for you. And it doesn't mean those people don't know what they're doing. It just means that the creators and the makers, and I'm gonna, I may call you designers on the show, whether you have a design title or not, if you're ultimately the person that's making this thing and determining what the last mile looks like, you are the designer effectively. So if you're always dealing with, with people sitting in the middle, that's going to be a challenge because you're getting filtered information, you're not getting primary information. 

So why, let's jump into that. So I've got 10 of these. The first one, they don't associate your work or the team with delivering value as defined in their eyes. So, I'm not talking about being on time with deliverables or commitments or dashboards or models and whatever the outputs are. I'm talking about the value or the outcomes that they want that are associated with those outputs because as you know, you can deliver a technically right model, a technically right dashboard or whatever, and it still might not end up getting used, let alone creating the value that they were hoping for. And it may be that that value is not clearly stated until too late or even after you've delivered the solution. And then you start to, oh, so really what you wanted was X, not Y. Well, we just spent, you know, three months doing Y. The point here is that value is always in the eye of the recipient. And if they don't associate your worker team with delivering that value in the past, then they may not want to make the time going forward because they don't feel like you're capable of doing that. They may see you as more - as just technical people who build stuff. Maybe once in a while something good comes out of it. But they're just not associating you with the value. So that can be one side of it. 

Again, some of these might hurt. I'm not trying to hurt anybody's feelings, I'm just trying to kind of be an outside perspective so you can look at the frame that you're operating in and decide if changes are needed. Okay? So, keep that in mind. There's definitely love coming from me to have all your backs in this work that you're doing.

So secondly, They know that your work represents the truth in cold, hard facts, and that truth can be threatening. So the facts, as you know, in certain environments, facts can be threatening to some people. They can require us or the stakeholders to say, Hey, you know, that didn't work. You know, our assumptions have been off for a long time. It's hard to admit that if you've been operating in one reality sphere and the data is saying something else, that goes against what you know, someone who's possibly put a lot of time, effort, or reputation or social capital behind a trajectory for the business or whatever. And then the data is challenging all of that. 

I mean, imagine like, oh, here's this marketing plan and we should direct all of our spend here. That should be done this way. And then you get some data to back up that decision and it's not aligned with that. That's really hard for someone to swallow. Not everybody is going to be ready to hear that. So I think you need to be aware that this is something that needs to happen upstream before we actually go get the answers. We need to understand, what kinds of decisions are we ready to make? What might we do with this kind of information if it comes back this way? Again, I don't wanna get too much into solutioning here, but again, number two, your user, your stakeholders, your clients, your customers. They know that your work represents. The facts, or at least the facts as closely as we can get to them, um, with, with some kind of data back to evidence, and that could be threatening.

The third one, they believe that you, being the data wizard that you are, should be telling them what they should be focusing on, looking at, exploring, believing, and that they're not really integral to the solution. In other words, “Wait, you're the tech person. You're supposed to know how to do this. I just, I don't know how all of that machine learning and AI stuff works. It's magic. So I don't know why you need my time to help you out.” I'm kind of role playing them, right? 

This is especially true for the data scientists listening here, who I think my assumption here, I'm speaking on behalf of other people here, but my assumption is for a lot of people working in the business who are not working with data that the analysts already is, how they come up with the numbers and back up all this stuff is probably somewhat understood, but the data science thing is another whole leap away from just the reality that most people are operating in. They don't know how you do that work. It sounds very technical, it's not magic, but it's something along those lines. And so they may not understand why they need to be part of it, because the assumption is you're an intelligent person, you should be able to figure it out. Doesn't the data just tell you the answer? Can't you go figure that out? Like, isn't that why you're here? That may be the frame that they're operating in, right? They're not really understanding how they are part of that, in this idea of designing with our customers and users and stakeholders, not for them.

This is a framing I've heard from, I forget where I heard that first it was from a designer, but I really liked the "with" versus "for." We designed with our customers and users, not for them. It puts them in the creation process. They are not just recipients, they are part of the creation. So anyhow, that's the number three.

Number four, they believe that their delivery of requirements in the form of solutions for you is sufficient, even if their requirements do not represent a clear problem space for you to actually tackle. So in this book called, uh, the Mom Test, I've been reading about doing product research with customers. The author, I think it's Rob Fitzpatrick's book, he makes an interesting point. The customer, users and stakeholders own the problem. You own the solution. So I really like that division there, where they get to voice anything they want about the problem, and they kind of get to own that space. But they don't get to tell you what to make, right? You get to determine the solution, but likewise, you don't get to create the problems or decide what they really should be doing or what they really should be paying attention to. You first need to really focus on the problem that they see in their eyes that they want to solve. 

So, for example, you know, your stakeholder may say, I need a better dashboard with best in class visualizations powered by AI. And sometimes that may be true, but that's actually not a problem. That is a solution or an idea for a solution that's masquerading as a problem. So you need to get behind what's behind this dashboard. Why did they say best in class visualizations? Why did they say powered by AI? There's all kinds of information behind those hints. And they're, most of the time they're doing this because, I think they're trying to help you know what to build for them. And frankly, there are a lot of technologists that will find that statement very helpful and useful because it tells them what to do and they don't have to think about it. They can simply go, begin building and feel like, “Hey, I gave you what you asked for, you should be happy.” But I think the more mature people who have perhaps been working longer, you've probably been through that enough to find out that you gotta be really careful with what you deliver, cause people don't always know what they want or what they need. And so, our job is to really own the solution, but they need to own the problem and we need to help them surface that problem.

So anyhow, again, number four, I wanna restate that one. They believe that the delivery of requirements in the form of solutions is sufficient for you to do your work. Okay? 

Number five. They don't understand the cost in terms of time dollars or technology that building the wrong solution imposes on them or on you, frankly.But again, people are self-interested so they may feel that you could just redo it if it's not right, which may be true, maybe the iteration cycle is fast that you can do that and that's fine. The question is whether the hard cost or the opportunity cost matter, and can they be quantified in a way that the risk to their goals is quantified and clear. So I think if they don't understand how you going off on the wrong direction, which you can say isn't your fault because they didn't give you enough information, or they gave you the wrong information, they may not understand how that is going to hurt them in the future with technology debt that they're now going to be carrying along, or the cost of redoing it, or the fact people don't wanna redo it. There's all kinds of sunk cost bias we'll tend to kick in, which is, well, let's just keep iterating on it. Even if the strategy itself is actually flawed, the longer this kind of thing continues, and I'm sure people are in the enterprise space or not in their head, we've all seen those projects where it's now a year, it's six months in, it's a year in, it's two years in. You're doing a giant transformation. Nobody is gonna wanna stand up and say, we need to stop. This is going the wrong direction. We're just digging the hole deeper and we can't feature our way out of this problem. We can't just keep cha, you know, adding more technology, adding more tool sets, whatever it may be. The strategy is wrong because it's not getting us to the desired outcomes that we set forth.That's a hard thing to swallow. 

So I think letting your customers and clients and stakeholders understand how the wrong solution can hurt them will get them to spend more time with you. Uh, again, I'm getting into solution mode here a little bit here, and I wanted to focus kind of on the why issue. Why are they doing this, not necessarily how to fix it there. But anyhow, that's number five, that understanding the pain, the time, the cost and dollars or whatever the cost could be, the currency of that, how that can hurt them if you create the wrong thing because you didn't have the right information. 

Number six, your past solutions are too hard to use, or they're not useful, or they're not trustworthy. Again, that could be because at some point you or your team, you fell into the trap of giving them what they asked for instead of what they needed by surfacing those problems, especially those unarticulated problems there. If they've gotten back material that they can't use to make good decisions, it's too hard to use. It takes too many steps. If the status quo is just an easier way to go, if that's the general association they have with you, then they're probably not gonna make a lot of time there cause they're not seeing what the value is and spending more time working with you to try to give you whatever it is that you need. It just seems like a tax to them. So, the more you can deliver value, right, the more you can make your solutions useful and usable, trustworthy, the more those customers love the work that you're doing, the more they're gonna give you the time to keep making more of it. Okay? 

Number seven, they, and perhaps rightfully so, believe that you should know the business or their business well enough such that you shouldn't need to be, or they shouldn't need to be involved at the level that you're asking. So this gets into, frankly, do you know, especially if you're working in an internal data science team for example, or digital team, do you know how the business makes money? Do you know what its goals are? Do you know what the strategic objectives are from the C-level team down? Is your work aligned with that? Do you understand the domain that your business operates in, or do you just understand the data behind it, kind of in an abstract way? 

The point is it's important to know about this. And this happens in, I think, not just data science or analytics or whatever this happens in, I see it in design, I see it in engineering. There are teams and especially people earlier in their career, individual contributors especially, they're like, “I get paid to code. Do you need Python? I do Python. Do you need wire frames? Do you need UX research? Do you need data engineering? That's what I'm here to do.” And you need those people. We need all of that stuff. But over time, if you're gonna be a leader, especially a data product leader, you need to understand the business as well. How does it make money? How does it lose money? Who are the customers? Especially if your customer is an internal business stakeholder. It's not an actual paying customer because you're working on internal decision support applications.

It's really important to understand all of this, and especially when we talk about building human-centered solutions, where you've heard me on this show talk many times about this. Marty Cagan, even when I had him on the show, has this real issue with even calling, like for example, the chief marketing officer that you're serving with your machine learning models as a customer, you shouldn't be calling them that because that CMO is not paying for anything. Sure, they're funding some project that the data science team is doing, but they are not directly paying for the goods and services that your collective business sells into the market. So it's really important to be thinking about that entire ecosystem. Well, who are those real customers? Who are the affected third parties here? Who are the stakeholders, which might be our "business customer" internally. 

They might expect you to know more about this, and maybe they feel that you don't. And this obviously takes time, right? But I think asking really good questions, being inquisitive, these are all parts of that, and spending that time to get up to speed on this stuff. When you start talking in their language, you're gonna see better results. 

There's a kind of related one coming up on that one, which may be a little duplicative, that's number nine. But first, number eight. Your team is perceived as too slow to provide useful insights on the timeline that your users or customers, again, stakeholders, whoever it is you're serving, that the timeline that they're operating under.

So it may be that their time frame is unrealistic. But helping them to understand the trade-offs of speed versus say, accuracy and value. I would say that's part of your job, particularly as a data product manager, because as PMs, feasibility, desirability, the need, the timing, all this kind of stuff falls under your purview. And so I think it's really important for them to understand, like, here's a few different options. Like if this is a mission critical decision you need to make and you want data to back it up, how important is it for you for that information to be accurate? And you have to then just explain what that means.

Because information sounds like it is by default accurate. But as you know, there could be multivariate reasons why something is true or not true. So what does it mean to be 50% right versus 80% right? And I'm not even sure percentage is the right thing, but I think helping them see how the two month solution that you need has these trade-offs. The six month solution will take much longer, but it will have all these other benefits here. So what kind of decision are you making? What's the criticality of that decision? What's the impact if that decision is wrong? I think these are all things that data product leaders need to be having those conversations there so that you can get the correct requirements for the technology to be built. And I think data scientists can be really helpful with this because I think especially if you know what the data is that's underlying this possible decision, you may be able to contribute in really positive ways there. Especially if you're a data scientist and you're also the data product leader or manager or whatever you want to call it. If that's also your job there, I think that's a really powerful thing because you're gonna be able to surface, hopefully surface, these trade-offs in ways that maybe, someone else that doesn't have that lens wouldn't be able to do. 

So number nine, we kind of talked about lingo here, but if all that you're hearing about from your team are things like snowflakes and pipelines and fabrics and clouds and meshes and products and random forests and blah, blah, blah, you can see eyes rolling into the back of their heads. And even if they're not literally doing that, you need to know who you're talking to and what their lingo is. If their lingo is sales: cpm, reach attrition, customer lifetime value, average delivery time, whatever, number of patients seen per day, per nurse. I don't know what it is, but you need to be speaking their language. You don't want them saying, “WTF are they doing over there?” They don't care about how the sausage is made. Most people don't care about the sausage. They're self-interested. What's it gonna do for me? How is it gonna increase my revenue, reduce my costs, increase my status, whatever. People are self-interested, so if you want to deliver really great technology solutions and data products, you need to understand their language, the value in their eyes, but really literally in the words that they're using. Get comfortable with those words and maybe you need to ask some questions like, well, what is a sale exactly? What's a customer? And have gentle conversations about that. Because they may not understand that a customer at the data level can mean six different things. Like, is a customer that hasn't bought something in 10 years till a customer or not, or are they a prospect?

You can get to those conversations. But all the technology lingo, they don't want to hear that. And if that's all they're hearing about is how the migration to cloud is going, I can guarantee you migration to cloud doesn't mean anything to business users, to end users of applications, et cetera. They don't care. The people who might care about that are other IT stakeholders and I understand some of you, for example, if you're building a data platform, your customers may be technical people like data scientists who are trying to run experiments and it takes a really long time to get the experiments set up and they need to create an oper- you know, a workstation or an environment in the cloud and it takes forever. 

So yes, some people might care about some of those things, but in general, I think there's just a ton of noise in this space. I feel like most of the chatter that I see on LinkedIn and elsewhere, it's primarily about all the different technology aspects here, and there's very little discussion about the work that we're doing for the people that we're trying to serve and their language. And there's plenty of money to be made selling that software, those transformations and all of that. There's plenty of work for your team to get lost in doing and feel like you're making progress because we're 60% of the way through the migration, and we'll be fully cloud at some point. We won't have any more on-prem stuff to blah, blah, blah. Yes, that's all true, but no value has been created yet except maybe some cost savings are starting to come through and someone might care about that. But if all this data work, this migration, is part of a plan to enable better decision making for the business, and therefore to increase customer sales or reduce some other costs or whatever, they're not gonna connect that to the word snowflake or random forests or clouds or meshes or whatever. They're not gonna care. So if that's what they're hearing, they're not gonna make time. 

So think about the language and words that you're using, the diction, it does matter. And the more you can speak their language, the more they're gonna be paying attention. Even as simply as using somebody's name. There's literally stuff that triggers in the brain when people hear their name. It's the word people love to hear their most. So just use their name when you talk to them and whatever. “Rachel, is that what you were talking about? Did I get that right? What you were saying about the sales increase and the timeframe for that. Is that, is that what you want, Rachel? Or do we need to do something else?” Again, probably a bad example, but I'm dropping that name into the conversation, right? To make it clear that I'm connected to you. I'm listening to what you're saying. I care. Those signals can help build that trust and get people to give you the time.

And then number 10, here. You don't make them feel like you're on their side, whether it's because of that lingo or your approach, or how you make them feel or something else. You know, if you're seen as as much of a threat as you are an asset, that can be a challenge here. And that can come from subtle body language communication styles, whatever, or, you know, “I'm gonna get a million questions about this and you know, every time I contact the data science team, I don't have a million answers for them. I don't know how all that stuff works. I just need X and I wish they could help me do it.”

And so they need to feel like you're on the same team there. And this is especially true if you're all working in the same org, right? If you're in one of these internal decision support teams helping to serve the internal stakeholders there, it's even more important that, because you're living with these people all the time. You're seeing them every day, all that kind of thing. Well, you're not living with them, but you know what I mean here. How you make them feel, making them feel like you're on their side, not making them feel stupid if they don't understand if you're starting to use jargon or lingo. Nobody wants to feel dumb. Even if they, maybe you think they should know more about how SQL works. Or how, I don't know, Statistics are, but you know what? Some of those people maybe haven't taken statistics ever. Or maybe they took it 25 years ago and they don't understand it. So again, I think you have to kind of meet people where they're at. If you wanna get what you need from them to serve them, you've gotta meet them where they're at, and you've got to make them feel like you're on their side and then you can start to work through some of those, those challenges. 

Anyhow. Those are the 10. What the heck do we do about it? Well, this is part two that I mentioned earlier. There's a ton of different, these issues are pretty wide, that there's a lot of different ways you could tackle some of these kinds of things. They're all gonna probably require changes in how you do your, the producty part of your work. Changes that probably have nothing to do with the technical part, right?

Ultimately, customers, users, clients, they primarily interact with the last mile of your work. So it means that this last mile journey needs to be crafted with intent. And a product oriented mindset can help us focus on discovering and delivering what is valuable. It helps us find what's actually needed, the unarticulated needs and what is possible, all with that human in the loop framing, that lens right? And applying good design and UX principles and the creation of the solution helps ensure that those needs that we uncovered are actually met and that the experience is safe and it's usable and it's useful, and the business value is realized.

So design and product management, in my opinion, in the digital space at least, are heavily overlapping circles. If you're thinking about a Venn diagram here, and even if your solution has light on a GUI, on a graphical user interface, there is always a user experience. This is right even if you're building a data platform and your customers are technical people and they're gonna be interacting with a CLI, for example, there is an experience there and you can either craft that experience with intent, or you can let it be the byproduct of a bunch of other decisions, but there will be an experience there. So how much intent are you going to put behind that, such that the experience is delightful and therefore the value increases in the eyes of those users? Ultimately, the experience is going to be a factor in whether or not they actually use your solution, right?

So unless they're totally ignoring your solution, which is the worst case that could happen, right? There is an experience, and this product and design mindset will help you design one that's actually valuable to them so that you can get all that promise of value that's on the other side. So one way in 2023 that I'm trying to help you get ahead and develop more valuable and indispensable data products on a regular cadence is to find a group of like-minded people who are also on this journey so that you have a place to share ideas and wins and challenges and questions, of course. 

And while the topic of data product, the producty version that I've defined on this show, I think it was episode 105, if you wanna go back and listen, while data product is perhaps the hub of this wheel, the spokes of this wheel are the community, the people. My plan is to have those spokes come from a bunch of different disciplines, or at least that's what I'm hoping we'll see here. We'll have data science spokes, we'll have product management spokes, UX and product designers, technical leads. There could be data engineers in there. I don't care. I mean, I care. All of these roles though, can take the role of a product owner and champion a product oriented focus in how the work is done there. And they could all learn from each other. Because the best teams in the software space where a lot of this stuff comes from, the standard trio there is your product manager, your technical lead, and your UX or product designer. Those three facets are considered integral. I sometimes call it the power trio, although with data products, I tend to think that there's usually a fourth leg, which is the data scientist or some kind of data expert or data, SME.When we're building these solutions, that's a distinct difference from what the engineer, the engineering or technical lead on the project may bring to the table. So that trio becomes more like a four-legged stool. 

But anyhow, getting back to this idea of this community here. I've been mulling this over for a while, and my plan is to try to run this as a 12 to 16 month experiment. Tweaking it along the way and then stepping back and reviewing it after that period. Instead of thinking, it's easy to get into, like, this is like a lifelong commitment, and what if it doesn't work? I think experimentation is a really good thing and I wanna run it like that, and I hope you wanna be part of that and we'll figure this out together.

As for you today on this part of the episode, I wanna explain the outcomes that I hope you as a member would get after a year of participation. And of course that participation that comes from you, how much you are contributing, how much you're reading, how much you're giving back. If there's no participation, you're obviously, you know, not gonna get much value out of it. But there are six outcomes that I want members to get. Or it's not that I want it, it's more these are the ones that I've summarized from the conversations that I've had, from the round table that we had back in August of 2022, and I've put these into a Google Doc and I've posted that publicly, at least to my mailing list, et cetera. And I'm actively soliciting comments from you so that I can get that feedback before we launch. So if you wanna go there right now and see these, I'm gonna read them to you here in just a moment, but if you wanna see them, you can head over to designingforanalytics.com/thecommunity.

Just add your email to the form on that page, you'll get a confirmation email that says you signed up, but it will also have a link to this work in progress Google Doc here explaining what I'm about to read to you here so you can go and read this at another time. If you've already been on my list or you're on the community's notification list, just go ahead and rejoin it. It will resend the confirmation email every time you put your email address in there, so it's not gonna double subscribe to you or anything like that. So feel free to hop there and get that. 

So anyhow, back to these outcomes. Again, these are summarized from that round table chat that some of you participated in back in August. Also, various one-on-one emails that I get. I actually solicit feedback as soon as you join the announcement list. I do try to ask, why are you joining the list? What do you want to get out of this community when it comes out? I do read all of those and I do respond to all of them and try to have short dialogues, so that's where this is coming from, and frankly, I don't know if I got it right. So I, I need to know from you whether or not this summary of outcomes is correct. So please head over to that Google Doc, and drop your comments in there. And after I share the outcomes here in just a moment, I'll be also telling you about the actual features and format of the community so you can kind of picture it in your head. But I wanted to start with the value in your eyes, at least what I hope is in the value in your eyes. And there's six of them. So here they are. 

So in that first, again, roughly one year of participation, I'm hoping you've had a safe, supportive place to learn and then apply some new product or design knowledge that you've learned in the community to your own data products, your client projects, whatever it may be.That's the first one. 

The second one is that you've adopted some sort of routine user or customer exposure program, some kind of regular behavior where you and your team, the key leads on your team, are regularly exposed to real end users on a regular cadence. Again, this is to further a human centricity in the work that you're doing, but ultimately it also will help you deliver more value, but you have to be having that exposure time on a regular basis. So I'm hoping you'll get that you'll start to make some kind of change to implement some kind of program or regular behavior there. 

The third one is you've been able to adopt some experimentation into your work, so shorter iterations, showing incomplete work, being willing to start over when things don't work.

Again, just like I've mentioned, this is literally me dogfooding this right now. I am also running this as an experiment. It's not forever. It's for now, it's, let's see what happens. Let's jump in. Let's have some milestones in place. Let's have a plan. The plan can change, but adopting that kind of experimentation and learning mindset, I'm hoping you get that.

Four, you've contributed a case study or some lessons learned, a webinar, some kind of progress or accountability updates back into the community. Primarily something of substance that another member could benefit from. So again, this is that you putting something back into the community part. Because obviously, the community is nothing if everyone is there to just soak up and learn from others, but nobody's contributing, it's going to be a ghost town. I actually had a very specific question about this, about whether that feels like a tax or a benefit. People I think do want to contribute there, but I was, I'm not sure, like is that, does that feel like a value or does that feel like, ugh, like I'm gonna have to do a webinar, I'm gonna have to like do a case study, or I'm gonna have to share stuff like I don't know what I'm doing. Well, guess what? A lot of other people don't know what they're doing either. But together, everyone's learning and I think sharing that learning is what people want to get out of the community. So, I'm hoping that's actually valuable. 

Number five, you've adopted or started the process of transitioning towards problem owning value oriented product teams in your work. This is in contrast to what Marty Cagan calls feature teams. I imagine people listening to this are probably aware of those distinctions. If you're not. Go check them out. One of the key ideas here, and this can take some time to change, especially if you're not at the C-level in your organization, you don't have control over this, the idea that you don't own the solution space, but you actually kind of own the problem on behalf of the customer. And together you, you being your product team, so you're whoever is the product owner, whoever the data lead is, the engineering lead, your design lead, together you're supposed to, for example, our job is to help the marketing team spend their marketing budget more efficiently and to cut cost, you know, 20%. Like let's cut wasted advertising spend by 20% in the next quarter. That's our job. That's our mission. How do we do that? Is it a dashboard? Is it a model? Does it use AI? Whatever. A feature team would say, okay, that's nice that you want to do that, but how do you want to do it? What are the features? What do you need us to make? That's what a feature team does. A value oriented product team owns that problem space and they're relentlessly focused together on solving that.

And you get those different disciplines there to help see the world differently. The data people are gonna see it from a data perspective. The engineers are gonna understand what the technical challenges are. The UX and product people are gonna really understand the customer. The product person is gonna be balancing all of these kinds of things. So again, I'm hoping you started that transition there, if you're not already on that track. 

And then the final sixth one is that your management, or your clients, or your customers, they might vocalize and recognize or notice positive changes in how you're approaching the work that you're doing. They've seen some kind of change. They like the change. It could be simply in the questions that you're asking them, but I'm hoping that maybe others will recognize that something's new here, something's different, and this is having an impact.

So those are the six outcomes that I would hope that a member would get after one year, or at least some of those. I don't know if you'll get to all of them or not, but that's what I think I heard. So is it right? I don't know. Please go again to designingforanalytics.com/thecommunity. Get your email in there, get to the Google Doc and please comment. 

And then as to the format of this community, the Data Product Leadership Community, this is what I have in mind. The central place will be a Slack based room for conversations with other people like you that are interested in this kind of product orientation. Again, PMs, UX people, data science people, analytics leaders, digital transformation, data engineering. It's a place to get that help, to celebrate wins, to vent frustrations, to challenge your thinking, all of those kinds of things. That's kind of the hub. 

I'm also going to be really driving one-on-one individual networking there between other members, especially in the early days when there's not a ton of people in there. My goal is that you're actually going to have a chance to meet everybody in some one-on-one capacity there, because ultimately, that's how relationships, I think, really get going in these communities is that there's one-on-one conversations going on as well as the many to one conversations and one to many. 

Monthly zoom webinars hosted by me, but presented by you. These would also be recorded and archived if you are in the community, but you're not able to show up live. This is where, again, when we talked about you contributing back, I'm willing to host these, but the goal here is that you are sharing case studies, frameworks, lessons learned, demos, design reviews. You're showing mock-ups of whatever the solution you're making, getting feedback. Obviously there's going to be rules of the road here about sharing confidential information here. There's the Chatham House rules are really gonna be the framework for that, which is kind of like whatever gets discussed in the community, stays in the community there and there's just a gentle person's agreement about that. We'll have some guidelines for the community on sharing information there, but I'm really hoping that you and especially the early seed members of the group are going to be ready to share on some kind of regular basis there, probably monthly. 

You'll also potentially have a chance to become a guest on Experiencing Data. You know, as I kind of just watch the community and see what people are talking about, I may approach you or if you have something that you think the audience on this show should hear about, I'm always open to recommendations, including nominating yourself. But I'll be listening because I think the people that are willing to be here, they're paying to be here, they want to be an active part of this. Those are the kinds of people that I want to share. I wanna share their work because they're doing something that goes beyond doing the minimum in their career, they're trying to make something bigger. So there's a chance for that.

I'm also, this is still TBD, possibly having guest speaker webinars come in and talk to the group. So this could be, for example, when I do have a guest on my show that I think could be really helpful, maybe asking them if they'd like to come in and do a private session with the community on some kind of topic that could be of interest.

And another TBD thing there is possibly opening up the recording of these episodes that I do on this show with my guests, to people in the community to actually observe live because there's, there's often like chit chat, you know, before I hit record and then after I hit record, there's more conversation tends to bleed over on both sides there. So a chance to maybe check that out too if people are interested. So I'll wait for feedback on whether or not people care about that. 

I also like to do anti-goals and do the negatives of things. So what's not going to be in the community as of now? This is not a training and group coaching or I'm not teaching in the community. That's not the plan. I haven't heard that that's what people want right now. I am considering actually moving that direction eventually with my public training at least, is moving that more into a group coaching model instead of doing calendar based, scheduled cohorts. It's just a lot of work to launch things on a cohort, and I kind of like this idea of just a continuum where people can drop in when they need that, but eventually. Right now, that's not part of the community. A formal job board is not part of it. There's not gonna be a conference. There's not gonna be an archive of the entire history of the conversations in Slack or, you know, a shared document repository or anything like that. Right now that's not for v1. Again, this is all open to your feedback. I'm just throwing those out there as things I've seen in other communities and it didn't feel like they really meant the criteria of MVP right now. 

So a few more things here. One thing on the size of the community, my primary goal right now is not to have a giant community here, and the paywall that's up there isn't really about generating a bunch of income for me. I'm not expect- I will probably lose money doing this, at least in the first year. It's really to raise the bar for participation and for everyone that's in it so that we actually can get this thing off the ground if the community is small, but the members are able to achieve those success metrics. I consider that a win, and my guess is that the community will take care of itself in terms of growth as long as the few of us that had those wins don't represent this very strange, tiny subset of the world. I think there's plenty of people out there who could benefit from this and who are struggling with some of the things that I think this product orientation for machine learning and analytics can help with. So yeah, size isn't really a driving factor for me right now. But again, I come back to, is that correct from your perspective?

Because this is for you. It's not for me. So are those metrics, right? I don't know. Again, head to that url, to designingforanalytics.com/thecommunity. Please leave your feedback there. You can also email me at brian@designingforanalytics.com. B-R-I-A-N. You can even leave an audio message and this is true for all my episodes.An anonymous audio message recording. You don't need any plugins or software. You can do it right from the browser at designing for analytics.com/podcast, please leave your comments. I'll be listening.

Finally, just on pricing, if you're wondering about that. I've actually changed this from the initial idea that I had there, and this is all outlined in the Google Docs, as well as some ways to get discounted and even free access to this community. As of this recording. I've decided to move this into an annual subscription model instead of doing a one-time lifetime access. So I would be starting at $249 US dollars for the first year, and there would be a trial period there so you can cancel if it doesn't feel like it's worth it. Several people mentioned they wanted to try it out and make sure it's right and all of that, so I did want to give a window for that so you can just cancel. You're not being roped into something that you don't want to be in. 

I will be personally interviewing the first 20 people to join this community. These 20 people will have free access for that first year, I hope. And again, shooting for around June of 2023 to get this off the ground. So I'll be doing those interviews hopefully in May, and there will be some additional discounts for those of you who are on my list. If you've gone to that URL that I've mentioned, there'll be some opportunities there as well. And then finally on that line, if you've taken my course or seminar before, the Designing Human-Centered Data Products, you can also get the first year for free. So, just watch for an email for me about that soon. If you took that seminar course and you're not on my mailing list anymore, for some reason, you probably will not get the message. So you'll need to rejoin on my homepage or that to designingforanalytics.com/thecommunity link that I mentioned earlier, get back on that. Because my email software will not be able to reach you if for some reason you've unsubscribed or changed jobs and that kind of thing with and having a different email address.

So yeah, those first 20, along with some VIPs that I've already been inviting to join over the last year or so, will comprise the first initial cohort and then I will kind of eventually extend that registration out to people on the community announcement list and then the full DFA insights mailing list and then to the public.

So that's it for now. I made it under an hour. I wanted this episode to definitely be under an hour. I look forward to reading and responding to your comments about the DPLC as it evolves. Hopefully it'll get a better name too at some point. That's on my list of things to do. I really tried to do this research and design of this community in the open since after all, it's a community. It's not just me. So it felt right to kind of just do this publicly. So I actually just, I created all this document. I'm like, I'm just gonna share it right out in the open. Let's get feedback on it. And yeah, I'm doing it in the open, so please, if I hear crickets and all of that, then I'll know people don't want to do it. But I'm really hoping that, from the conversations I've been having, there's a good number of you who would like to be part of this. So I will watch for your feedback, you know how to reach me. And until next time, thanks for listening to Experiencing Data. This is Brian, take care.