The Product Experience

The journey to becoming customer-centric at Pfizer: Atif Faruqui (Director, Developer Products and Platforms, Pfizer)

• Mind the Product

Share episode

Join our conversation with Atif Faruiqui, Director of Developer Products and Platforms at Pfizer, as he illuminates the path the pharmaceutical colossus took towards a product-focused approach. He takes us behind the scenes of Pfizer's strategic pivot, highlighting the signals that spurred the company's leadership to champion a customer-centric approach. 

Featured Links: Follow Atif on LinkedIn | Pfizer | 'What's a Proof of Concept? The Complete Beginner's Guide' feature at Career Foundry | 'The Rising Importance of Product Managers in Digital Transformation' piece at Emergn 

Our Hosts
Lily Smith enjoys working as a consultant product manager with early-stage and growing startups and as a mentor to other product managers. She’s currently Chief Product Officer at BBC Maestro, and has spent 13 years in the tech industry working with startups in the SaaS and mobile space. She’s worked on a diverse range of products – leading the product teams through discovery, prototyping, testing and delivery. Lily also founded ProductTank Bristol and runs ProductCamp in Bristol and Bath.

Randy Silver is a Leadership & Product Coach and Consultant. He gets teams unstuck, helping you to supercharge your results. Randy's held interim CPO and Leadership roles at scale-ups and SMEs, advised start-ups, and been Head of Product at HSBC and Sainsbury’s. He participated in Silicon Valley Product Group’s Coaching the Coaches forum, and speaks frequently at conferences and events. You can join one of communities he runs for CPOs (CPO Circles), Product Managers (Product In the {A}ether) and Product Coaches. He’s the author of What Do We Do Now? A Product Manager’s Guide to Strategy in the Time of COVID-19. A recovering music journalist and editor, Randy also launched Amazon’s music stores in the US & UK.

Speaker 1:

Hello and welcome to the Product Experience Podcast. This week we're talking to Atif Faruqi, Director of Developer Products and Platforms at Pfizer. He went through a digital transformation along with his team and came out the other side unscathed and ready to tell the tale. So if you want to hear what a successful digital transformation looks like, then listen on.

Speaker 2:

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 world.

Speaker 1:

Visit mindtheproductcom to catch up on past episodes and discover loads of free resources to help you with your product practice. You can also find more information about Mind the Product's conferences and their great training opportunities happening around the world, and online.

Speaker 2:

Create a free account on the website for a fully personalized experience and to get access to the full library of awesome content and the weekly curated newsletter Mind. The Product also offers free product tank meetups in more than 200 cities. There's probably one near you, Atif. Thank you so much for joining us on the podcast this week. How are you doing? How's your day been?

Speaker 3:

I'm doing great. Yeah, day's been good, day's been good getting things done, so, which is always a good sign. But yeah, thank you.

Speaker 2:

Excellent. So before we get into the topic of the day, we're going to be talking about the experience you've had in transforming your company, or the transformation experience you've had in your company. Tell us a little bit about yourself. How did you first get into product management and what's the job that you're doing these days?

Speaker 3:

Yeah, so I'll start off with what I'm doing these days. So I'm a product leader for the digital automation product within Pfizer and basically what we do is we build an engineer automation solutions for our customers and build any tools or platforms that would accelerate their work, which, in turn, you know, would help with delivery of customers.

Speaker 2:

And Atef. How did you first get into product management?

Speaker 3:

Yeah, so I've been involved in product area here and there, whether product owner or supporting products, but three years ago our company started the journey around transformation and adopting product mindset, and that is when I got the real taste of product management. What does that entail and ins and outs of it?

Speaker 2:

I'm sorry. What was the difference for you from moving from the roles you had before? What kind of roles were you doing before you took on this role, and what's the difference been?

Speaker 3:

Yeah, so previous to this I was leading teams. We were shipping features, we were shipping products, but they were not in the context of a product. We did not have a clear line of sight of our customers. Work would come to us, we would deliver on it and we would move on. So it was a very loosely defined role. But you know, with this product model it's more. You know it has more clarity to it in terms of you know clear line of customers, what our OKRs are and so forth.

Speaker 2:

Okay, so we're here today to talk about the transformation project that you've been going through for the past few years and what it felt like and what we can all learn from it. I'm curious, though you started talking about this, but we've all been through transformation projects over the years. What was the situation that Pfizer found itself in that you're part of? Pfizer found itself in that it decided to commit to a transformation. What were the problems that management was seeing that? They said you know, we got to make a change.

Speaker 3:

Yeah, yeah, so that's a good question. So we started the journey mainly because of three reasons First, to enhance customer experience in terms of delivering our services by simplifying our delivery model. Second, creating space for innovation for our employees so that they can focus more on important work rather than mundane day-to-day work. And third is, you know, to empower our colleagues so that they can make decisions independently. And all these three things came along in terms of, you know, making sure that the services we are providing to our customers, they have a consistent experience when they engage with our group.

Speaker 1:

It's interesting that Randy said earlier oh, we've all been through a transformation project.

Speaker 1:

I have been through a kind of a very lightweight transformation project, but probably not like most people have been through in much bigger organizations, and those kind of three reasons that sort of triggered this transformation are kind of interesting reasons to me, because they seem to be more kind of inward, focused on the team experience, rather than you did mention enhancing the customer experience. But there's kind of then two reasons on, like creating space for innovation for employees and then empowering your colleagues as well. So how was this sort of identified within the part of the organization that you were in? Was it the team that were crying out for this change or was it the you know, the customers saying, oh, we need more from you, or was it the leadership that identified that opportunity?

Speaker 3:

Yeah. So I think the biggest indicator for us was that there were multiple channels where customers were engaging. There was no single front door. What was that causing was that our employees were getting overwhelmed because, you know, multiple customers would get in touch with them directly, the response time was not defined and the team was getting overwhelmed to a point that our, you know, service quality was taking an impact and again, as you could imagine, that was creating, you know, not a very good customer experience, you know, when engaging with our group. So those were the two key indicators that made us realize that we need to do something about it indicators that made us realize that we need to do something about it.

Speaker 1:

So when you say we like, who was it that was identifying this as an area for improvement for you? Was it the leadership team that were saying, hey, I think we need to do something about this?

Speaker 3:

Yeah, it is our leadership team and our senior vice president. He identified it and his leadership team rallied behind him. And obviously, you know we don't do anything that radical without talking to our customers. So there were some customer satisfactions, you know. Results were taken into account. We did user journey to see where the problems were at what point. So there was a lot of analysis, research went into it before we embarked on the journey, because we knew this is going to be a multi-year effort. So yeah, it was, it came right from the top.

Speaker 1:

I think that's like such an interesting part of doing digital transformation, because you really really need that buy-in from your leadership team Absolutely, and also the understanding that this is a huge project. So thank you for just clarifying that point.

Speaker 3:

Yeah.

Speaker 2:

And you said that you all knew it was going to be a multi-year effort. I think sometimes there's the fantasy that, okay, we're going to stop, we're going to put down tools on Friday, We'll all go into training for a week and then we come out after a week and we're all working in the new way. So how did you actually get started? What were the first things that the division did to get started on working in a new direction?

Speaker 3:

Yeah. So I think the first thing that team did was our leadership team. They put together you know hypothesis that okay, we know what our problem is. This is how it should work and let's test it out, let's pressure test it. And the way we pressure tested is we stood up two proof of concept teams, which we called it beacon teams, and those two beacon teams have different scope, different set of customers, different delivery domains, and they were stood up for about six sprints and the idea was that you know they be productized, the you know work that they're going to be doing, there's persistent team behind it, identify who the customers are and we will inspect and adopt right. I mean, the things are not going to go as planned as what we have put on the paper, but we went with the understanding that you know we will evolve as we learn out of these two teams.

Speaker 2:

How did you decide which teams were going to be the beacons?

Speaker 3:

Yeah. So we, as I said, we decided two areas One was more closer to our customers, which was less technical that presents a different opportunity area in terms of testing the model and the second was more technical, more around developer experience. So that's how we decided that we should do one technical beacon, one non-technical beacon see how our customers are reacting to it, how teams are forming, because they have to go through forming, storming, norming and performing phase, so to see everything, you know, from all angles. And along the way, we had agile coaches that were there to support. So there was a big support structure in place to help us. So it was not like, okay, you're the product owner, you're Scrum Master, you're the team, go run with it. There was a support structure behind it to clearly monitor how teams are doing, so that the lessons can be taken from it that would get applied to future teams.

Speaker 1:

That was one of the questions I was going to ask is what kind of changes you made to the way that the teams were structured or the skills within the team. So was it kind of people that were in the organization and in the team already, or kind of close to the work that you were doing already, and then you gave them roles? Or you slightly changed their roles and then gave them an agile coach to help them work through this new way of working?

Speaker 3:

Yeah, so part of this transformation was agile transformation as well, because, you know, we were using agile principles in some area, but not across the whole organization. The way we were operating was that we would create a project and we will assemble the team to work on that project. So this was a paradigm shift where the idea was that we will define a product, we will create a persistent team behind that product with the right set of skill set and we will bring work to them. That way, the team is more familiar with the product, what the indicators are to be successful in terms of successful delivery, have clear line of sight of our customers. So, in terms of skills, we had the skills. It was just, you know, being very thoughtful about it that you know, if this is the product, what skills do we need in the team. And these were cross-functional teams, so hierarchical wise, they were not reporting to product owner. They were coming from different practices. So that was part of the model as well defining practices. So that's how we went about forming the teams.

Speaker 1:

And during that phase, when you had those beacon teams, what was the vibe like in the business? Were people nervous or excited? Were they skeptical, or how are people feeling about it?

Speaker 3:

well, I can tell you that, since one of the beacon was some was iran I was a product owner for that one. So we were nervous, uh, within the team, that how it's all going to. I still remember the first retrospective that we did. We all were really nervous, you know, at how our customers are going to react, how our stakeholders are going to react, but it certainly exceeded expectations. The biggest, you know, surprise for me was our customers. They were really receptive to our operating model redesign. They were all in. They were, you know, very supportive and they did not see it as a disruption to them. So, yeah, that was, which was pretty good. But, to answer your question, we were nervous as a beacon teams, you know we were nervous you said that you had most of the skills already, but where did you find that?

Speaker 2:

as you changed the way you were, did you need to acquire any new skills on the team, or was there just a different focus? Did you have to relearn or practice things in a different way?

Speaker 3:

Yeah. So in terms of domain skills we had. So, for example, if it was a software developer we needed in the team, we had those set of skills. Where we were lacking was more around mindset shift on how to adopt agile ways of working Because, as I mentioned, we were not consistent in terms of our practices. So that's where we had agile coaches who really helped us with defining what agile is and how the ceremonies work and how it adds values to customers. So that's the skill that we gain along the way, plus the product mindset. That is a different way to look at things. All together right. So that's another thing that we learn along the way.

Speaker 2:

Well, so far this all sounds really easy and really positive, but I've definitely worked in places where some people are resistant to change. They like the way things are. So did you come across anyone who wasn't quite so happy with this new attitude, with this new approach?

Speaker 3:

Absolutely. I mean you're looking at approximately 300 people and you know many, many a team. So these two teams were beacon teams, they were proof of concept team. The idea was that they will be there for six sprints and the momentum they will create the future cohort teams will take forward with them. But you know change comes with anxiety, with nervousness, and you know change creates disruption. So, yeah, there were people, some people strived in it, they thrived, they did great. Some people who were set in their ways, they had a hard time. They did not understand why we have to make that change when everything is going fine. So, yeah, I mean it was pretty rocky, especially when we came into the earlier stage of you know, when beacons were times where we really had to, you know, go back to the drawing board and and see that you know, okay, what have we gotten ourself into?

Speaker 1:

So after the beacon teams, what? What was the kind of next part of the process?

Speaker 3:

Yeah, so we have. We have what we called it cohorts. We have defined teams in different cohorts. So cohort one would have five or 10 teams, cohort two, cohort three. So that's how we mobilized the rest of the organization by grouping them. And we were thoughtful in terms of grouping because, you know, some teams are, they had a head start in terms of you know they're, you know they already adopted agile ways of working. Some teams did not have a product, they have service. So the other thing was that not all teams had products, like some teams were more service oriented, so we do not necessarily have to have scrum sprints for them. We went with Kanban type of approach. So we were thoughtful in terms of how we want to mobilize these teams. And, you know, as these groups got mobilized, we did a graduation ceremony. We made sure that we are recognizing every milestone that we are achieving throughout the journey and that's how we continue to, you know, deploy the new operating model.

Speaker 2:

This episode is brought to you by Pendo, the only all-in-one product experience platform.

Speaker 1:

Do you find yourself bouncing around multiple tools to uncover what's happening inside your product?

Speaker 2:

With all the tools you need in one simple platform. Pendo makes it easy to answer critical questions about how users are engaging with your product.

Speaker 1:

And then turn those insights into action so you can nudge your users to adopt valuable behaviors. First, pendo is built around product analytics, enabling you to explore how your users behave and what they're experiencing, so you can make strategic optimizations.

Speaker 2:

Next, Pendo lets you deploy in-app guides that lead users through the actions that matter most.

Speaker 1:

Then Pendo integrates user feedback so you can capture and analyze how people feel and what people want.

Speaker 2:

And a new thing in Pendo session replays a very cool way to experience your users' actual experiences.

Speaker 1:

There's a very good reason over 10,000 companies use it today.

Speaker 2:

Visit pendoio slash podcast to create your free Pendo account today and try it yourself.

Speaker 1:

PS. Want to take your product-led know-how a step further? Check out Pendo and Mind, the Products lineup of free certification courses Free Everyone loves a freebie led by top product experts and designed to help you grow and advance in your career.

Speaker 2:

Learn more today at pendoio slash podcast. So, Atif, what was the biggest unexpected challenge that you found along the way?

Speaker 3:

That's a good question, yeah, so I think one of the challenges which I think was not is because these were cross-functional teams. The product owner did not have any. They were not reporting to product owner in terms of you know being, you know being their direct reports. So it's a cross-functional team and PO was delivering, you know, you know talking to customers, bringing work, getting work done. So the challenge we saw was that PO felt some of the POs not all felt that I should be, you know, these teams should be reporting to me.

Speaker 3:

So there was some adjustment in terms of how these teams were structured, because the idea was not that we are creating hierarchy here, that people are reporting into PO. The idea was these are cross-functional teams. If a developer's work is complete, he will move on back to the practice and it will get assigned to the. So scaling up and scaling down is something that was an unexpected challenge because it looked good on the paper but when we applied it in the practice it created a little bit confusion, and I want to say rightly so, because when you have some people or you know a resource who has developed knowledge of a product and you take that person out and put it in a, in a different team, it does create, uh, you know, impacts, continuity. I should say so, uh, that's some of the things you know that.

Speaker 1:

I should say that that came across as as a challenge and I guess that shift from, as you said, sort of people were expecting some hierarchy. I feel like I've definitely experienced that before, where you're shifting from a model where developers and engineers and designers or whoever you have on that cross-functional team, are kind of being fed things as opposed to challenges or objectives, that they then decide what the work should be and they have a lot more kind of autonomy over the work that they're doing. There's that kind of mental adjustment can be quite tricky for some people and can actually cause more anxiety and it's like no, no, no, I just want a manager to tell me what I'm doing.

Speaker 3:

So it's quite uh, it can be quite sort of overwhelming for the people, I think yeah, and, and I think the key is that as long as team uh is going towards being autonomous or being you self-organizing team, then eventually it all falls into the place. But initially you know it is an odd feeling that you know, okay, we are working in a team, but our manager is sitting in some other area, and then you know how would my performance be rated? Because my manager has no idea of my direct work. Po has more ideas. So yeah, there were some. I want to say these are natural issues, or I would say natural things that probably people would run into and problems that are solvable.

Speaker 1:

And one of the things I think is really unusual about the way that you set up the products within your organization is that the product owners also owned the P&L for that product. Is that correct?

Speaker 3:

that, you know, initially our focus was more around, you know, scrum, master, product Owner, getting them trained enough so that we go through this new operating model. In the second phase we started another program which was upskilling of POs and as part of upskilling, you know, the idea was to give them understanding of financials, how to manage financials, understand what does a P&L mean, what does it take, because essentially a PO is sort of a CEO of the product. You know ins and outs, you know the features, the profit and loss. So, yeah, that is something that we have given a lot of attention to lately and quite recently, I mean, I want to say, in the last six months to make sure POs have the right skill set, to make sure that they can manage the product end to end.

Speaker 1:

I think this is one of those things that can be slightly controversial around the job title of PO of, like, product owner. You know, quite often people will say product owner is not necessarily a job title, it's a role within Scrum. And this is why when you're looking at roles and looking at jobs like, it's so important to not just dismiss something straight away but understand what that job title means to that company. Because actually that product owner role within Pfizer like owning a P&L is something that's really unusual, I think, for product managers or product owners especially, and potentially like a very attractive like skill to build and thing to own. So how did it change the way that your product owners operate within the teams, that that additional knowledge of finance and responsibility of the P&L?

Speaker 3:

Yeah, as I said, this is relatively new. In the past six months, where we have, you know, made a concerted effort to give financial authority, or awareness, at least for some, to POs, so far results have been encouraging. We are seeing, you know, a lot of interest. But yeah, I mean, it's too early to tell. I would say, lily, I mean we have to see, because some people, you know, have natural acumen, financial acumen, some people, you know it doesn't come naturally to them, so we have to strike the right balance. So more to come on that, but we definitely do realize that having financial understanding for a PO is important and we want to strike the right balance.

Speaker 2:

What about at management level? So we're here today talking about this because it's been a successful transformation, a successful effort. How has management recognized that, in terms of what are the metrics that they're using to say this was worth our while and things are going well?

Speaker 3:

Yeah, that's a good question. So, as I said, this was conceived by our senior most management and what has been done throughout is that there is a maturity index, surveys that goes out, I believe, every quarter to understand that how are we doing? Are we raising the bar? How's team feeling? And it's not just for PO to answer, it's for the whole team members to answer that Do you understand what your product is? Do you understand what the OKRs are? Do you understand who your customers are?

Speaker 3:

So that is something that is part of our DNA, of this operating model, where we feel that you know, we need to continue to ask the teams if you know what we put together as part of this op model is working or not. And it gets reviewed by our management. They get to see. And out of that was one of the reasons why we decided to upskill PO, because we were hearing that, okay, yeah, we are using Agile, but now that Agile coaches' role have diminished, now teams are pretty much self-organizing. We are seeing Scrum Master becoming Agile coach and they are coaching POs what PO role should be. So that's the sort of feedback that we received and that resulted in upskilling of our PO training.

Speaker 2:

It's good to hear. I've been through places where you know people had a vague intention of we want to be better, but they didn't know exactly what it looked like. They didn't have specific things that they were aiming towards. So it's very difficult for people to prioritize and say this is, you know, after a transfer we may adjust what we do along the way, but this is the effect of what it will look like in the organization. This is how we'll be working differently. This is the you know the effect it'll have on our teams. So it's really good to hear that you have all that in place.

Speaker 3:

The other thing that this operating model helped us with is transparency. So before there was, you know, people were getting hit from all different channels from our customers, so we didn't have a good understanding of which team is working or not. There was duplication of work. But now, because we all are using same tools to track our work, it has bubbled up, at least at the Epic level to see which team is working on what, and that helps with cross-collaboration, reusability and, especially for engineering teams, you know, it promotes engineering culture because you get to know, you know who's working on what, you go, you talk, lunch and learn sessions, community of practices. So there's a lot of other benefits that have come out of it which initially we hadn't thought, uh, thought of. So, uh, so far, yeah, it's been.

Speaker 1:

It's been a success story, but it it has been a journey you seem so calm at if, like you know, having been doing this transformation for quite a while, you're like the uh uh, the shining light of transformation for all businesses that might be thinking of going through this no, I mean, it wasn't me who was doing transformation.

Speaker 3:

We had a whole team which designed it and then the whole another team who mobilized it, and hats off to them. I mean, I was part of the design team and then I led the beacon team and after that, you know, the mobilization team did a phenomenal job with change management, communication, trainings, graduation ceremonies, you know, creating energy around it. Um, so, yeah it. It took a number of us, uh, to get it to the finish line nice.

Speaker 1:

What would you? It sounds like it went incredibly well, but what would you do differently if you were starting again today?

Speaker 3:

yeah. So I think the main thing is to uh, to trust the process. Fail fast and learn fast. Um, recognize that things are not going to go as planned, so be ready to inspect and adapt, be patient and I would say that, be very thoughtful of what problem are you looking to solve, because, as they say, problem well-defined is half solved, find is half solved. So to me, you know, if I were to give, if I were to look back, or I have to give advice to another team who are going to go through transformation is to define your problem statement, spend some time in it. Just don't embark on a journey just for the sake of it, and then be thoughtful around. You know what value you want to get out of it.

Speaker 1:

I think we have time just for one more question, and I'm as previous head of innovation. I feel like I have to ask have you seen, you know, the ability for the teams to innovate more in their work?

Speaker 3:

Yeah, we have seen that innovation has increased in the organization. One of the things we did is we ran a hackathon and I was encouraged to see that the developers who participated in the hackathon came up with innovative ideas using generative AI, came up with innovative ideas using generative AI, so things that they may not have, you know, come up with in terms of idea. They came up with these novel ideas or the new ideas that you know can help us accelerate our work.

Speaker 2:

So, yeah, Atif, thank you very much. It's really nice to hear a happy story in one of these for once, so thank you so much for joining us today.

Speaker 3:

Thank you, lily. Thank you, randy, great to have a chat with you guys.

Speaker 1:

Thanks, Atif.

Speaker 3:

Bye-bye.

Speaker 1:

The Product Experience is the first and the best podcast from Mind the Product. Our hosts are me, lily Smith and me, Randy Silver. Lerun Pratt is our producer and Luke Smith is our editor.

Speaker 2:

Our theme music is from Hamburg-based band PAU. That's P-A-U. Thanks to Arnie Kittler, 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.

Speaker 1:

If there's not one near you, maybe you should think about starting one. To find out more, go to mindtheproductcom. Forward slash product tank.