Our founding data science lead, Gráinne Mcknight (aka “G”), has worked with many PMs in companies like N26 or Adyen and now Spoke. It is an honour to be working together with her for such a long time now.
Gráinne shares extremely important learnings for any PM working with data or AI. The importance of getting the data team into the discussion of what’s possible and what’s not can have immense implications on the value to the customer.
I am certain you’ll enjoy this episode!
✅ Integration of Data Teams: Embed data teams within product teams to foster collaboration and innovation from the ideation phase.
✅ Early Demonstrations of Value: Start with small, manageable projects to demonstrate the value data can bring to the product, gaining a seat at the decision-making table.
✅ Bi-Directional Ideation: Encourage both data and product teams to contribute ideas, leveraging data insights to drive product development and vice versa.
✅ Agile Methodology Adaptation: Adapt agile methodologies to accommodate the unique timelines and processes of data projects, especially in exploration and testing phases.
✅ Effective Communication: Improve communication about the distinct nature of data work, especially around the time and processes required for exploration and testing.
Gráinne (00:00)
Yeah, currently I'm funding data science lead at Spoke. So overseeing all the AI magic that we serve in our product. We first, I guess, had the great opportunity of working together at N26, as you mentioned, where I worked also as a data scientist across both customer communication and fraud and money laundering topics.
In between where we got the break from each other, much needed. I worked at Adyen in Amsterdam and there also worked on kind of financial crime topics as a data scientist in lead.
Jack (01:04)
Cool. I think obviously product and data communication is becoming under like maybe increasing scrutiny as it sounds a bit harsh, but it's becoming like a more relevant topic since data is and specifically AI is more integrated into every product team and every product that's being built now. So I think a lot of learning's there, um, to share and to dive into, but maybe you can talk to us or tell us about an experience that you've had where that communication between product and data didn't work so quite so well and sort of unpack what happened there.
Gráinne (01:43)
Sure, so probably some of my former colleagues on the data science team at N26 will remember a service there called Brussels, which was a microservice that we built on the data team that served geolocation enhanced information for transactions. It was really cool. It was my baby while I was there.
Product and data communication didn't really work well as that project was birthed on from the data team and was never really taken up by the product team at N26 at the time. I think this was a feature of the fact that data was very much at the time a separate entity from product at N26 and we more served as a service, than as an embedded part of the product team. So when it came to product development, we were more there as a team to ask a request from, rather than a team to ideate and build a product from start to finish with. And when we had ideas like this Brussels geolocation project, we were put into a position of having to pitch them as an outsider to the product team.
And that's in fact what I did. I remember being extremely nervous because I was pitching to some of the C level as well for this topic. I have no idea what they thought, but I do know that it was never developed.
The others on the team had that experience numerous times, which was quite frustrating. And it really, in my opinion, stems from not having data be really embedded in part of the product development, which I think is more and more important now as people are beginning to really build a lot of products involving data and AI.
Jack (04:02)
Yeah, it seems so crazy to have front end in the team, back end in the team, design in the team, and then data being this complete other thing. I mean, at N26 data was even sitting down sort of, you know, not in a separate building, but on a different floor that it felt like it took a long time to go down to, which made for quite a physical separation as well. Um, which I think it's really good to see that data is being brought in and, and consulted more and also driving projects and products that I was going to say at N26, but had spoke where we are now.
Tell me a bit about what you think you would have done differently in that circumstance or how you think you could have brought data in to that kind of ideation process or made them more deeply integrated in Teams to begin with.
Gráinne (04:52)
Yeah, I think at the time there was very much a chicken and the egg problem, which is that we, in order to have voice in product ideation and development, we needed to prove that the data team could deliver value. And in the end, I think we did, especially on the project we worked on together with the chatbot, I think that served as a really great advertisement for if we build data into our products, we can deliver value for our user. I think things improved after that point.
I guess what I personally would have done differently is maybe tried to build a much smaller scoped project, show and demonstrate that it could deliver value, and then kind of gotten a seat at the table with the product team because that was within my control. I think in terms of what actually are the changes needed to avoid this situation, it's what we do at Spoke, right?
So really getting the data team involved in product ideation right from the beginning, having multiple touch points with the product team, our, I know you've had our bi-weekly product and data meeting.
And I think that's a great example of how kind of to inject that data thinking and AI thinking into the entire process.
Jack (06:27)
I think what's nice about our kind of bi-weekly meeting is that it's sometimes it's product saying, Hey, we were thinking of, you know, this stupid idea. Could you look into it a bit more, but often, or probably even more than 50% of the time it's data saying, Hey, we were thinking about this, you know, this is possible, for example, with the new stuff around the assistance API, right?
It was really came out of exploration that you did on the data team to say, hey, this is something that we could do. And then it's almost like productizing that. So it's really, it's using that opportunity for both kind of sets of people or both parts of the team or all parts of the team to actually drive the ideation to start with what's possible, I think.
Gráinne (07:11)
Yeah, 100%. And I think we're all learning what large language models and other generative AI can do. So it's kind of a nice opportunity to learn from both directions, the product team learning about what's out there and how people are designing those generative AI experiences and us really exploring what is technically possible.
Jack (07:39)
And maybe just zooming into then when you're like, we have, obviously we, you know, we have sprints where we've got tickets on the board and, you know, some of them are more cross-functional tickets and they have parts of front-end and backend and data, but there are also just data tickets as well. And sometimes I think that distance maybe comes because data tickets are a little bit detached because it's maybe building a model, training a model.
And there's like this, this timeline of stuff before they kind of become in like integrated or embedded within the product. Do you have any thoughts or learnings from, from our experiences there of like trying to bring data more closely into those cycles? Because I also remember at N26 when we were working on that chatbot stuff, some of the data tickets were just like super irrelevant to the rest of the stuff on the, in the planning and we'd sit there and with data folks being very patient as we talked about, you know, all these other stuff and then there was like 10% data.
What do you think about that? What's the best way to balance those things?
Gráinne (08:42)
Yeah, I still think there's more to be figured out on how agile methodology can work best for teams with that data component. But at least what I think I've learned is to, is that specifically on sort of spikes or exploration, they're really quite different types of tickets between backend, frontend and data.
So typically in backend or frontend, a spike can really be time boxed well. It can be a series of questions around feasibility or implementation that can be answered within some pre-known time. Unfortunately, on the data side, often feasibility is something we can only assess after building out a solution or something, some sketch of a solution. So spikes in that instance become much longer and less capable of being time boxed in the same way. I think the biggest personal learning I've had there is to try and get better at communicating. That's the case and that it can take longer for those processes.
I think another big difference is just this testing and ready for testing column that we have, for example. So when you're assessing an AI or a data product, it isn't as deterministic as front-end or back-end services where, okay, you test something 10 times, you expect the page to load, for example, or it doesn't. It's really less, you know, it's more...rough.
So testing is something that can also take a little bit longer and needs to be thought about like what's our threshold for accuracy for example and then that entire ready for testing and testing kind of process can take a little longer because of that as well.
Jack (11:00)
Yeah, it's completely different. As you said, it's not testing does the page load, right? It's and you almost want to test it 100 times to get 100 different results, especially with generative products as well, because that one result might be the very problematic one. So yeah, super interesting that Granya, thanks for joining me today. Nice chat. And thanks for your time.
Gráinne (11:22)
Thanks Jack, ciao, bye.
.webp)
.webp)
