How to Transform Product Operations and PDLC to Accelerate Product Agility

Lou: Hey everybody. Becky reached out a few weeks ago, our paths had crossed at PayPal, and she remembered some of the work we did back then. And was thinking there might be some experiences in learnings that were relevant for this audience. Because during our time at PayPal, our product organization went through a major transformation. We went from a decentralized to a centralized model. I was head of product ops at Paypal, and I played a role in the design and implementation of that transformation. There’s a lot we could talk about from that period, but with the time we have together today, I’m just going to summarize the transformation and the outcomes. Highlight key elements of the changes we made and reflect on a few takeaways. While the time period for this case study is about 10 years ago, I believe the lessons learned remain relevant for any company struggling today to keep pace with fast growth. I hope you do too. So let’s get started.

So when Becky and I met at paypal, paypal was just under 4 billion in annual revenue and was still tightly coupled to ebay who’d acquired paypal. A few years earlier, I had been hired to help the product organization build more scalable and responsive processes. At the time. As we were experiencing pretty rapid growth, the primary product delivery model and systems in place were just failing to evolve with the changing business. And that was creating a lot of duplication, friction, reduced output and low morale among the product organization folks. 

Because at that time, we actually had nine product organizations. We had the formal global product organization with the CPO and eight others including four in each of the major geographic sales markets, AMEA, Laam and A P A. We had 1/5 product team that was credit related and a vestige of an acquired company that had yet to be integrated for development. We had a mix of waterfall and agile and some hybrid approaches and in terms of planning, we had this massive annual planning process that could take well into the new year to finish. one underway. 

We used multiple agile and spreadsheet based portfolio management tracking tools. And despite our best efforts, we had roadmap disruptors, primarily ebay could come in at any time and tell us now you need to build X including after the roadmap had been set, interrupting products already in development.

Similarly, BD deals could happen any time during the year. BD might promise features just to sign a deal and that would force us to add additional disruption to the roadmap in order to meet the contractual commitments BD had made. All of that created a ton of backroom bargaining where the various product teams would try to negotiate their own item ahead of another, and even some backroom capacity hoarding, where engineering lead might keep some capacity off the books to deliver something that was a lower priority on the roadmap for some one of the other parts of the organization.

And despite all those product teams and all those backroom deals, virtually everything we produced was for the US markets, international teams like AMEA would try to adapt the US product for their local needs.

So after spending 12 weeks with a cross functional team to design a new model, we delivered a proposal for restructuring that would produce a more customer centric global responsive and agile capital A based operating model. After another three or four months to iterate, iterate, finalize plan changes get approval with the shareholders, we moved to the following. We consolidated into one global product organization where we still retained product management teams and markets, but they were part of the single global product organization and they had a complementary versus competing scope of responsibilities to the core product teams. 

We designed one PDLC and transitioned everyone to agile. Our planning shifted to quarterly planning with some on demand planning In, in the interim periods. For portfolio management planning, we converged on rally for product development plus, incorporated a portfolio of planning tool built by Becky’s organization back then. For ebay and BD, the disruptors that I mentioned, we implemented formal processes for introducing potential product asks earlier in the PDLC. These changes included a strong bias, of course to leverage existing or planned products versus built one offs. 

To make all that work, we introduced a nested set of global and local in market data driven operating rhythms to create a common understanding of needs and resources and to reduce siloed information and decision making. And rather than have the geo markets try to build their own products from the US Center catalog, we learned to adapt core products for international markets and I’ll explain more about how we did that in a couple of slides.

So what were the outcomes? This transformation was a pretty heavy lift, but largely successful in multiple levels. So three of the major outcomes, our launch velocity dramatically improved from less than two launches per year, outside the US we actually got up to over a hundred within two years. We wound up with 30% less headcount, approximately 700 people when we started this to less than 400 when we kicked it off and transformed. And in that process we also created new roles. And our planning got faster, just simply from annual quarterly and then planning that was cascaded down to multiple levels and it became more responsive. Boy, if I go back to the launches, APAC had seen zero products for their markets before we did this transformation. This was the first time we were able to deliver something specific for markets in that theater.

In terms of headcount, we actually had quite a few duplicative if not competing roles and they were producing redundant experiences. We had over 60 onboarding experiences because with nine product teams operating in silos, it was easy to duplicate. But on the plus side, because eBay and PayPal were growing, quite a few of the folks whose roles were eliminated found roles across the two companies. In that last year before change with planning, it had become so painful we actually had senior leaders walking out of sessions out of frustration. Okay, so with all that as context, look at the major changes that we made.

I picked three to talk about. One, creating an integrated PDLC. Two, aligning our jobs teams and organizations to enable the process, how we shifted out of those silos. And three, what were the accompanying operating rhythms and tools to manage the process, PDLC and the teams operating that process. So let’s drill down on each. 

So from an SDLC to integrated PDLC. We actually leveraged earlier efforts in the company to create a single consistent approach, but we also augmented it. For example, we introduced a methodology for customer-centric product design and management. It was a hybrid of design thinking, lean and agile, and we called it CDI, Customer Driven Innovation. The CDI approach ensured that we didn’t just innovate from the center, but that we drew insights from our customers with those product organization team members that I mentioned earlier, embedded in those target markets. We also incorporated some of the key stakeholders early in our PDLC, stakeholders like launch management, risk, compliance, and legal.

We did that to ensure the products were not just innovative and engaging for our customers, but also safe, secure, and legal. I should probably mention before the transformation, these policy teams felt like they had to chase product managers to make sure that their regulatory or compliance issues were addressed in the products about to be launched. Unfortunately, the product managers tend to see the policy folks as friction and people to avoid, people that would only slow down your launch. But they were not just an option, they were mandatory and increasingly necessary.

So what we did in the PDLC is we created three gates in the process for anything on the roadmap at concept time before coding was to start and then before launch for these policy teams to engage with the product manager and their team. And the purpose was at the onset to make sure that understand what was being built and give the policy teams an opportunity to comment on what they needed to watch out for, what they had to do, and maybe there was nothing to do. And then he came back again twice more to see how the product was being developed and to give the thumbs up before launch that yes, this is indeed safe, legal, and compliant.

Okay, what else? With that I probably mentioned earlier, we also connected all this, the PDLC to our strategic planning and a quarterly planning to allow for agile development to cascade through. Which then meant in our integrated PDLC, we actually mandated 100% Agile. Like I said earlier, we did some Waterfall, we did some Agile, we even had some design for Six Sigma advocates before the transformation, but everybody migrated to Agile and our technology product ops team took care of tracking who was certified, what level they were certified, and taking care of training and everything else. So we started out with this integrated PDLC and we matched this with some new roles, teams and organizational models that I’ll touch on next.

As I mentioned in summary, we moved from a siloed and decentralized product management model to a single product organization. In this model, we actually developed two types of product management, core product managers and solution managers. Core product managers were on teams that owned and developed the major products like checkout or credit and were largely headquartered in the US. Solutions managers were product managers living in the principal geographic theaters, North America, Lat-Am, EMEA, and APAC. And their charter was to determine how to best deploy core products to their customers to include proposing adaptations.

Product adaptations were then consolidated and rationalized at the core product level. The core product managers own that responsibility, would look to see to what extent was a request, what kind of demand did it have across the different theaters, and then make decisions about whether to green light its production. Again, adaptation is not new products. Well and to keep these product and solution management teams consistent across theaters and across product lines, we created a global product operations team that provided planning, analytics, launch management, product policy, and business ops services to the core teams and to the regions.

We did that with locally embedded SMEs, just like solutions managers, we embedded the product ops people into those four major theaters. These teams were critical both in initiating the [inaudible 00:10:54] and collectively and regardless of function these product op teams were forced multipliers in that they created a common language and processes for operating day-to-day. They reduced friction, anticipated issues, and provided data and insights to allow for a much better informed decision-making. Which is then a good segue to the third area I’d like to highlight. Our portfolio operating cadences. We established new operating rhythms to dive discipline, focus, progress versus goals, and collaboration.

The improved planning process is just one example that could include solution managers who had to develop justification for those adaptations I mentioned earlier, as well as their own roadmaps and priorities. At the other end, the global core product team prepared quarterly roadmap refreshes and partnered with technology and their OP teams to do those reviews and make sure they were aligned across the business.

We also did monthly theater-based business reviews with the sales teams. Those, and the results for those would be rolled out to global product teams and to the PayPal executive level. That process created opportunity for better conversations at C-Level because the CPO had input that came from the theaters. And then as those sales leaders on the executive level were also present, they could better align on global priorities because they all had the same information. As I mentioned earlier, teams like product policy, we also incorporated engagement guidance from key stakeholders outside the product organization.

And I guess one more worth mentioning is we introduced a BD roadmap process into the portfolio process to stop those disruptions. What we did is we introduced a BD ask earlier in the BD sales cycle so we could understand what the ask was and then rationalize that against existing or planned products that were already in roadmaps so we could guide a BD deal to leverage existing product or plan product versus new one-offs.

Well, there was much more to transformation than just a process organization in these cadences, and there are a lot of lessons learned over time, but these paint a pretty decent picture of what we did. So I’m going to stop there and then review. 

So key takeaways from doing this work. First was we have to lurk, you have to look beyond the roadmap. Of course a product organization is going to invest in some form of roadmap development and grooming along with an investment in program management associated tools. But quite often it stops there and leaders fail to consider additional elements of their operating model and more importantly how that might be changing to meet or to anticipate the involving needs of the business.

In fact, in this case study I just reviewed, the reason we even had to do the transformation is because we were operating reactively, and that’s the case too often, organizations being reactive and adding capabilities, processes or tools only after a breakdown. In my last role at MuleSoft, we talk about paving roads. In other words, how do we anticipate the needs of the organization and introduce those new processes capabilities ahead of the demand. In other words, pave the roads before the traffic arrives. And conversations around paving roads were always conversations about is the infrastructure capable of supporting the business needs and are we anticipating how growth will be impacting those needs and are we expanding those paved roads?

Second takeaway. Adopt thoughtful metrics and tools, including the right portfolio platform. If you can think ahead and lay out what your operating model needs to be, then you also have to answer the question how do you manage it? You need rhythms and tools, and when I say thoughtful rhythms and tools, I mean be deliberate. What are you trying to accomplish and do the metrics illuminate that path? In our case where we’re really talking about a core process around getting product out the door, that also means starting with the right portfolio platform. The number of the tools on the market continues to grow and it is so much better than what was available when Becky and I worked together.

And when we talk about thought rhythms and metrics and tools, it’s worthwhile to remember there is both a tactical and strategic value to having these things in place. Tactically, right tools in place, clarity on roadmap, consistent methodology means less friction and distraction for the folks doing the work. Developers can focus on coding and don’t have to worry about the ancillary things. Strategically, these operating rhythms and metrics obviously enable leaders to make better, more informed decisions, and they can make them faster with the immediacy of the information. But if you’re going to do that, if you’re going to develop and provide these tools, then you need to invest in a product ops team that has a strategic and tactical proficiencies to be able to produce and engage in these conversations. The problem is quite often leaders see product ops as overhead, and they would prefer to invest in one more developer or a UX expert versus a staff.

Well, my experience is that can be bad math. A product ops SME can be a force multiplier and can deliver a higher ROI for their cost. As an example, if I had hypothetically 50 developers and maybe one analytics person on my team, do I hire the 51st developer if I have a headcount, or do I hire a second analytics person? In one case, I’m doubling the capacity of my team. And that analytics SME can access quality or market performance information that might help us gain insights around the ROI of a product and the impact of an entire team of developers. So argument is it’s a good investment. In addition, if you don’t have product ops SMEs to determine those best tools or set up those processes we need to keep an organization running, a product team running, teams are going to make their own. And again, that’s going to divert their time away from their primary role and it’s going to create conditions for inefficiency as different teams create their own versions of different tools.

Without a good planner and planning system, teams are going to build either the wrong stuff or they’re going to build the same stuff in different places. In the case study we just looked at, having the product policy expertise centralized was a much better solution than expecting product managers across the organizations to be experts on the multitude of changing compliance requirements and be able to engage with all those experts on their own. I actually worked in a company that had a senior engineering manager responsible for all things related to the office. He was the most senior person and they made him the office lead, except that included I have a senior engineering manager organizing fire drills and making sure that the coffee machine is working. So just imagine the work he didn’t get to do and the opportunity cost of saving money, but not having a ops person or in this case an office administrator in his place.

And like I said, this is strategic and tactical. So product ops is more than keeping the trains running. From providing data for decision-making to looking at the corporate strategy and helping A CPO understand the implications to people, processes, organization, and systems, products ops, leaders, and SMEs can support or lead strategic conversation and they can partner with the CPO in other functions to keep the business running. 

So as I said at the beginning, Becky reached out to me because she remembered our time together and thought the transformation would be a good case study to share. And while the specifics might be dated, the problems we solve continue to exist in growth companies today. So I hope you think so too. I’m glad I had the chance to share some of my experiences, and I hope it’s been useful. Thanks everybody.

Christina Lau (Host): We will now be kicking off our Q and A session and we’ve got a couple great questions for you, Lou, so if you’re ready, I’ll go ahead and kick it off.

Lou: Sure.

Christina Lau (Host): Okay. So the first question that we’ve got is can you elaborate a little on your formal process for rationalizing disruptors?

Lou: I’m not sure. So the formal process was we convened a cross-functional team of folks and started out with just mapping out what’s the core process here? How do we put product into market? And then we went through and redesigned it from scratch, what should it look like? And once we had confidence that this basic standard process is down and here’s how we want to operate it, here’s the teams we want in place, then we said, “Okay, now how do we iterate on that? Now let’s add a disruptor. What happens if we throw in that BD project? How does that impact here and where does it break things and how do we then evolve the design to be able to include those?”

With BD we evolved into it more after we launched. We had our idea of here’s how it’s going to work once we launch. Once we did it, there’s always this pressure from the business to sell, so even though you said, “Hey, here’s the new rules. You get a new BD…” Hey, sorry, rules don’t count. I just sold this deal and it took us a few iterations to smooth it out and actually took the leadership of the CPO to sort of put his foot down and say, “Not going to build it until we do it.” And we created a new role. We realized we needed a role that would be sort of a broker between the BD organization and the product organization who could then sort of look at the deals in the pipeline early and start that process of anticipating what are they going to be asking for? What are they trying to sell? And how does that fit with our existing or planned features and products?

Christina Lau (Host): Thanks, Lou. So the next question is how did you reliably measure your improvements. If moving from lots of different inconsistent ways of working across so many systems to a consolidated way, since we can’t just use one system for KPIs.

Lou: Right. So the ultimate KPI, was are we actually moving the needle on the business outcome? So are we getting more people signing up? Are we seeing more use particularly in markets where we decided to launch some new feature or product internationally? So for example, free return shipping in France. Then there’s a bunch of metrics around how well is that working? If you think about the metrics, and I didn’t really talk about this in our short time, there’s metrics that are measuring outcome and there’s metrics that are measuring process performance. So when we talk about things like the productivity of development team, pick some of the agile metrics, those are process metrics. This is the process operating as intended. Are people doing more stories per sprint and so forth? The outcome metrics, did you actually make the business outcome? So we use the mix of those, right? So we have the business outcomes, which are really are we actually putting product into market?

Are we seeing people use that product? Are we seeing success on BD? Are we selling BD deals even with this new twist in place? On the process side, we focus… Those things would also evolve over time because the process has a phase where we’re initiating a transformation and then you have a phase where you’re actually sustaining it. So let’s imagine one of the [inaudible 00:22:08] did was shift over to Agile. So shifting over to Agile, we had to train everybody on Agile. So one of the metrics for initiating the transformation is how many people are certified on Agile? How many people have gone through the different gates, level one, level two, level three, and so forth, [inaudible 00:22:19] of the time. Even do we have leaders in place? So it’s a mix of the process metrics and outcomes, and like I said, the outcomes are business driven. They start with strategy and move down. The process ones have a piece of what do you have to do to initiate the change? What do you have to do to sustain it?

Christina Lau (Host): Okay, and so the next question is, as a product ops and transformation leader at a large enterprise, how do you convince functional leaders and executives that the time for change is now and not later?

Lou: There’s a sort of process [inaudible 00:23:01] template way to do it, process way to do it, then there’s this sort of behavioral, maybe political ways to do it. It also depends on what’s going on. So it starts with the case for action. So you need to articulate what is the case for action. In some cases, the case for action is evident, like the business is crashing. So people are already ready, they’re primed. In other cases they’re thinking, “No, no, no.” Or they’re thinking, “Yeah, it’s crashing, but I want to do it my way versus your way.” So how do we do it? So the first is you develop a case for action. So what is the business reasons for making this change and that case for action should address all those different elements. Are there process breakdowns? What are those? Can you measure them? Can you quantify the level of the breakdown?

Like I mentioned earlier, I think we had over 60 plus onboarding flows. Nine organizations and how many duplicate roles and that sort of thing. In that case, fraction you might benchmark against best in class organizations or processes and use that. Then there’s an economic case fraction to make, so on and so forth. You might have customer input, whatever it is, but you come up with the case fraction and use that. Once you get that ball rolling, then you obviously need leadership to buy in. And it involves do you have a senior leader, a CEO, a COO, a CPO that can stand up and pound table [inaudible 00:24:16] “We have to do this and here’s why.” So if we start getting into more stakeholder management, what are stakeholders are afraid of in making the change, and can we address those fears or anxieties? If we can put those to bed and enroll people in the change, then we sort of move past the case for action part. Now okay, got it. I understand why we’re doing this, how are we going to get it done?

Christina Lau (Host): Great process to hear about. The next question is to hire or grow your product ops, what are the key strength and characteristics that you look for?

Lou: Sorry for the bulldog in the background. Hold on.

Christina Lau (Host): Yes, he wants to participate in the discussion too.

Lou: Well, first I’d look to see if they love dogs. That’s a joke. Sorry for that interruption. 

There’s a combination of I’m trying to hire somebody that has a certain competence. Obviously I’m looking to see if they have that competence. I’m looking to understand their ability to engage with other people and be able to sell. So there’s a sales role where it’s again, stakeholder management, we’re going to introduce some new function. Maybe people don’t want to, maybe they don’t know what it is. So does this person have the ability to engage with other stakeholders and senior people and sell it? They have an executive presence for example. So are they a team player? This [inaudible 00:25:46] doesn’t work very well if you’re not a team player because you’re there to enable and support other people, so I need that thing.

So it’s a combination of things, but it starts with what’s the role? What are those competencies I’m looking for? Do they have the agility and flexibility? Do they have leadership qualities? And when I say… They don’t have to be a VP to be a leader, no matter what level of the organization you’re sitting in, you can demonstrate leadership abilities. It begins with, “Am I embodying the values and approaches that I want in this work?” So I’m also looking for that because I need them to not just have the confidence, but like I said, they have to be able to understand what’s going on in the business, adapt their expertise to suit the particular problem we’re solving for, and then be able to influence stakeholders to implement or to adopt the things that we’re trying to implement.

Christina Lau (Host): Okay. We’ve got time for just a few more questions here. So one of them is, do you have any tips on sources for understanding what the best in-class practices are? And also, hello to your dog.

Lou: Cyrus says hello back. Particularly out here in tech world, it seems to me there’s so much variability in the stage of the company, the things that you’re producing and so forth. I don’t know that I have a here’s my go-to Bible. What I have is instead a couple frameworks that start out with… And it was implicit in what I just talked about. Start with, strip it down to the core process. What’s the work that needs to be delivered? And I’m going to give you a bottoms up and a top down sense of what those tools are. The bottoms up one is start with that core process, strip everything out, what are you trying to do? And strip it down to its essence. And then from there, start building up, okay, if this is what we’re trying to do, how do we measure success now? What kind of people need to operate this process?

How are they organized into skills? How are those people organized into teams? How do those teams become [inaudible 00:27:47] so I sort of build it up that way. And that gives me a sense of the structural elements. Then there’s the behavioral ones. What managed systems are in place to make sure that people are operating their process as intended. And management system, I don’t mean by punitive, I actually mean the metrics and the rhythms as well as the incentives. How am I rewarding people for operating system as intended? Or taking care of people that actually are falling or deviant from the process? Then the other part is culturally what values have to be in place? So if I’ve got the core process, the jobs and the management systems to run it. That’s bottoms up. Top down it’s strategic work. So I want to understand what’s back to… What’s the corporate strategy and how do I enable an operation strategy that services that corporate strategy.

And there I start with what are the order winners? What’s making the business successful? What’s the thing that customers really value about the business? The one thing that makes you pick company A over company B. And if I know those things, okay, then my operating model should be aligned to deliver that. If people are looking for innovative products, but I’ve got this operating model that’s operationally excellent and is able to produce the… Stamp up the same thing time after time at scale, those two are incompatible. So from the top down, it’s an alignment to strategy. From the bottoms up, it’s an alignment to process. Then we have to make the two meet.

Christina Lau (Host): Okay, so one last question here along the theme for today. So, Lou, can you elaborate on how your roadmap planning and PDLC intersected?

Lou: So they intersected in a bunch of places. So if you remember in the talk I said we had three layers, actually mentioned two. Solutions management, core product. There’s a third layer underneath called platform services, and below that were infrastructure teams. So I’ll use solutions as an example, and it applies to all. The solutions people have in their PDLC, their approach to how do they identify what they want build, how do they validate it, and then how do they get it into the roadmap? Their part of the planning process included business cases and justification in order to nominate something into the queue. That intersected with the quarterly planning process because the core product teams who were managing those queues would take a look at what was being asked for and build it. We also, by the way, gave those solutions teams their own small group of developers to be able to handle stuff that didn’t need major roadmap decisions.

So the intersection point was at that quarterly level where then the asks that had been rationalized were floated up to the core teams and intersected into the quarterly planning process. And then if I think about… I already mentioned in the talk, how do we do that for the ancillary groups? How did policy teams intersect with the planning process? Well, they understand what was on the roadmap and inject themselves. They basically had their menu of what projects that they have to go after and at least sit in on and see what was going on based on what was coming up on the roadmap. And then we facilitated that by having a product policy team that brokered those conversations between those two groups.