Dinushi Pieries, VP of Product Management at J.P. Morgan, has years of experience in the product space, having worked for prominent tech organizations for several years. Her expertise ranges from managing services to spearheading the development of innovative portals. In this week’s podcast, we spoke with her on the topics of platform product management, open source, and her approach to measuring success when working on new tools.
Featured Links: Follow Dinushi on LinkedIn and Tik Tok | The Open Source Software Security Mobilization Plan | GitHub Copilot | Amazon CodeWhisperer | IBM Project CodeNet
Episode transcript
Randy Silver (00:00):
You know, Lily, it’s a shame that we didn’t set out to plan the intro for this week’s episode earlier.
Lily Smith (00:05):
But Randy, the appeal of our intros is that they’re spontaneous. Well, spontaneous, and they have one really bad joke in them. Oh, and that they’re short. Spontaneous, one bad joke and over quickly. That’s it.
Randy Silver (00:21):
Well, yeah, that is a winning formula, but in the spirit of this week’s topic, I feel like we should have given other people a chance to contribute to the intro script. I mean, we are talking to Dinushi Pieries about what it’s like to work as a product manager on platforms and open source projects at a massive company.
Lily Smith (00:40):
Okay. Well, yeah, it’s a bit late for that, but how about this? If you have a better intro for this episode, why don’t you write it up or send it in, and we’ll see if we can merge it into a later version of this episode?
Randy Silver (00:54):
Yeah, I’m not sure it’s exactly how this works, but, yeah, let’s do that, and let’s get right into our chat with Dinu.
Lily Smith (01:04):
The Product Experience is brought to you by Mind the Product. Every week on the podcast we talk to the best product people from around the globe. Visit mindtheproduct.com to catch up on past episodes and discover more.
Randy Silver (01:16):
Browse for free, or become a Mind The Product member to unlock premium content, discounts to our conferences around the world and training opportunities. Mind The Product also offers free Product Tank meetups in more than 200 cities. There’s probably one near you.
Lily Smith (01:34):
Hi, Dinu, so nice to have you on the podcast today. How are you doing?
Dinushi Pieries (01:39):
I’m very well, thank you. I’m very excited to be here.
Lily Smith (01:43):
Awesome. So before we get stuck into our topic, it would be great if you could give our guests a real quick intro to you, and how you got into product, and what you are doing these days.
Dinushi Pieries (01:55):
Sure. Just to give you a quick overview, I’ve been in product management for just over five years. But before that, I’ve had a little bit of a career trajectory. So I started off studying biochemistry at university, which was in incidentally my foray into just technical curiosity, I would say. I specialised in bioinformatics in a lot of my courses and the lab work that I did. And while I was at university, I did a lot of, one would call, a jack of all trades for a very early-stage payments startup. And it specialised in providing advisory through a bot, if you will, and analytics for the average/gen Z to essentially aggregate your payments into one and give you insights from your bank accounts into how you could be saving better and make more financially sound decisions. So that was the startup I joined while I was at university in my undergrad, and I did a lot of what one would call the marketing functions and product manager and also a number of operational functions.
(03:07)
So I did a bit of the growth marketing, general marketing of paid socials and social media marketing. And from there, I realised, “Well, this is very far away from my lab work, and I do actually enjoy this a lot.” So I then also did an interview with Google, and I realised maybe tech is the answer. And I had a little look at traditional product programmes at a lot of big tech companies, but I did want something that was very FinTech, given that has been my recent experience. So I joined the Royal Bank of Canada, who were just piloting their first product rotation programme at a bank, and I was lucky enough to be on their first cohort. And it was very much an associate product manager programme, and there were a couple of us on the cohort. And from then onwards, it was product for the rest of my career.
(04:02)
And during a time at the Royal Bank of Canada, I did a bunch of things. I rotated across different functions that pertained to asset management, but within that, from a domain standpoint, I looked at both front and development and also data analytics as products. And from then onwards, I specialised further and further into technical product management. So what I initially started off was business domain, almost a sales or solution architect style product, into data analytics, product management and pivoting. Then later on to my roles at JP Morgan, I joined what one would call the platform team or the digital platform team at JP Morgan. And I’ve been in that domain ever since, working on a whole number of things from services, so more backend product management, all the way into what we call horizontal product management. So working on building some of our portals that JP Morgan has externalised recently, and also, as of very, very recently, leading a developer tooling team within our platform product management function.
Lily Smith (05:21):
Awesome, thank you for that intro. I’m super interested to hear about the APM programme, but I’m not going to go down that rabbit hole, because we’ve got so much to talk about on the other side of things, which was kind of platform product management and also you do a lot on open source as well. So before we get into the open source side of things, tell me a bit more about the tools that you work on. So they’re kind of internal and dev tools, is that right? And who are your customers? How do you measure success when you are working on those tools?
Dinushi Pieries (05:59):
Yes, definitely. So basically one of the things that we have looked at so far is a couple of products that relate to front end development and specifically how to build good front end applications. So we have focused very much in our open source frameworks on how we do that well and how we can share that work on GitHub. So we have a product called Modular that is open source and that does focus on this monorepo concept and how you can build react applications quickly and well with all the tooling and the CICD embedded within it in a collaborative environment. So that has been a product I have been working on.
(06:47)
And we have looked at a lot of ways of how we can measure success in an open source community. And some of the key takeaways we have found are looking at adoption rate, so looking at the percentage of developers and development teams that actively use our tooling, time saved and also efficiency improvements. The tool is open source as well as what we call InnerSource inside companies big as JP Morgan, also provides a lot of benefit. So we do do more traditional feedback and satisfaction capturing as well in house. And we also look at developer productivity, so assessing the impact of the tool on individuals and also feature adoption that way. And then we have a number of measures of evaluating cost savings as well, alongside traditional stakeholder feedback and platform product management.
Randy Silver (07:42):
I’m curious, when you first moved into platform, I mean doing dev tools and platform… I have some experience in doing internal tooling. It’s really hard, because you have to not only satisfy your customers, but you have to understand their use cases. So you have to understand the B to C use case as well as what you’re trying to do. What was the learning curve like? What do you wish you had known before you had transitioned into taking on a platform role?
Dinushi Pieries (08:09):
That is a great question. So as you know, through my background, I never had formal developer training or any type of software engineering training for that matter. So a lot of it revolved around self-learning and also learning on the job, learning through developers around me in my early career and using some of my bioinformatics background to teach myself Python, a little bit of Sequel, and also start giving myself a little bit of a front end boot camp as I worked on different products and through them. So that was a humongous learning curve. And constantly teaching myself the newest tech, the newest languages, the newest frameworks has been very rewarding. And also being able to operate as a product manager, going from an individual product that focused on data analytics earlier on in my career and moving into platform product has taught me to go through another learning curve, and I think I can boil those down into three areas.
(09:16)
So one of them was getting accustomed to having a separation from end users when looking at platform product and unlocking the developer persona. That’s also one of the main reasons we have open source in JP at the moment is really getting a developer community going. And also understanding that we have to work very hard to understand user needs, but also how users connect through different platform integrations from a feature perspective. And also, it forces us, from a platform product perspective, to look at prioritisation at its utmost peak. And how to say no is probably one of the biggest learning curves I also had to undertake when going from product to platform product management and the never-ending set of dependencies as well as something platform PMs have to advocate for. And most importantly, visioning and vision statements across product vision. So naturally collaboration there becomes even more crucial than it does in an individual product capacity.
Randy Silver (10:25):
I do have to ask, does anyone ever say thank you?
Dinushi Pieries (10:28):
Yes, yes. That does actually happen. It does happen, but there’s many ways to say thank you. I guess recognition awards are quite nice, that type of thing. But yeah, it does tend to happen.
Lily Smith (10:45):
And you’ve kind of hinted at it there, but how would you define platform product management versus other types of product management?
Dinushi Pieries (10:57):
That’s a good point. I have many different definitions for this, but I think one good way to know if product is part of a platform or has been built in a platform product context is knowing if you can “dog food” the product amongst other product teams. Essentially, if you have company-specific business rules, from an organisational context perspective, and then you have the plane of the platform, and then you have the domain context and essentially real-word facts, and you want to get to both the organisation context and the domain context through using the tools available to you and having, if you’re in a developer tooling context, say, the tooling team’s output be used by the front end development teams. That way you can prove value through say building sample apps that then can be seen by potential customers and thereby drive value.
(11:58)
That’s probably the best way, just using an example, to see the difference between platform product versus traditional product. And the other way I would like to define it is through how you measure success. So from a platform product perspective, stability. Not to say stability isn’t an ever an issue, but stability of the platform as a whole, and SRE telemetry, et cetera, that becomes much larger focus from a platform-style thinking perspective. And also, as I mentioned earlier, your vision becomes very different. You start thinking about APIs and the beyond the technical tooling, API provisioning, SDK provisioning, and again, most importantly, unlocking the developer persona or engineering persona as well as the end user or end customer that is typically on the business side.
Randy Silver (12:59):
When somebody new joins the team, what’s the thing that you have to make sure that they understand? What’s the biggest challenge of moving into this space that they may not have faced elsewhere in a different product role?
Dinushi Pieries (13:11):
I think that that’s a great question as well. So that I think goes back to a very similar theme. One of the biggest things in general, because there are people like myself who don’t come from a technical background, working on technical tooling. So you don’t necessarily have to come in with all the certifications and being a former developer, although that does help, but what does help a lot is the ability to learn and have an acumen for technical analysis.
(13:41)
So being curious through data driven insights, if that makes sense, is very integral to a platform role, because you are at the end of the day backing up your decision making through a lot of data and you’re getting other people to come on the journey with you. And thereby you’re also telling a lot of very skilled engineers and developers who you are working with to optimise the platform while you’re making decisions. So it becomes an equal part of traditionally sourcing customer feedback and requirements and sentiment for new feature with data to support if this is something that can be scaled in a platform. So that’s typically a scenario that new joiners experience and, yeah, that’s one way to bring people in and get them in a platform mindset.
Lily Smith (14:33):
And you’ve mentioned there a couple of areas in which it’s really good to be quite strong if you’re going to be a platform product manager around technical analysis and I guess just generally being quite technical. Do you think that you need to have an engineering background? I mean obviously, you didn’t come from an engineering background. How much is that an advantage versus a disadvantage in that sort of platform product management role?
Dinushi Pieries (15:04):
Definitely. So I think the disadvantage for sure is that you’re coming in and you’re immediately met with a lot of engineers speaking in intricate detail about their technical implementation details. And a lot of engineers are obviously brilliant at what they do, but they come in with that solutioning mindset. So as we all have experienced, being a strong platform product manager is being able to discreetly, and with facts and knowledge, being able to push back on that and have an alternative if that is the case, or dig deeper into why that consideration is being proposed. So that’s definitely something that has to be learned.
(15:48)
And also, one thing that has helped me a lot from a non-technical background going to a platform and very technical set of products is this concept of preventing “go around” with platforms. I.E., if you are not very technical yet, but you want to understand what the impact of that technical feature could be as you learn, through maybe learning Cloud strategies and doing your Cloud certifications and maybe playing around with some front end development, is understanding what the client team wants and what the central system is that you’re working on and the custom system that may already exist, right?
(16:30)
So how do you prevent that go around from going from a custom system to the client team? You want to make it very much a central system and build into the platform. So being able to segment that visually and being able to understand that from a client perspective and understand architecturally how that works is something that I first started to do.
Lily Smith (16:59):
Hey folks, are you looking for an opportunity to learn from the best, connect with other PMs and sharpen your skills?
Randy Silver (17:06):
Then you won’t want to miss MTP Con in San Francisco on June 14th. This year’s lineup of incredible speakers includes Christian Idiodi, a partner at Silicon Valley Product Group. Yi-Wei Ang, chief product officer at Talabat, Natalia Williams, chief product officer at Hootsuite and many more.
Lily Smith (17:24):
Also, check out the schedule on June 13th. The team have arranged a bunch of in-person, interactive workshops led by experienced product managers who will share their secrets and demonstrate their tips for success. These workshops are designed to be for everyone, total newbies and season pros alike. Go learn some stuff and make some new product friends.
Randy Silver (17:44):
So what are you waiting for? Grab your tickets now at mindtheproduct.com/sanfrancisco, and we’ll see you there.
(17:57)
Dinu, I’m curious, so you’re working on platforms that improve the productivity of your dev teams. You’d think that would be a competitive advantage. Why do you guys open source this stuff?
Dinushi Pieries (18:10):
Another good point. So what we are trying to do through open sourcing is also showcase that we are thinking about the developer persona, especially historically, in banking, that is a very new phenomenon, whereas larger players there have been doing this for a while. Like AWS, APG, et cetera, are very well established Cloud giants and naturally, authentically fit into the developer persona. So through open sourcing, we are demonstrating that we can also address developers and how they build front-end apps. And we also are looking into how we merge that with a design system that is now publicly available called Salt. So we are looking into that Spotify design system-style domain work as well. So that’s definitely something we see value in doing, and it’s also a good way to test out externally how features are perceived from a developer’s perspective. So it gives our developers a lot of confidence to see that. And as mentioned before, we do a lot of that inner sourcing as well. So it’s a two-pronged fork in and out to get that buried feedback and also figure out what gets platformized and what doesn’t.
Lily Smith (19:34):
So how do you decide what gets open sourced?
Dinushi Pieries (19:39):
Ooh. The way, I think, in general, one decides what to get open sourced, and there’s no hard and fast rule for this, is generally trying to figure out what the project goals are. So is it looking to build a community, as the case was with us, building a developer community, fostering collaboration, also receiving contributions. And in some cases, it can also be to gain visibility, right? To say, “Look, I’m in this space, I’m here, and this is how we contribute.” It’s also understanding and identifying what the core functionality is. So is there something that maybe others can benefit from that one might do really well. So is it beneficial to open source the core components to attract contributors and create a collaborative ecosystem around the project? Or is it more to say that, “Here is a list of key dependencies that a product could rely on,” and maybe third party libraries or tools could benefit others who may have similar problems?
(20:46)
So one thing we also would want to look at is how to minimise restrictions and potential conflicts in an open source project. So in the decision [inaudible 00:20:57], what could that look like? And then also looking at potential licencing, ensuring that there are guidelines in place. Like there are, for example, MIT’s licence, Apache licences, general public licences, et cetera. So where does the implementation fall into? And then, very importantly, also documentation and also understanding that the code that is looking to be open sourced is well documented internally before it is open to the public. And thereby, we also would want to look at how want you to look at feedback and source feedback. Is it through a mailing lists, forums, other communication channels, et cetera? So at the moment, in the case of module, it is through the GitHub channels as well.
Lily Smith (21:45):
And… I mean, I have my assumptions about why engineers contribute to open source projects. But in general, what’s your experience with why engineers enjoy contributing to projects like this?
Dinushi Pieries (22:02):
Sure. I think it’s a very simple answer. At the surface level, it is getting validation and very quick feedback on what engineers put out there. And that, I guess, speaking objectively, is very different to the traditional product model where one would have to go through cycles of shipping a product and features to see material impact and value and an increase in satisfaction scores like CSAT for example. So this is a fast way of getting feedback from other developers as well and getting more technical detailed feedback that developers appreciate, which helps them iterate faster. So that’s something I’ve noticed in general
Randy Silver (22:47):
Dinu, at the best of times, trying to work with stakeholders and your team and everything else, it’s like herding cats. When you’re working with open source and you’ve got the potential for anybody to contribute to a project, how do you maintain any semblance of control and actually manage it or is part of it just letting go and seeing what happens?
Dinushi Pieries (23:12):
A part of it is essentially controlling who generally has access from a sense of what commits do you eventually merge into the core of the product itself. So there’s a guideline from that perspective of how many commits can you get in, and obviously approve as a core of contributors of the product in-house as well, so they can pick what goes in and what doesn’t. So there’s a bit of moderation that takes place. And there’s also curation of the feature that is decided to be brought in into the open source project. So if it’s an existing open source project, some things may not want to necessarily publish, and other things you continue publishing if it has enough reach, for example, or if it has enough code audits that it could pass.
Lily Smith (24:04):
And I’ve just realised we haven’t actually sort of specifically explained what open source is or what it means. So if you are explaining it to someone new who hasn’t come across this concept before, how do you explain it?
Dinushi Pieries (24:20):
Sure. The simplest way to describe it is any type of open source software is any type of code that a community can inspect, modify, or elevate is probably the simplest way to explain what that is. And I personally see open source as a big community driver in a big part of the developer community unlocker. So I typically explain it that way.
Lily Smith (24:51):
Awesome, thank you. We probably should have done that beginning, but nevermind.
Dinushi Pieries (24:56):
No worries.
Lily Smith (24:59):
And then so one of the things that I find really interesting about this is obviously you’ve got a lot of engineers that are contributing to your open source project. And often I get asked by product managers about how they can get into the product space, or not asked by product managers, but product people who are aspiring product managers, and how they can gain experience in product management. Is open source a good route for volunteering some time to do user research or help with prioritisation? Is there a way for aspiring product managers to connect with the open source communities and provide some services so that they can also gain experience?
Dinushi Pieries (25:50):
Definitely that’s a great way to get started and also a very non-traditional way to do it. Especially folks who are not technically inclined should also consider this to just learn more about a project as well. And a good way for aspiring product managers to give value to open source communities is through documentation. So really good developer documentation and learning how to write good developer documentation through guided tutorials, et cetera, is a great way to start. And providing that essentially as a starting point to build up a product portfolio to certain projects where you might really be interested in and would like to see it succeed is always a good way to get started and essentially build upwards from the documentation into what one might call productizing an open source project.
(26:44)
So that’s a good way to start, especially if you’re coming from a wide variety of backgrounds like from BA route or QA or anything around the tech space or even completely outside of it. It’s a good way to get started. But that’s also something I have recently started addressing. So I started, a bit off-topic, creating TikToks, which I’ve explained to Randy before to address this and essentially get more non-technical people involved in the tech space and not be perturbed by the general industry at the moment, but really have a look. So yes, to your point, open source is a good way to get in there.
Randy Silver (27:28):
And we definitely have a link to your TikTok in the show notes for this. So if you’re old school like us and you actually click links and show notes, then that’s one good way to find Dinu’s TikTok. Along those lines, though… I feel like I’m repeating myself, but it’s in a good way. When people move into working with open source and they haven’t done this before, what’s the lesson you think that they need to learn? What’s the thing you wish you had known before you had come into this space?
Dinushi Pieries (28:01):
I think what I would have wanted to learn more is… Which, doesn’t sound that illustrious, but it’s just overall understanding more than the cool repos and the features in the open source landscape… But understanding a bit more of who the very product of me, who the developer persona is. So really doing persona profiles of the developer as we would for treating the developer, really, like a buyer persona or a customer persona as part of our framing work that one would do as a product manager. And even if you’re new to product, taking the time to do that when entering a potential open source project is it has a lot of value.
(28:44)
And another thing, which is probably not that glamorous but very essential, is understanding the emergence of security awareness in open source. So there’s like things like the open source software security mobilisation plan. So it has different streams of investment in building more laws around open source and what that means, so does I think the European Cyber Resiliency Act and other similar acts like that that are coming about, which is obviously very important when entering the open source spaces of product manager as well.
(29:18)
And the other very topical part is understanding open source and the ethical implications of AI, ML and also deep learning. So for example, understanding GitHub’s AI assisted copilot and how said models can be used in open source repositories and what that means for that particular repository. And I believe there’s also Amazon’s Code Whisperer and IBM’s Product Code Net, which are also very similar. So really delving into those facets as well.
Lily Smith (29:49):
That sounds like an awful lot of stuff to get to grips with.
Dinushi Pieries (29:53):
Yes, I think it’s easier to say this in hindsight, I would say. Yeah, I had no idea beforehand, but that’s the beauty of it.
Lily Smith (30:04):
Dinu, this has been so interesting. Thank you so much for joining us. We have time for just one more question, and I’m really interested to know what you’ve kind of seen changing in the opensource community during your time being involved in it and what you see changing in the future as well.
Dinushi Pieries (30:23):
Sure. So I can just speak generally about trends I’ve seen in the industry. So one of them is seeing a lot of enterprises or enterprise-driven organisations, larger scale organisations, creating this concept of a open source programme office or a virtual office, if you will, for different parts of open source operations. So this could include setting guidance, compliance around what open source means to that particular company, and then also creating training tooling and also promoting open source community engagement. So that seems to be quite a trend. And then there’s also looking at appointments of folks to executive levels for open source strategies and security, maybe even legal and compliance, if that pertains to the scale of the organisation. And then also the concept of contributing to open source projects as a means of gaining expertise, so really eliminating skill gaps, is also something I’m seeing happen.
Randy Silver (31:30):
Dinu, thank you so much. This has been fantastic. We look forward to continuing to follow you on your TikToks and everything else and learning more about this. This has been really interesting and we really appreciate you coming on.
Dinushi Pieries (31:43):
Thank you so much for this conversation. It really has been great.
Lily Smith (31:46):
The Product Experience is the first…
Randy Silver (31:59):
… and the best…
Lily Smith (32:00):
… podcast from Mind the Product. Our hosts are me, Lily Smith…
Randy Silver (32:05):
… and me, Randy Silver.
Lily Smith (32:11):
Louron Pratt is our producer and Luke Smith is our editor.
Randy Silver (32:11):
Our theme music is from Hamburg-based band Pau. That’s P-A-U. Thanks to Arne Kitler, who curates both product tank and MTP engage in Hamburg and who also plays bass in the band, for letting us use their music. You can connect with your local product community via Product Tank, regular free meetups in over 200 cities worldwide.
Lily Smith (32:32):
If there’s not one near you, maybe you should think about starting one. To find out more, go to mind the product.com/producttank.
Comments 0