Episode 201: Enhancing Product Operations in Enterprise Software with Mark Rosenberg and Vivian Phinney
I recently enjoyed a conversation with Mark Rosenberg and Vivian Phinney, two leading figures at Workday who are driving transformative product operations.
We covered the crucial role of standardized, data-driven processes that empower teams to make dynamic, cross-functional decisions in real time. Mark shared with me how lightweight standardization enables faster, high-quality product delivery by aligning divisional objectives, while maintaining essential flexibility. Vivian then expanded on her mission to reduce the cognitive load on product teams through selective standardization and streamlined data solutions—ensuring PMs can prioritize effectively and communicate clearly with leadership.
The two of them also discuss the unique challenges and benefits of hybrid product operations, where a central PMO provides universal tools and governance while allowing divisions to adapt processes suited to their unique maturity levels.
Read on to explore some of the best bits from my conversation with the dynamic pair!
You’ll hear us talk about:
07:13 - Building Transparency Through Structured Prioritization and Role Definition
In the discussion about optimizing transparency in prioritization, Mark outlines a new system of scoring projects across the portfolio, helping teams align on Workday’s most crucial goals while preserving team autonomy. He mentions how Vivian played a crucial role in refining roles and responsibilities within the product teams, from inbound and outbound product management to machine learning integration. This included a focus on continuous delivery, allowing code releases to reach testing environments more frequently for immediate feedback. Mark emphasizes that by refining product organization roles, Workday can better anticipate complex needs and scale effectively, building incremental progress that reassures leadership of their alignment with customer needs and business goals.
28:57 - Bridging Central and Division-Specific Product Ops
Mark and Vivian describe here the symbiotic relationship between central PMO governance and division-specific operational autonomy. Mark highlights the need for central standards for broader policies, release management, and compliance, but underscores the importance of giving divisions the flexibility to adapt these processes to their unique needs. Vivian adds that her product ops role involves customizing central policies for her division and regularly communicating back to central PMO about any proposed changes or potential concerns from her team. This two-way communication enables central PMO to make informed decisions, allowing product ops to tailor centralized frameworks to fit division-specific workflows and protect PMs' time, all while maintaining compliance and reducing risk.
41:45 - Rapid Prototyping for PMs
Vivian shares her journey from data science to product operations, explaining how her background in data science equips her with the skills to prototype solutions swiftly for PMs. With a strong grasp of pattern recognition and systems analysis, she can create quick, mock solutions utilizing tools such as Tableau or Jupyter notebooks, providing PMs with tangible tools to assess and refine before any major investment in a scaled solution. Her ability to test ideas with data and iterate based on PM feedback allows her to address their pain points practically and quickly. This agility, she notes, has proven invaluable in supporting PMs directly while keeping internal and central stakeholders aligned.
Episode Resources:
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | Twitter | LinkedIn
Intro - 00:00:01: Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perri.
Melissa - 00:00:37: When starting product operations in a large company, it can be challenging to figure out how to make the case and where to get started. Hello, and welcome to another episode of the Product Thinking Podcast. Today, we're joined by Mark Rosenberg, the VP of Product at Workday Financials, and Vivian Phinney, a Senior Product Operations Program Manager, who shared their story of how they did this in Workday Financials. Their story illustrates how having the right skills and mindset in transforming product organizations can make a huge impact in just one year. But before we go and talk to Mark and Vivian, it's time for Dear Melissa. This is a segment of the show where you can ask me any of your burning product management questions. Go to dearmelissa.com and let me know what they are. Today, we're going to the phones. Let's hear from our caller.
Caller - 00:01:21: Hey Melissa, so my organization has had product management teams now for many years and is now keen to set up a product ops team. There are some general initial ideas of what will be expected of this team, but do you have any advice on how to quickly demonstrate value while the team is still new, please?
Melissa - 00:01:38: So very relevant to our conversation with Mark and Vivian from Workday today. When you are starting out with product operations, you want to make sure that you demonstrate the value of it very quickly. The way that I like to think about this is to start looking at who do you need to convince about this value. A lot of times that's leadership so that you can get the budget. So here I would start with your biggest stakeholders and figure out how you can make the impact and what their biggest pain points are. Some of the biggest pain points I've seen from leadership teams surrounding product management is getting transparency into what the teams are actually working on. In that case, you might want to start with something like implementing better roadmapping processes, a tool that can help surface up the roadmap and make sure that all of the initiatives are written in the same format and you can start to compare apples to apples. In other places, it's been getting the right data to make product strategy decisions. Here, you might want to focus on the data impacts. You might want to go in and start to pull stuff into a BI tool, create the dashboards, create reporting mechanisms so that we can actually track our outcomes over time. That's a great way to look at it too. Other times, it's about how teams actually come together and start working together. In this case, maybe you want to look at processes and governance and figure out how are product teams working with product marketing teams, anything there that can help with the friction. So you're going to approach this very much like you approach product management. Go out and try to figure out who are my stakeholders? What type of value are they expecting from product operations?
Who am I also serving, which are the product managers? And the surrounding teams? And then try to identify what's the biggest pain point I could solve that will help those stakeholders who need to invest in me really see this value and show that this is going to be something that not just helps product managers, but helps the entire organization. If you can start to do things like that, that's where you're going to get the buy-in for product operations. There are also a lot of key studies in our books. If you go to productoperations.com, you can start to read a little bit more about that and buy the book. So I hope that helps. And definitely. Check out the rest of this podcast to hear about Mark and Vivian and how they demonstrated value to Workday Financials. All right, let's go talk to the team. Are you eager to dive into the world of angel investing? I was too, but I wasn't sure how to get started. I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side. This is why I joined Hustle Fund's Angel Squad. They don't just bring you opportunities to invest in early stage companies, they provide an entire education on how professional investors think about which companies to fund. Product leaders make fantastic angel investors. And if you're interested in joining me at Angel Squad, you can learn more at hustlefund.vc/mp. Find the link in our show notes. Hey, Mark and Vivian, welcome to the show. It's great to have you here.
Mark - 00:04:23: Hey, Melissa. Great to be here.
Vivian - 00:04:25: Great to be here.
Melissa - 00:04:26: So, Mark, you have been on this journey to implement product operations at Workday, which is a very large company, and revamp it. Can you tell us a little bit about Workday and what led you to wanting to implement product operations?
Mark - 00:04:39: Sure, Melissa. The organization actually has had product operations for many years, and we've got a central team, now really a hybrid model. We've had in the financials division where Vivian and I work, we've had a product operations manager role. And part of my history is I was at Workday for a couple of years. During the pandemic, family reasons moved away, went to another organization and worked with some really strong product operations folks there and started or continued to evolve my thinking about product operations. And it's actually the time the product operations leader there introduced me to this product operations thought leader, Melissa Perri. So we started to follow the podcast and learning more about your point of view on it. And so when I came back to Workday, as the organization had grown, I saw that there was an opportunity to bring some of that thinking of really modern product operations and evolving some of the things we were doing in financials. And my experience has long been in enterprise products as a financial analyst using enterprise systems, to a business analyst implementing them, product manager building them, portfolio product manager and onward. And so I've seen product operations and the value it could bring. And so when I came back and saw it at Workday, we were really dealing with growth and scale. Our financials customers were approaching 2,000 customers. We're now over 2,000 customers. And when you get that big, you need more leverage and you need to help everybody swim in the same direction, but also do it efficiently. And so I had a few ideas of things we could do. Been working on that with Vivian ever since.
Melissa - 00:06:19: That's great. So when you came back to Workday, what were some of the challenges that you tackled and tried to implement differently than was before?
Mark - 00:06:28: The timing was good. So I came back shortly before a new fiscal year was starting. And I was, when you come into an organization, often good just to do a lot of listening, asking questions like, where can you help? And what needs some attention? Spent a good amount of time talking to peers, folks who were in my organization, and then also peers in different divisions as well that we work with to deliver value to customers. And as I went around, looked at the challenges, and a couple of frameworks I tend to use in an organization, one that I learned to really appreciate when I was at Workiva, frankly, is the Playing to Win framework from A.G. Lafley in the book Playing to Win, where are you clear on the vision and do you have your winning aspiration? Then are you clear where you're going to play? Are you clear then on your strategy, how you're going to play? Do you have your capacity, your capabilities set, and then the instrumentation monitoring systems to support that? And so as I was listening to folks around the organization, whether they were our developers, our QA team members, our product managers. Was the aspiration clear? Was the strategy clear? The industries we serve clear? And then even talking to others in sales and our implementation strategy team, did everybody have the same picture? Saw some opportunities to tighten that up and improve that. And so that was kind of one lens I brought to it. Second lens is I've followed for a number of years the TSIA or Technology Service Industry Association’s model. They've written about the technologies as a service playbook. And basically landing or selling, driving adoption, driving expansion and consumption, and then customers happy and renewal.
And so I started looking at, are we engineering that entire journey as well as we possibly could? Saw opportunities to do more there. And so I took my notes and then got into what could we do most immediately to fix? And so some of it was the team topology, the roles in the teams, the way, for example, how our UX team members were working with the dev and QA and product management folks. Did we have the implementation strategy folks plugged in more tightly enough with us to think about that adoption experience when we put out great stuff. Because we sell solutions to complex business processes. It's not like everything should be naturally intuitive to anybody; Any consumer could just flip the switch and start using it. It's like, not quite; you have to know something about the domain. There's data that's got to be prepped and ready to consume it. Are we thinking about how to make that journey as simple as possible? And so you do that by getting the right people to the table and thinking about the problem correctly. And that then led to probably some of our templates and frameworks needed to, and the way we describe problems, that needed to get tightened up and ask some of the right questions earlier in the process. Do we know the outcome of each feature and the things that we can control? Is it really clear what outcome we're trying to drive for which user? And sometimes that user is an implementation person who's going to be setting up the accounts payable function for a customer.
And then the other thing, as a new leader in the organization responsible for spending on a lot of people or to support a lot of people to building a lot of product, was like, can I make decisions about one idea versus another? Hey, there's a big new customer that wants something. That's great. Sounds like a good idea. Compared to what? And it was hard to make that decision on an organization that was hundreds, hundreds, thousands kind of people deciding what to do. It wasn't easy to make that decision. That made me uncomfortable in my role and saying, okay, we need to put some calories to fixing that problem. So those kind of three things about the team structure, the way we work, and really being able to get that visibility. Those were the big things that just really stood out after kind of applying those couple frameworks to where are we on that maturity.
Melissa - 00:10:27: The visibility piece is always interesting because that's where I see a gap in a lot of leadership. They're asking questions like, hey, what are we working on? What are our priorities? Are we hitting our goals? All of that reporting. How did you think about tackling that piece to get yourself and other leaders in the organization the right information?
Mark - 00:10:45: So one of the things we did, so that actually, it leads into, we got into our annual planning and my peers got in a room kind of figure out what to focus on first. What needed the most change and attention? And we said, okay, first thing, one of the three things that surfaced was a prioritization framework and being able to score consistently across the portfolio. And sometimes folks say, oh, it's top-down. You're taking away autonomy. It's like, well, no, we're just making sure we are aligned to the most important problems to solve to deliver the company's objectives through the work that our division does. Are we contributing there? And so we're evaluating everything fairly and transparently. And that was something that the team, we exited with annual planning. We made that one of our change initiatives for the year. Vivian was instrumental in driving that forward. The other thing we did is that we wanted to talk about the roles or the team's topology and the roles and responsibilities. We decided we needed to get that crisper as well. So we have inbound and outbound product management. Felt like we should really tighten the definition on the outbound, tighten the definition on the inbound. Who's on point for each of the kind of major things that product management is generally tagged with. But also what roles do our researchers play? What roles do our designers play? What roles do our machine learning counterparts play? Because you know what, you know, we've grown up building products that were not 100% based on ML in the early days. So there's a technology inflection point. We've got to make sure the right people are at the table. And what roles do these folks play in the process of building and delivering great product? And then the final one that surfaced was continuous delivery.
And it's always interesting folks like we can push code hundreds of times a day. That's great. But can your customers consume it? And what, what's the business benefit? And we do major releases a couple times a year, but we've gotten really good now at incremental releases. And the more important thing is getting the code out to an environment, maybe not to production, but to an environment that customers can touch it more regularly. So you're not built because we build oftentimes very complex features, you know, to handle multi-currency international demands. It's pretty hard. And some of those can be, you know, very large projects that touch a dozen scrum teams. People go, you know, and I can feel kind of monolithic and go on a long time, but how do we put it out into customers' hands much more iteratively? Even every few weeks, we're putting out something to try another piece, another piece, another piece. And that tooling and engineering kind of mindset shift in terms of how we plan our sprints to get more experimental was the third major thing that we really focused on. And those were key to helping us target the most important things, but then also make sure we were headed in the right direction. So we just, you put them out more incrementally, senior leadership, more confident that yeah. Oh, getting great feedback from customers that yes, we are on the right track. Good work. We're de-risking that bet. And so people start to get more comfortable that you're making good decisions because again, it's expensive operation. A lot of people, Fortune 500 company, we are, there's that good stewardship and the ways to make sure that good stewardship is surfacing up and horizontally. That’s key.
Melissa - 00:14:01: When you were looking to get started with all these great ideas, hey, we got to fix this, we got to fix that. How did you start to execute around this?
Mark - 00:14:10: So we started looking at just some of these things we're talking about, like sort of classifying the problem areas and the things that needed the most attention, that visibility was important. And there were a number of new leaders and kind of board changes in our office of CFO divisions, which is financial, but also our analytics and our planning and our procurement or spend team. And getting everybody seeing the, at least in financials, at least getting everybody seeing the problems, seeing that we could go faster, seeing that we could deliver code more safely, we could reduce the risk of bets. That was a key part of it. And coming back to my initial, just going on a listening tour and really looking for the most important pains and seeing that people were like, yeah, we on scrum teams, product managers, leading individual teams, or products, feeling like we could be faster…we could make a bigger impact, but there's some structural impediments to that. It would treated our teams like customers. And I think that's really the key and senior product operations book. One of the success stories that one of them, one of the folks you interviewed for the book talked about is this, that we've thought about our product managers, those customers, and how do we take the friction out of their day and enable them to deliver better, faster, make better decisions.
So if you are keeping them front center with and making clear to them the goals. But by the way, you know, you need to make sure that the things you're deciding are clear and transparent flowing up and flowing sideways. They got that and like sign us up. And that's where some of the tooling that Vivian was critical to doing was naturally consumed. People were like, thank goodness. This is great. We love it. We're happy to fill in this thing and not these other six things because this makes our lives easier. And we know that leadership is going to be happy too. Let's go do that. So again, it comes down to seeing where the friction was kind of downward, if you will, again, to the team level. And then also up from above, like the visibility to make sure we're aligned to the objectives. And then these major initiatives, they took off. It was very easy to get the traction for them.
Melissa - 00:16:19: It sounds like you had to do a little bit of work to show the value at the beginning for people to say, okay, like we're going faster, we're doing this. What specifically did you use to get buy-in from those other peers that you needed in CFO and procurement and leadership?
Mark - 00:16:34: Yeah, so we started, and maybe good advice or something for those who are kind of at our level, either division leaders or prodops management in a division, take care of your own house first. It's kind of my mindset. I was like, there's a central team. There are product teams that have been around many years. They've got great experience. They're humming along. Let's take care of our own house first. Make sure we're aligned to central, which has certain things. Make sure we push code safely and securely creates pipelines for analytics and so forth. So that's great. But we need to then make sure we're able to answer the mail or respond to executive inquiries in a timely fashion, that we're able to make decisions transparently. So we really started with that and stayed focused on, are we clear? And in that annual planning, we had our head of QA. We had our research and design leaders in there. We had our GM, head of engineering. So we were all there and said, yeah, these are the most important problems. We had strategy. These are the most important problems. Let's go after these. We all believe that this is going to make it better and empower us to show up as a credible part of the organization to our executive office folks and also, frankly, as leaders to many people in our division. And then people in other divisions saw the good work we were doing, too. And so, hey, let's share ideas. So it's been a lot of fun actually helping other teams like, oh, we've struggled with that, too. So it's actually drawn the entire organization together in new ways that was exciting. So from that, the lesson is just make sure your own house is clean first. Get into good habits. Make sure you're transparent. Tell people what you're doing. Explain what you're doing. Explain the business rationale for your investments and whether you're going to change the process, why you're going to change the process, what's the outcome, the value of it. People who know me in the organization are like, oh, you're going to use the word outcome again. Yes, that is true. But in prior life, at Workiva got to have Jeff Gothelf give a training session to us, and he's been on your podcast as well with Josh Seiden, that outcomes over outputs is super, super. It is like the single most transformative thing in terms of getting people to focus on the most important. And it helped us in every conversation. But we do this. I know, but like, what's the outcome? Is it moving customers to get live faster with less friction? Is some somebody going to do something better? When they wake up tomorrow or at the end of the year, some timeframe, you can't answer that. Like, we're not done. And we take that same approach to our products. It's like, are we going to move the needle that somebody is going to be better off, our C-suite or our product teams, whatever that is. So we've not gotten any resistance, frankly, to the ideas we've deployed or looked at implementing because of that product manager for product manager kind of approach. We need to make everybody's lives better and give them clear outcomes.
Melissa - 00:19:33: When did you enlist in Vivian?
Mark - 00:19:35: So I was fortunate to come back and have some great colleagues who knew Vivian. And she's in our Boulder office. And she had joined the team. Oh, actually, she was being interviewed for the role. And I got to interview Vivian. And we talked. And I said, you know, product operations is very exciting, super important to the organization. It's a key leverage for an organization to do great things and to really accelerate. And told her about, you know, if you want to learn more about the role, there’s this thought leader Melissa Perri. You should read the book that she's published. And she’s got another one coming out called Product Operations later on. But it's good reading to kind of learn more about the role. So I met Vivian. And that was the early part of 2023 when we met and she was interviewing for the role.
Melissa - 00:20:26: And when you approached Vivian about this, how did you explain the role? What made you also say, hey, I actually, I need some help with this?
Mark - 00:20:33: Well, the good news is our chief of staff who brought Vivian over knew the importance of it and had gotten her oriented to, hey, there's a lot to do…the tooling, the process governance, the insights and analytics that come to this or that are needed for running a product operation. And she saw that in Vivian and Vivian could clarify in terms of some of the skills that she brought. But some things that I saw is her data orientation, analytics, data science background, her library science and cataloging and categorization. And the other thing, too, is as I learned more through the interviews is her operations analysis background and being able to look at processes and think about them from a system perspective, literally an engineering system perspective. Became, increasingly clear that she had the right attitude to jump on board and orchestrate this big machine or help us orchestrate the big machine.
Melissa - 00:21:33: Vivian. So this is a new role. It's, you know, Mark's like, do you want to jump in here? Tell me a little bit about your background and what made you want to go into product ops?
Vivian - 00:21:43: Yeah, so I do have a background in data and engineering and supply chain analysis, so kind of a fun mix. And I initially started at Workday on the DevOps side. So I was on a team called Engineering Insights, and our entire purpose was to instrument leadership visibility into things like lead time, deployment frequency, mean time to restore, change failure rate. And those are just, in the industry, understood as kind of the four main metrics that drive leadership's understanding of bottlenecks in the software development deployment process. So it sounded very intriguing because it sounded like the opportunity to unblock a lot of people with metrics and with data, just helping them make data-driven decisions. So it seemed like a natural transition to me, but like Mark said, I had never heard of ProdOps before, you know, data science. Data science to ProdOps. This is kind of an interesting transition, but it wasn't until he suggested that I listen to some of your podcasts and, you know, read your Escaping the Build Trap book that I think I heard in one of your podcasts, you and I guess we're talking about kind of surprising good hires that you'd made in the past for the product role. And I believe they mentioned data scientist, and it was kind of a surprisingly positive hire for them. And I was like, oh, okay, see, I can do this. So I remember sending that link to Mark. And then saying, look, I definitely think I could do this. So it was learning a lot about prodops and understanding the similarities of what I have done in operations in the past. But I think that the mentality in DevOps has really served me well in the products area, too, even though I never would have thought to come over naturally without that network connection. But I think it's been a fun approach to learning product management while applying that operations background.
Melissa - 00:23:32: I did a talk at a DevOps conference, too. And we were talking about all the similarities, which I think is really cool. So I'm excited that you came from that type of ops background as well. When you were getting up to speed on, you know, all the stuff that you had to take into account at Workday and figure out where to start. How did you kind of narrow down the scope, figure out where I can dive in, where I can have the leverage for that? What did that process look like?
Vivian - 00:23:56: Yeah, I think as Mark mentioned earlier, it's really leadership understanding how they can apply resources to make the right decisions because the impact of that is so broad. And so for me, with the data background, it was immediately about what you mentioned in product operations where the data just becomes immediately stale. I mean, that's a fact. It will be immediately stale if you live in the environment of spreadsheets and, you know, you don't have specialized tooling built out around it. And so for me, the first challenge that I understood that I had to unblock was just create visibility into how they had resources invested and the prioritization that their team understood to be working towards just so that they could stay informed. And I had to do it in a way where we could standardize the process for teams to surface that information and in a way that could scale to be continuously delivered. So as anyone in data knows, it's... It's always fun to try and mix and match data sources. That's more than half the problem is cleaning the data, getting it together, combining it, understanding what you need to pull from various sources. So for me, I understood that would be the most impactful thing that I could do just to help surface the information to those who could make the decisions that would impact so many people in the world.
Melissa - 00:25:20: What kind of solution did you end up with to make that happen?
Vivian - 00:25:23: Yeah, so ultimately, we started with annual planning, which has since become more of a continuous planning exercise. Because when you're able to surface that data continuously, leadership can make on-the-go decisions about, you know, we got this major request. Can we actually stop this and do that? And so the first thing that I did was trying to understand, I think you mentioned it in Escaping the Build, but it's about standardizing a hierarchy of describing the work being done. And for us, it's interesting because one of the most complex divisions in the company, in my opinion, being new to the app side of it and coming from tools, I definitely understood how complex financials was in comparison to some of our older organizations. And so for me, the challenge was going to be defining the work and creating the least amount of standardization required to be all speaking the same language. Because you can't ask people to put data into a system unless there's some standardization. And at the same time, you have to do it with a change-managed mindset of helping them understand the value. Why are you asking them to do one more thing in their already busy day? And if they can understand that it ultimately unlocks this or it ultimately helps leadership give them the resources that they desperately need. There's been amazing adoption and participation from PMs because they get it and they appreciate it and they're able to speak the same language, which is not an easy thing in an org that doesn't have a standard taxonomy even within our own division, at least we didn't prior to this. And even as we've defined it for financials, it's not the same taxonomy that other colors use. So. Being able to create that and standardize it in a way that surface that insight for leadership in a way that they could then telegraph that up to executive levels and describe their investment decisions has been the first major challenge that I tackled.
Melissa - 00:27:22: After working with hundreds of companies to transform product management, I've discovered one thing that consistently holds both organizations and product managers back from reaching their full potential, the ability to craft great product strategy. That's why I created Product Institute's latest course, Mastering Product Strategy. I've taken my hands-on experience and turned it into interactive lessons that will teach you exactly how to create strategies that drive real business results. Lock in your spot now during the presale with code holiday and save $200 before December 31st. Visit product institute.com today. And from there, you've got the insights surfaced up. People are able to do apples to apples comparisons now across your initiatives or your goals and the different levels. What kind of results did you see?
Vivian - 00:28:04: Yeah, so it's been really fun to do it in a parallel track with enabling the PMs to also prioritize their own work. Our leadership knew early on enabling them to prioritize in a standard way was going to help them understand what decisions to make at their level. But then doing that in a way that also surfaced data for leadership to understand who's doing the work, what work is being done, and ultimately, what is the value outcome that that work is going to drive? Kind of connecting those dots has been incredible. We're still working on refining a few things, but being able to surface that in a continuous fashion so they can see what customer commits are we on the line for? How many are we overinvested in run the business versus grow the business? And for each of those, where do we see the mix spread out? It's really helped them compare their prioritization to how teams are prioritizing, but also just understand how can they resource and enable their own teams? How can they resource and enable PMs?
Melissa - 00:29:07: Vivian, one thing that a lot of people like to push back on with product operations is around this like standardization and process area, right? I think there's like a lot of holdover from Agile stuff where everybody's like, oh, process is bad. Let's not talk about process, right? Let's not standardize certain things. Why are you so obsessed about standardization? Can you tell us a little bit about, you know, what your view has been on that since this is literally the problem that you're tackling in a large organization?
Vivian - 00:29:33: Yeah, so it's interesting because the challenge is always pushing standardization within an org that holds tightly to our own autonomy within the company. So it's an interesting pitch to make that we need to standardize in order to not standardize or be subjected to further top-down mandates or requirements. So I think communicating the value in that, but I think even you had pointed out in products. That it's about standardizing as little as possible to have the most impact. And to me and Mark, that generally translates into, what do we have to standardize to this extent where we can then just get out of the way? Like, how can we get this to the point where we can standardize this? And at least we can standardize, you know, a taxonomy or an understanding of how we describe the work being done to get out of their way.
Melissa - 00:30:27: Mark, from your perspective as a leader, too, what does that type of work help you with?
Mark - 00:30:31: I think that standardization helps in terms of evaluating investments fairly and also in terms of the delivery and confidence in the process, because as we build our products, again, unlike consumer products, oftentimes it's sort of naturally, or consumer web products, you know, you hope people kind of naturally consume them,there's an education process. We communicate out to our community website with the newest releases, the roadmaps. How-to or admin guides, making sure that there's just enough standardization to enable, again, the outcomes. Like, we need people to consume this as fast as possible. So, we want them to go here, not there, or get lost on that journey. Thinking kind of the outcome first and then backing into engineering the system and the processes leads you to, you know, we standardize this. This will make a whole lot more people happy. And being transparent about that and explaining that to your team. So, oh, okay, we get it. Yeah, that'd be great because the customer experience is better. And I think sometimes if you get into, or, you know, the negativity that sometimes surrounds process is that it feels like process has been made by people who are looking at individual, oh, this failed and that failed. Oh, we've got to go close this door and that door and that door and that door. And you pile up all these things as opposed to, okay, well, what are we really trying to do? Let's engineer an optimal system that's as lightweight as possible to get that outcome. And that's where Vivian's operations analysis background, that systems THINKING comes in and you go, okay, well, gosh, if we did standardize this, we limit the chances are going to be a security risk. We're going to chance are going to be, you know, something's going to break, et cetera, et cetera. And, and it's easy to consume and everybody likes that. And then the field team and the marketing teams can, they can all consume it better. So starting with the end point, designing the process and then communicating transparently to your teams and having to go, yeah, you're right. We should just use that model. Not these, not six other ones that we have in place already that we all thought were good ideas. Like, so, okay. And listen, and taking the best of some of those, like and accounting for some of the nuances. So you can, so again, product manager for product managers, Vivian's spent hundreds, if not probably pushing a thousand hours of interviewing people and talking about like, okay, what are you doing? How are you doing it? Right. Why do you do it? And bringing that to shape the templates or the standards that we put in place. So in the end, for me as a leader, I feel more confident that people are bought in, in delivering the outcomes. I feel more confident in the quality of the outcomes and the consistency of the outcomes. Because again, as you get to our size and scale, customers are not expecting six ways to do the same thing. They're like, can you please just like lower the cognitive load on us so we can consume this thing faster. And that comes to good system engineering.
Vivian - 00:33:11: And so additionally, I just wanted to add that because we don't all share a taxonomy within the company in terms of how we define and plan around the fiscal year or scenario map, for me, it was critical to create tooling in a way that didn't require that top-down mandated taxonomy. And so ultimately, we were able to allow the organization to plan and scenario model in a way that worked for their team and our org, and ultimately for leadership to telegraph up the outcomes that would enable, which has been incredibly powerful. We don't require that top-down standardization. We've done just enough, like you mentioned.
Mark - 00:33:46: That's a great point because each of our divisions are in different stages of their maturity as well. The financial division is notably newer than the core HR products that have been around from day one. So our acquired companies are younger compared to the HR flagship. And so those need to think about their investments a little differently. Having that flexibility in the taxonomy and the way we plan, but having tools that offer some of that flexibility. I think that's an important element for folks to think about as they grow or are in a scaled organization. You can't just talk to your friend. You've got to go push yourself to talk to a few other folks and broaden your point of view. And maybe you can't solve everything on day one, but like, okay, we need something that probably is flexible in these ways to adapt to the reality that we've got a heterogeneous organization.
Melissa - 00:34:39: That's a good point that comes back to, I think, centralized product ops versus product ops that is spread into different teams. What's been your experience? You mentioned there is product ops globally there too. Like what's been your experience of having your own product ops? How's it evolved as well versus having that centralized team?
Mark - 00:34:58: Wait, a couple things. I think Vivian's got a great point of view on this. We get a lot of central tooling that is very helpful. And like I said, the delivery systems for product, the standard definition of done, definition of ready, super important. We get some tooling and processing around orchestrating interdivisional commitments. That's helpful for sure. And also our community. We have one community to go out to communicate with customers and our information delivery systems. That is something that every division shouldn't really have to go build. So they provide tremendous value and leverage globally. And then the ability for us to tailor to that maturity of our organization, the topology of our teams, the nature of the problems we're going after. That's where having the having um, I think our this you know, or operating a hybrid model, works uh or comes comes into play, maybe, not I've probably got some thoughts on that further too.
Vivian - 00:36:05: Yeah, so I have a very interesting relationship with central PMO because we work so closely with them, in addition to our internal tooling teams. In a company as big as Workday, that does work as important as Workday, there is a lot of risk in allowing a particular division to have our own processes. So we need the central PMO because they drive the release engineering, the release management, the processes and governance around that. But in addition to what they provide for us to help us de-risk the bigger picture, when it comes down to how we operationalize that, we have the agency within our own division because it works differently for us. So that's where product operations comes in. And the way I interact with central PMO is we have regular meetings where we have conversations about proposals for change. They need our feedback. They need our input on whether something that they want to change centrally will or won't work. So just taking into consideration, how the PMs within each division work. We have our own internal cadences and considerations. So that's critical as well. But mostly central PMO drives the official policies that drive a lot of the release cadence and processes. We are able to leverage that and kind of bring it down to the level that's meaningful for our PMs and kind of protect their time and processes as well.
Melissa - 00:37:25: With that central PMO as well, how are you working together? So they're setting those policies. They're coming down to you. So, what are you bringing back to them as well about what's working for you, what's not working?
Vivian - 00:37:36: Yeah. So in addition to helping them as they get requests for changes from across the company, consider that with respect to how each individual division has to work autonomously. In addition to helping inform them on proposed changes, we can help them roll out that change within each individual division. So there is that standardization. And it just helps the PMs kind of that central purpose of products, which is creating that process, and creating the documentation and knowledge around what they need to do. One, to reduce some of that mental burden on them. They have enough to do. So that's, I would say, a smaller part of my job. But it's certainly, I think of it as release orchestration. So they're doing the release engineering. They're doing the governance and policies. But it's on products to orchestrate within your own division and help it for the purpose of helping PMs at the end of the day. Those are my customers.
Mark - 00:38:31: The two-way flow of communication, I think, is something we've gotten from my first time at Workday and now and to my time here now. I think it's exciting that that dialogue is two ways and our division products managers and team lead, product management team leads are talking more laterally about, hey, is this practice making sense for us? Or could we, hey, we've done this over in this division and we share the ideas and go, you know, let's take that to central. And maybe that's going to be a better way for all of us because we got the intent. We're looking at this on the ground and how to operationalize and it's not quite sticking maybe the way we thought it would stick. But this other team's tried something. Let's experiment with that one instead. And the central team is like, hey, that's great. Yes, let's learn. And so I think, you know, kind of a common theme in business these days about learning, a constant learning organization, a growth mindset. That's really exciting to me personally, seeing the organization. Listening and adapting in real time. And a lot of thought and kind of been written about this in terms of teams, especially in larger organizations. You can feel top down. But the thing that we try to do is flatten the number of levels so that communication is flowing from anybody who has something to share about that process. And really encourage folks to speak up and communicate and make sure. If something's not sticking, they can be heard. And we actually use our own tool, Pecan. Pecan. To gauge employee sentiment and ultimately employee engagement. And so some things, you know, that maybe we've pushed that folks have been frustrated about and they don't want to come and tell me or, you know, or other leaders directly, they can comment about it. And we read the comments and we see the engagement score or some of the themes, you know, whether it's burnout or whether it's like process, there's too much change. So we can get in and address that. And sometimes it's like, okay, what's the root cause of that? Well, it's something central to it, or it's something that we did, or it's something we didn't do. And we're really listening, we're learning, flattening that communication so that whoever's got important information can communicate and make sure that it doesn't, that we aren't doing process for process sake or falling into process for process sake or falling into painful ways of doing things that, you know, could be stopped or should be stopped and changed.
Vivian - 00:40:46: Another example I'll give, a more specific example, is if central PMO is proposing to change the recording policy because of certain requirements from legal, that has completely different implications for our division because we deal with certain industries compared to another. So that's something that bidirectional communication enables is kind of helping them understand our perspective as well, protecting our own PM's interest.
Melissa - 00:41:13: Vivian, you did not come from a product management background as we went through here. And I think some people, when they're trying to hire a product operations role, they're debating, does this person need to be a great product manager or do they need to be a great ops person? Can you tell us a little bit, you read the books, right? I heard that part. Are the books yet upskilled? Reflecting back, what was your process to getting the product management knowledge that you need to be dangerous? And do you feel like you were able to jump in right off the bat and start working? Or do you feel like you had to take a bunch of time and upskill first?
Vivian - 00:41:45: Yeah, so I did need to upskill in terms of learning the process and kind of the operating model that product managers work towards because it's complex. It's complex for a reason because they're providing something incredibly valuable, which is a solution to customers' standpoints and problems. And so your book, Escaping the Build Trap, was definitely my first experience in product management ever. That was my first foray into product management. And what that and a lot of your podcasts helped me understand is at its heart, product management is really about conversing with your customers, understanding the problem before you try and solution it, and iteratively getting it in front of them for feedback. And so enabling that has been easier for me in this role because of my data science background. Because product ops and any operations role, in my opinion, is served incredibly well by someone who is really... I would say keen at pattern recognition and just overall systems analysis because it's all in service of automating workflows in general. So anybody with a data background who's never heard of or considered a product's role, I could not recommend it more highly. It's incredibly fun. You can dive into becoming the product manager for product managers by helping them solve their biggest problems and doing it in a way that they do it themselves, which is getting it in front of customers, talking to them. And making sure you're iterating on the feedback and getting them a solution quickly. Another really positive advantage that I feel my data science background has provided is being able to mock up a solution and get it in front of them quickly. Because I don't need to wait or request that an entire scaled pipeline is built out for me and able to just quickly spin up a Jupyter notebook, get in there, build up a mock-up solution, and kind of combine those data sources that we talked about earlier. And say, if I could combine these for you in this way, does that help this? And really getting that to them quickly because I'm not worried about scaling it. I can solve it first with them and kind of take that solution to our internal tooling teams and central PMO and get support and buy-in for scaling it later. But kind of designing that product and getting their feedback has been enabled by my data background, I would say.
Melissa - 00:44:07: And Mark, when you reflect back on all the things that you've learned about product operations so far, and implementing it, what's been your biggest reflections and lessons learned?
Mark - 00:44:16: A few things that have stood out to me is the, and it comes back to that earlier point we were talking about with the process and program management, is it's a subtle difference between being curious about solving the problem for a customer instead of, I've got to make sure this is enforced or that's enforced. It's about what's the problem that needs to be less of a problem or solved, and what can I do and grab arms with folks around in the org to solve that problem that makes life better for folks. And I think when you bring that mindset to it and you bring, whether that's in data, you're enabling it through data governance and you talk about customer insights and business insights, when you bring that mindset of being helpful and curious, it changes, dramatically, frankly, and people want to get on board with you. They're like, hey, can you help me with this problem? And some of the things that Vivian was talking about, like creating those dashboards and locking them up, like, is this going to help? And people are like, oh my gosh, this is fabulous. Yes. Like, can we have more of those? And sure. And we want to see the layout of people by the level. Sure. And we want to see by location. And quickly iterating to, again, solve the problems to help people get their job done. The real power of that, I guess, earlier in my career, wasn't quite as clear. It wasn't clear to me. And so now when we came back, like, this is about making the team better, not about enforcing the process. And it's both, but it's about when you make people better, they're excited. Your engagement scores go up. As a people leader, that's good. And you get a great energy behind you. You get people growing. You get people wanting to participate in new efforts. And that's usually how people will grow. They'll grow through gigs or trying. So people come like, hey, can I help Vivian on this product thing? So that's been super interesting, for me. And then I think also from a product perspective, how does product help folks get or see the importance of certain trainings and skill building that they should be taking a look at? So we, as a central kind of team, if you will, or within our division, we think about what are the skills that are inhibiting our doing some of these things? Let's figure out the best way to get people trained. And so we're being more deliberate about that. I'd say earlier in my career, I wasn't quite as deliberate for my team about that. And so I kind of view that as the product's role of like looking at the problems, looking at where there are friction points, looking at where folks maybe don't have the skill. So one skill we invested in recently or heavily is facilitation skills. That's, that's been pretty important because especially in finance division, you know, a lot of us kind of grew up as accountants or operations analysts. We maybe weren't, we weren't as outgoing as our design and research colleagues who love to be talked to. You know, we're like, well, we talked to a customer or I did the job. I know what to do. And you go, you want your natural inclination to go build the thing. It's like, no, we got to get more comfortable being uncomfortable, hearing the hard news from the customer and talking to enough customers. So, you know, that just doesn't happen naturally for many of us kind of accounting oriented folk. Um, so again, looking for where can we get leverage and kind of push a theme skill wise, super important. And then I'd say the other thing too, from a product perspective that, um, that I learned is that, uh, we had a mindset of, it was a trio, but it wasn't the modern triad as it's kind of referred to by folks like yourself, a lot of leaders in, in product management. What I realized is as with any model, you've got to bring it to your organization. And when I looked at our organization and the complexity of the products and these large multi-step multi-role business process solutions that we deliver, a lot of people need to come together to make that happen. And it's just the traditional triad design PM and coming together isn't complete enough for our business. And so to make a point and get people kind of scratching their head, I turned it to, folks, it takes an octad or eight functions within our organization to deliver great solutions. Now, there are certainly other roles, but I was trying to make a point within product, the engineering or the development and product organization. We've got PM, but we need UX research and design and information development documentation and QA and developers and probably an advanced technologist or AI expert and program management to come together to make sure that we are delivering the thing because empowered teams, but not aligned. Or chaos, and you create more functional and dark and technical debt on your customers and experience debt. You've got to have the right team structure to deliver these more complex processes or complex solutions to customers. So that was the other thing that kind of emerged to me over the years is I was just like, there's just not something quite right. This trio isn't getting the outcomes we need. And if you're looking at, and so my thoughts to other folks is like, what do you actually deliver? And if it's a standard consumer product, then maybe just that trio is great and it's all you need. But in our world, it wasn't cutting it. And we needed to think about what's missing here. And certain brains aren't at the table to think about that journey from zero to hero for our customers and getting them excited to sign the renewal check when we send them, hey, would you like to renew your subscription? They're like, heck yes, because I got the value and you made my journey to value easy. That needed a few other functions to come together and be part of the process.
Melissa - 00:49:38: Well, thank you so much, Mark and Vivian, for sharing your product operations journey with us. If people want to learn more about you, where can they go?
Mark - 00:49:46: So for me, if you look up Mark Rosenberg, M-A-R-K, Rosenberg and Workday on LinkedIn, you'll find me there. I'm happy to hear from folks about what we do.
Vivian - 00:49:56: And for me, I'm also on LinkedIn, Vivian Phinney, P-H-I-N-N-E-Y. And I would love to interact with or answer questions for any individual contributors or anyone considering joining the Prod Ops role.
Melissa - 00:50:08: Great. Well, thank you again for being on the podcast. And thank you to our listeners. We will put those links in our show notes at productthinkingpodcast.com. Make sure you like and subscribe so you never miss another episode. And we will see you next week.