The product lifecycle unpacked: From concept to launch

Product lifecycle and especially product ops is a newer role that has evolved over the last few years, where it has assumed a greater level of formality.

However, it still isn't consistent. If I were to ask you what one person does in product ops versus what another person does in product ops, you’d see a lot of variation. 

Product operations serves as a backbone for product-led growth by driving seamless alignment between strategy and execution. 

I’ve put three circles in this diagram below. You could put sales in here, you could put a lot more circles in here. But from my perspective, I think these are the core of what product ops means. 

I want to set the stage because when I talk about product lifecycle, it’ll be around this high level of what I think product ops means. 

But before I go further, I will say that this is an awesome place to be in terms of product ops. You get to see everything. You get to see all aspects of the product, from the start all the way to the end, as well as the tracking of it. Your hands are in everything. 

It's a really fun role, and it opens you up to a lot of things that you want to do. You can decide to go into PMO, or you can decide to go into sales ops, or marketing ops. There are even people who’ve moved into product management. It's a good place to come in and see how things move, and then you can decide if this a place that works for you, or if you want to go into XYZ. 

But what happens a lot of time in product ops is that we just end up becoming an ops person. You need to know what you're supporting, and what that product does, and be closer to that. 

If you were to ask me how you differentiate between good product ops versus great product ops, great product ops people are able to intelligently talk about what the product is doing and delivering. You get how to get it done, but just make sure you're close to what product does. Be closer to the content of what you deliver. 

When you think about product ops, in product, you’d have strategy, your roadmaps, and your financials for your product. So your sales, billing margins, all of that stuff falls under your product. 

On the engineering side, you’d have your execution, your customer-found defects, quality, automation, all of those things fall into the engineering bucket. 

And then, when we talk about customer success, this is adoption of your product, your first-time fix, how your product’s doing in the market, and your call volume. All of that stuff comes under customer success. 

I provide this context because some of this will go into product lifecycle. 

What is the product lifecycle and why do we need it?

When we talk about bringing a product to market, when you’re a startup, a 10-person company, founders could sit around the table and say, “Hey, I'm going to bring this product to market. You’ve got to go, you’ve got to go, and you’ve got to go. You're all aligned. Everyone's good to go.” And that’s what happened. It was easy as a startup. 

But as the company starts scaling, you need a framework to get the organization to stay aligned. So, as you become a midsize company or a large company, you need some framework because you can't have 50 people at the table. There’s no table for 50 people. 

You’ll then say, “Who are the accountable parties who need to come to the table to ensure everything is good?” 

One example from when I came to Palo Alto Networks is I talked to around 70 executives, and one of the things that I consistently heard was, “Our products are awesome. We’re doing a great job in the market. But sometimes, the product is so good and so fast in terms of when it’s being released, that the rest of the organization isn't aligned.” 

So, support wasn't aware the product was going out, go-to-market/enablement wasn't aware that they needed to enable the field, and marketing wasn't aligned. 

That’s what a product lifecycle framework does in some ways. It provides the table where you can bring the various functions, align, and move forward.

So, to talk about product lifecycle more, it basically provides a table. Once you're at the table, it says, ‘What are the critical deliverables that we need to complete on time?’ 

Cross-functionally, it aligns all of those functions and ensures you're ready for launch together simultaneously. 

Ensuring cross-functional readiness through the product lifecycle management framework

Like product ops, there are different versions of a product lifecycle framework. The following is what works for us. 

When I was putting this framework together, I spent a lot of time talking to people. And we thought, We’re agile, so should it be more circular versus waterfall? It just feels like it should be that way. 

I will say this: product lifecycle framework has nothing to do with development methodology. Your development methodology can be agile, it can be iterative, it can be a waterfall. You decide. 

But when you're putting something out for a customer, you better not tell the customer, “Hey, I'm going to give this thing to you, but it doesn't work well. We'll come back and do an increment.” You can do betas and you can set expectations, but when you’re giving something to them, you better make sure that something is solid.

Whether it's alpha, beta, GA, or whatever you call it, if someone's touching it, you better make sure it's solid and there’s a plan behind it. Sometimes, people confuse that with, “Hey, I'm agile. I don't need any formality around the framework.” 

When I started, I said, “I don't want you to put in too much process.” This isn’t too much process. It's one slide. That’s all there is. But it's also about educating your stakeholders. Why are we doing it? Why is it needed? And for me, when I talked to people, I learned that there was a gap. 

So, when you're thinking about bringing a product to market, it always has to align with a vision or a strategy. Whatever we’re building needs to align with where the company’s going, especially if you have multiple products, if it's one product, then that will be your vision and strategy, so it needs to align with the strategy. 

Then, when the product manager says, “I want to build X,” somewhere, there needs to be information about what X means because ultimately, someone needs to build X. 

We call it ‘concept commit.’ Concept commit is where you put down the concept and what that means. And then you bring in the respective stakeholders to say, “Hey, this is what I'm thinking.” 

Then you get into the planning section, and I call it ‘execution commit,’ when the engineering and other teams come together and review the PRDs. If you have a PRD, if you're agile, you probably have epics around it, and a high-level estimation around what we're going to be building. If you're doing agile, again, some story points around it.

You bring the cross-functional teams, and then you do some type of fun execution commit, and we’ll talk a little bit more about what that entails in the execution commit. 

Then you get into more of the build. And when I say build, there are multiple teams, so you’ve also got to identify who needs to be at the table. You don’t need everyone for every product launch. If it's a smaller product that you're releasing, you may only need five stakeholders. If it’s a big launch you're doing, you may need 20 stakeholders depending upon how big your company is.

And then, if you're bringing a new product to market, you have to make sure your pricing’s been thought through, your end-to-end orderability has been thought through, your messaging, how you're going to go-to-market, and what you’re going to say. Your enablement activities in go-to-market also need to be thought through, and you need to ensure that everyone has a plan. 

And then we get into bringing everyone together before you go. Are you all aligned? You sit at the table, nod your head, you're aligned, and then you go from there. 

Product ops needs to ensure this is happening. Every company may be different, but I have two orgs. I have a TPM org, which is a technical PM org, and I have a product ops org. Product ops is very closely aligned with product. They basically help ensure that we’re aligned for concept commit. 

They don't do the work, but they ensure the product managers are accountable for coming to the table with the right ask. 

And when we get into the engineering execution, I have the engineering TPM to take on and drive that forward. There are orgs where product ops might run the whole gamut. Again, it varies for what works for your organization. 

I will say that once we go launch, the thing that also doesn't happen as much is how adoption and activation are coming along for your products. Call volume does get tracked, but in those early stages, the first two, or three months, I think it’s important to have one slide that says, ‘What are the four things we will track in the first three months?’ 

It's your pipeline, it's your adoption, it's your sales wins. What are those? You can sit down with your org and say, “What does post-launch look like?” 

Key milestones of a successful product lifecycle management launch

I’ve simplified the previous chart into three things. If you do nothing but do these three things, I think that will really change the game in how you release your products. 

One, when you talk about concept commit, product managers need to explain what’s being built and what the justification is for what you're building. From a monetization perspective, how are we going to bring this to market? 

If there are any dependencies within it, do multiple products need to come together? Do you need IT to do something? Engineering development work should also be called out in there. 

And then, at the end of the day, they should also have a requested timeframe. When do you want this ready? So that’ll be part of the concept commit. 

Then, when we go to execute, I call it eng commit or execution commit. Initially, we started with engineering commit because we didn't even have engineering aligned on the commit. Now, we’re moving to execution commit, which means engineering commits, go-to-market commits, marketing commits, and support commits. All of them come out saying, “We’re aligned to delivering your ask in this timeframe.” 

So, at least you have some commitment from the broader team. And then, all of these teams can go run their process. 

What we ended up doing was once we’d decided who the organizations were, each of the orgs had a mini checklist. 

So, for marketing, if you have to launch, what are the 10 things you do? GCS support, if you have to go start taking the call, what are the 10 things you need to do? You need to train your techs and you need to have your professional services team trained. On the enablement side, you need to have sales enablement trained. So eng/execution commit is that for us. 

And then we go to GA readiness. It doesn't matter how big or small the company is, you can spend 15-20 minutes before you go and release anything, especially for any of the big stuff. For smaller stuff, if it’s an iterative release, if you already have the product launched out and you’re doing weekly releases, monthly releases, you may not need this. Again, you decide where you want to put this framework in. 

But for something that’s going to be a signature moment, a signature moment is anything that we’re going to talk about in the market. If it will be in the news, and our board cares about it, those are signature moments.

Or we call it momentums. Momentums may not be as big, but we may be releasing something every six months. Though it's pretty content-heavy in terms of what we're releasing, what we’re bringing to the market is going to change the game. Those things we call momentum. 

So, for those two, I highly recommend that you have GA readiness. But what does GA readiness mean? It’s product engineering, go-to-market, marketing, support, IT, InfoSec. For us, it’s also compliance and privacy, legal, and cybersecurity.

Basically, you have your owners, and you may have your exec sponsors. Are we all red, yellow, green, before we go release? It’s that simple. But I don't think all companies do that. So putting in this framework has changed the game in how we deliver.

Everyone says, “Hey, is the CC done? Is the EC done? The GA? Those three things are all we care about. 

I'll show you one more thing, and this is our way of tracking this on a weekly or bi-weekly basis. Depending on how big your program is, you want to bring a team back together on a regular basis. You can do it monthly, you can do it weekly, you decide. 

But how are we doing towards the end goal of GA? Are we all locked and loaded? Is marketing running behind? You’ve got to know that. And a launch manager can do this too, but making sure someone is thinking about it is important. 

Getting alignment and buy-in from the top down is crucial

As I think about this more, there were a few areas where we struggled as we were putting this in place. 

Firstly, you can’t do this bottoms up only. You need buy-in from the top down. So that’s why it’s important to get the tops down. 

When I was putting this in place, there were orgs that weren't aligned. Supporting orgs for product were very aligned because they were in the pain. They knew it. They wanted to be in lockstep with product. But product itself were the kings, they weren’t aligned all the time because they could decide to release. So really getting that alignment at the top is very important. 

And then, start small. You don't have to say that you’re going to do this for the whole org. Start with the smaller orgs, start with a few products, show success, and then it’ll start. It’s at a grassroots level. It’ll start holding. And when it starts holding and people start seeing the value it's bringing, people will ask for it. 

Even if I say, “Okay, you know what, I don't want to use this right now because it’s too simple.” 

They say, “No, no, no, we want this because it's easier to get everyone aligned.”

Smriti Motwani, VP of Operations, Product & Engineering at Palo Alto Networks, gave this presentation at the Product Operations Summit in San Francisco in 2023.