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 Perry.
Hello and welcome to another episode of the Product Thinking Podcast.
Joining us today is Vijay Pichimani, Director of Product Light Cycle Management and Governance at Okta.
Vijay has been instrumental in building and optimizing identity governance and light cycle management products.
His impressive career includes leading integrations with Microsoft and Azure, driving predictive analytics at Spark Cognition and winning the VMware Hackathon.
Today we're going to go into a hot topic all about how we effectively do platform product management and what it takes to be successful in that job.
But before we talk to Vijay, it's time for a segment on Dear Melissa.
So this is the part of the show where you can ask me any of your burning product management questions and I answer them every single week.
Go to dearmelissa .com and let me know what you want answered.
Here's this week's question.
Dear Melissa, what are some ways to best support a PM who's burning out?
Nothing they are working on is outside of what a PM should be doing, but the job is a lot.
And it's not just one PM, it's a few of them.
And so that tells me it's something more than a localized problem.
What are some ways to combat this fatigue?
So when it comes to fatigue for product managers, that is nothing new.
Product management is a really big job and I hear more and more about people burning out every single day.
So we have to start looking at what are the sources for that.
One source that I find is changing strategies.
So I'd look beyond just what the product managers are doing and try to look at what is leadership doing.
Are you creating swirl?
Are you changing priorities all the time where product managers feel like they're making a lot of progress and then all of a sudden they have to stop and start over again.
Are they able to empower themselves and make their decisions about strategy?
Or are they being told what to do?
Are we reprioritizing things all the time?
If you don't feel like you can actually get things done, get things out the door as a product manager and see what those results are and make informed decisions off of them, it usually does create a lot of fatigue.
So sometimes it might not just be the work that the product managers are doing on a day -to -day basis, it might be the work that the organization is doing.
And how we actually prioritize that work, how we think about our goals, how we think about getting them done.
So, I see changing priorities and strategies be a huge fatigue driver for product managers.
I would really look there.
And if you do find that, then I would say, how do we start to stabilize that?
How do we make sure that we have strategies that are at the right level of every part of the organization?
We've got leaders that are thinking further ahead so that our product managers can think, you know, six months to a year out and start to figure out what is the vision that we're building and build for the long term.
They're not just responding to short -term requests.
So we'd look there.
Another place, though, you said that nothing is out of the realm of what a product manager should be doing, but what should a product manager be doing?
Sometimes we are taking on a lot more as a product manager than we should be.
We're out there learning SQL so that we can actually figure out how to pull the data.
We are trying to figure out how to build the processes around doing product management rather than just doing product management itself.
This is where things like product operations comes in.
Now, a lot of people see this as a rite of passage.
Like, why can't a PM just go learn SQL?
Why can't a PM do this?
It's because it is a lot of work.
You have other things to be doing.
Your job is to go out there, talk to customers, figure out what their problems are, help run experiments, identify what those right solutions are with your team, bring these stakeholders together, communicate these launches, all of this stuff.
Just adding a couple things on top of it could be the straw that breaks the camel's back.
So here we really need to understand, is this really what a product manager should be doing, or are these things that we can actually automate or centralize and take off their plate so that it can make them be more effective?
And they don't feel like they're just doing grunt work.
So I'd really encourage you to look at what your product managers are doing.
Is it central to making decisions about what products are going to solve customer problems and provide business value?
Are there things that they're doing to help enable those decisions to be made that don't necessarily have to fall on their plate?
Things like getting data out of pipelines or trying to track it down all over the place or aggregate user research that's all over the company.
These are things that could be automated.
These are things that could be taken on by product operations.
And a little bit goes a long way here to helping product managers lighten the load and be able to concentrate on the work that really matters and follow through.
So I'd really look at those things.
Look at your culture.
Look at your strategy.
Look at how product managers are enabled, but also really analyze their work and say, is this something that a product manager absolutely has to do?
Or is it something that we can pull off their plate, automate and centralize, or have somebody else do so that they can focus on the work and they're not drowning?
So that's incredibly important.
So hopefully that helps you lessen the load a little bit on your product managers, bring them back to life a little bit, and I wish you the best of luck.
Remember, if you have another question for me, go to DearMelissa .com and let me know what they are.
Now, let's go talk to Vijay.
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.
Welcome, Vijay. It's great to have you on the podcast.
Hey, Melissa. Thanks so much.
Pleasure to be here.
So, you are a director of platform products at Okta.
Can you tell us a little bit about Okta and also what products you oversee?
So, Okta is an identity access management company.
We build software products that we sell to organizations across the world.
And organizations use Okta to secure access and secure identities and ensure that they get protected from any security breaches or threats.
Like, that's the primary purpose of the software that we build.
At Okta, internally, I lead multiple product lines, so I lead a lot of our core directories.
So, directories are a fundamental portion of any identity and access management platform.
So, I own the core platform, and then I also own life cycle management and governance, which are two other new product offerings that we've had.
So, you are director of platform products.
Can you tell us a little bit about what are platform products, and how are they different from user -facing products?
So, when you think about a platform, right, like, so the way we internally review a platform at Okta is, a platform is something that serves multiple customers, multiple personas, multiple use cases, and it's not effectively targeted at, like, a single persona.
So, for example, the directory product that we have internally at Okta, the directory product actually powers multiple different product lines at Okta.
It powers the single sign -on product, the multi -factor authentication product, the governance and life cycle management product.
So, really, when we think about building the platform, we always think about, how does the platform evolve to meet all of these different use cases, right?
So, that's how we fundamentally view the difference between platforms and products.
The platform addresses much more broader use cases and unlock newer capabilities overall.
What are the challenges of building out products that don't have user interfaces?
Platform products are typically, like, a classic example of that, right?
So, for example, the core directory that we have at Okta, I mean, it has a user interface, but it's primarily an API -driven product.
And so, we expose API interfaces for not just our internal teams, but our external customers as well.
And so, when you think about the challenges, it really comes down to when you want to ship, let's say, newer capabilities in the platform.
Those newer capabilities, you need to have a broad spectrum of an understanding of all the different ways customers interact with the platform.
And then, when you think about building newer features or newer capabilities, you have to understand how these newer capabilities address multiple of those use cases.
It's not just a straightforward, okay, here's a single customer persona, here's how this is going to use.
So, it's like a different way of thinking about it in terms of how broadly do these capabilities apply across different product areas.
What are types of customers that you're serving for and different types of personas you're looking at?
So, think about, from my day -to -day job, the platform components that we build are used by internal teams at Okta.
So, effectively, we expose API interfaces that internal teams at Okta leverage to build products that their customers have.
Second, we expose our APIs, our interfaces, to external customers, as well, so that customers can effectively manage identities inside their organization.
Then, the third persona that we actually also serve is, think about anyone who wants to build integrations on top of Okta, right?
And so, we ship API interfaces that enable customers to build integrations, as well.
So, I could just think and explain three different, completely different personas that any object that we ship just immediately gets exposed to across the board.
It's interesting, too, because I think a lot of people would listen to this and say, oh, it's just developers, but there's all different types of developers you're actually building for.
Exactly. Because, like, the needs of these different types of developers are also evolving, right?
Like, from a customer perspective, the specific job to be done is different, compared to, like, an internal developer or an internal employee, compared to, like, ISVs.
So, really, the job to be done across these different personas is just drastically different.
And so, it's really important from a platform perspective to think about all of these personas when you build new products.
When you're looking at that, too, roadmap is always, like, a hot topic when it comes to platforms.
How do you approach road mapping for your platform products, and how do you juggle the different types of personas, but also the different needs of areas of the business you might support, too?
That's a good question.
I mean, so, as a platform PM, one of the foundational challenges is really, you have to juggle the priorities of multiple consumers.
There's not a, here's one single business outcome that you're trying to drive, because sometimes, platform PMs might be a dependency in multiple different business outcomes that you would have.
And so, from a road mapping perspective, I think it's really important to be aligned top down, in terms of just saying, okay, here are all of the business outcomes that we want to drive.
And then, from a platform PM, you have to prioritize the effective trade -offs, because, I mean, at the end of the day, a platform PM is also like a product PM.
You have a finite amount of resources, a finite amount of time, and you need to get a finite amount of work done.
So, it really comes down to very effective prioritization and trade -offs across these business outcomes, and clearly communicating and articulating those trade -offs so that teams are well aware of, here is how the platform's evolving, so that they can go ensure that expectations are met correctly.
When you're communicating those trade -offs, I've found a lot of people struggle when it comes to highly technical products, or platform back -end products, too, to describe what the business value is of them, right?
Like, if we decide to build a microservice for, I don't know, scheduling, that services everything else, they're like, how do I put that back into terms, because it feels more like a tech decision than a business decision?
But then, leaders always want to know what's a business value here.
How do you explain that?
One of the things that we want to do is reduce the amount of infrastructure that we want to consume in terms of, like, just seeking identities into the platform.
And so, the biggest challenge for us was, okay, we want to do this because we know that we want to make the overall pipeline of creating identities much more efficient, but how do you communicate the best?
Why would your CPO care?
Why would, like, your product leadership care?
And I think if you ask that question, I think it will start answering a bunch of those answers.
So, for example, one of the things, always, we justified it was saying, hey, we went and found out support tickets that were tied to just lagging identity creation.
And so, we were like, okay, maybe one vector is to figure out how do we reduce support tickets.
Another vector is to figure out how do we make sure that we improve the overall customer experience.
And so, improving overall customer experience naturally leads to more attention and more customer satisfaction.
So, if you think about it, it doesn't always have to try to new revenue and getting new customers.
It can also try to, how do we improve existing customers, improving CSAT, improving, like, the overall experience of using the product, which I think is really important.
Can you tell us about a time, baby, too, when you had to justify getting ahead of a platform development?
Maybe it wasn't, like, crashing now, but you knew it wasn't going to scale, or it was going to crash later.
I always find that one difficult.
I can actually give you an example of something we did internally, where one of the biggest challenges was, I mean, this was just from my past experience.
One of the biggest challenges was just that the entire software stack was not, like, modernized, right?
So, from a development perspective, we wanted to go both towards a completely microservice -based architecture.
And that was something that it was a really heavy lift from an investment perspective.
But then it goes into the classic conversations on, okay, how do we justify this investment?
How do we stop other, like, product investments, like, and things like that?
And so, this is where I think PMs can add real value, because, like, one of the strategies we took in executing those projects was really working it out from an engineering counterpart and PM perspective and saying, okay, let's make sure we prove value over time.
Because these projects are traditionally long -time projects.
So, how do you break it down into smaller chunks?
How do you keep measuring progress?
How do you track success over time so that you can quickly iterate and change?
And this was, like, just how we were able to get ahead of the curve in proving value to, like, leadership.
Because in each phase, you can then communicate to leadership, hey, maybe we spent the last quarter, 30 % of the time on this, and look at the value you had.
And, you know, that's how you justify value over time.
I was involved in a big re -platforming, one set of a company as well.
And we originally didn't have product managers associate with it.
So, the strategy was, like, to pull off whatever could be a microservice fast and just do that.
And we found that nobody was actually consuming the platform.
Nobody was using it.
So, we're spending all this time trying to release something, get it up and going, and there was no value there.
When I think about going back, and we put a product manager on there and rolled it out with a real, you know, vision and strategy, and it worked great after that, it really demonstrated the value of having product managers there and not just being tech -led.
Totally. Yeah. Because, like, that it really comes out to articulating that vision and breaking that vision into tangible milestones or phases.
That really helps to demonstrate the value.
And it's not just to product leadership, right?
It's also to your external stakeholders as well, because, you know, you have to be answerable to your customers because there's going to be a bunch of customers who are waiting to get more product capabilities or more features.
So, you have to go and say no, not just to your product leadership, but to your sales people, to your customers.
And articulating the value of how the world is going to be better once this platform initiative is done, I think, is really, really critical to the success of the overall initiative.
When you're thinking of juggling those different things, right, you've got some platform components that go externally.
Customers are directly using them, and they integrate with it.
There's other platform components that are solving problems for people internally in your organization, and then you've got a whole host of other things.
How do you think about prioritizing that landscape, right?
Especially when you've got some tech demands warring with some business demands?
I mean, from a prioritization perspective, it really comes down to, I think, we have to have an apples -to -apples comparison.
And the best way I found it really successful is really converting each of the priorities we have, articulating the business outcome, and then weighing the business outcomes in terms of, okay, what are the trade -offs that we are willing to make?
Because sometimes, ultimately, business needs to be successful.
And we all need to make sure our customers are as well.
So sometimes it might be that, hey, it is really important that we have to go build this net new product offering that is extremely strategic for the business.
So that might mean the over -index on building new product capabilities.
Sometimes it might be like, hey, the business is really trying to ensure the incentive -wise existing customers and making sure they're successful in adopting the platform.
So that would mean evolving the platform and making sure more customers engage with the platform and track metrics.
So I think it's really useful to align the platform roadmap with the broader business outcome and the business roadmap so that we are solving a shared set of outcomes.
Because if the platform is mess -aligned with the business outcome, then I think that's a recipe for trouble.
What process do you follow or what kind of activities do you do to make sure that your roadmaps are aligned back to the business?
Do you have, like, planning meetings or cadences that you follow there?
The way we do it is, I mean, internally at Okta we follow something which we call vision methods and targets.
It's a BMT framework.
It's very similar to, like, the OKR framework that's used by Google.
So internally we have the vision method and targets and those are set at, like, the business level.
And then eventually we can then trickle down into the planning process where there's effectively a planning, right up front in the year, where we say, okay, we know the business outcomes.
Here are the different ways the platform could evolve.
And then we have quarterly meetings to evaluate check -ins.
We, like, once every six months is where we do a – it's a bigger event where the team comes together, it's, like, an offsite.
And then we evaluate whether we're going in the right direction or we have to pivot or not.
And so usually these check -ins happen once every three months, I'd say, where we are, like, okay, are we making track towards our business goals, our metrics, how are we trending and what are the things we need to pivot?
Because those frequent changes are needed.
What are you looking for, too, from, like, a platform team to make sure that you can prioritize effectively?
Do you have to wait for some other roadmaps to be built?
I know you have to wait for the business goals, but what types of things are you looking for?
So I lead a team of awesome PMs who lead, like, platform capabilities as well.
And this is one advice I always give them, which is always think about end -to -end scenarios.
Because, like, one of the biggest challenges from a platform PM perspective is sometimes there might be some misalignment between platform capabilities that will land and the products that can actually consume the platform capabilities.
Because it's very difficult to align all of these in the exact same time.
And so my guidance always to my platform PMs is that if you're shipping a platform capability that is meant for internal products or internal teams to use, make sure you align the roadmaps to the best of our ability, because I can always ship an MVP with just the platform capability and going to the customer.
But then, over time, we need to make sure that the platform and the product capabilities are really working together well to serve the end -to -end.
And so my guidance to my PMs is always that, which is make sure that you write that alignment between platform and product teams.
And it's a challenge.
It's not easy. Yeah, I think that's one of the things that most platform PMs complain to me about the most.
It's like, what am I supposed to do when I have to go, like, drive all this alignment and do all this work?
What are types of ways that you encourage your PMs to drive alignment?
What should they be doing on a day -to -day, week -by -week basis?
Think incentives. So one of the things I always tell my PMs is think shared incentives.
Because, like, you know, from a platform PM perspective, I think it's really important to talk to your fellow PMs in those incentive terms and make sure you communicate with them.
How you're going to make the other team successful.
And that is how you really drive alignment.
Because, like, the platform is, I mean, again, it depends on who you're building the platform for.
And in this case, I'm talking about a platform that is serving internal teams and internal customers.
And so if you make sure the platform you're building is serving internal customers, you need to make sure that you go to them.
Have, like, a shared incentive model plan properly where you can articulate to them, okay.
Here is how both of us can go and jointly make the business successful.
And that is going to be the biggest key to success.
Because the incentives need to match.
Because many times, the difference where you don't get this alignment is because incentives are different and priorities are different.
So you need to make sure that you need to match the incentives to make sure that you can ship end -to -end.
Platform, too, it's interesting because we think of a lot of, like, user -facing products having a vision, right, that's clearly, like, articulated back to the customer needs.
And there's definitely parts of the platform that have that as well.
But there's other pieces that are enablers.
But the platform itself needs to have a vision.
How do you think about crafting a platform vision?
And how is that different than maybe, you know, a workflow, you know, app or something like that that we're used to?
So, again, this is another interesting challenge, and it's actually something that I'm really passionate about, which is when you really think about the vision for a platform, like, I mean, even product visions are usually, like, longer term.
But when you think about product visions, it's more easy and tangible where you can say, hey, I'm going to ship features XYZ, and then I'm going to track an option of the products.
Whereas from a platform perspective, it's going to be more difficult for you to say that, right?
And so when I think about the vision, I'm basically having to articulate to my team, here is where the business needs to be in the next, like, three years, for example.
And so this is one thing.
We built a new platform component for one of the net new products that we had.
And one of the biggest things that we had to do was really try to anticipate what are the other use cases that customers might have outside of the predefined MVP of the platform.
Because when you design a platform, it's really important that you design the platform for the long run and not have a myopic view on the MVP.
And that's, like, a fundamental difference between a product PM and a platform PM.
Whereas from a product PM perspective, you'd be like, wait, I'm going MVP, I get the MVP done, I'm going to iterate after the MVP.
Whereas from a platform PM perspective, it's going to be very difficult, like, there's no changing API contracts after you go out to MVP and people start using the product because people are going to complain a lot.
And so it's really important that we have open discussions, have workshops where we anticipate, like, the next two, three -year need, and we make platform decisions that are aligned to that goal.
And those goals could be not just ways how you engage with the platform, but it could also be nonfunctional requirements.
Like, think about scale.
Think about, like, how many API requests are made in a second because all those are going to be tied to the technology choices that you have to make.
And as a PM, it's really important to give your engineering team insights into these kind of questions so they can go make the right decisions.
So what types of things should a PM be helping their engineers understand when it comes to these long -term, you know, visions?
Give your engineers, like, my recommendation to PMs always, and this is something I've personally used, is give them a market sense.
Give them a market sense of where the market is evolving over the next three years, and what are the different ways the platform could evolve to meet those needs.
And it doesn't have to be fully jotted down end -to -end user stories.
But it can really be at a high level where you can say things like, hey, maybe the platform can support use cases XYZ to begin with.
But in three years, I really anticipate the platform to support use cases A, B, and C.
And just giving your engineering team that clarity of, here is where we are going, will really help them to make a lot of tech choices behind the scenes, articulate the data model really well, and really ensure that, you know, they build a platform in the right way that are not going to lock you in from expanding
to those use cases.
Because, like, you know, it's really important that you expand over time and address your use cases as you go.
With that, too, there's always been, like, this little conversation about, should we have product managers on platform teams or should it be tech -driven?
You are on the same page as I am that you should have product managers, and we talked about why, so you're not tech -driven there.
But what does a platform product manager need to know?
Like, how is that different than somebody who's working with user interfaces?
100%. I mean, I'm firmly on the page of a strong team that builds products, needs to have a product manager.
And at the end of the day, platform is also, you're building a platform so that people can engage with the platform and get things done.
So at the end of the day, it is a product.
So you absolutely need product managers.
Now, what are the things a platform product manager would do?
What value they would add different to PMs that have user interfaces?
I think it's really articulating the success metrics.
Because one of the things that I have seen is projects that engineers are extremely capable of leading and driving projects, right?
Like, I'm not saying engineers are not capable of doing anything.
But I think one thing that engineers are notoriously prone to is they're prone to optimizing for the best possible outcome.
And sometimes optimizing for the best possible outcome really goes or takes a really long time without getting the right customer inputs as you go.
And so from my perspective, the real value add, I think customers can—PMs can drive in platform teams is define your success metrics.
Define, here is how I'm going to measure success of the platform and break it down into individual chunks, break it down into smaller measurable targets that help you to go to customers or go to your consumers of the platform and really get that signal.
Get the signal to make sure that you're building the platform in the right way.
Because having that tight loop is really important to quickly iterate and evolve the platform to meet your use cases.
And so that would be my recommendation.
That's like the value, I think, PM square.
Did you know I have a course for product managers that you could take?
It's called Product Institute.
Over the past seven years, I've been working with individuals, teams and companies to upscale their product chops through my fully online school.
We have an ever -growing list of courses to help you work through your current product dilemma.
Visit productinstitute .com and learn to think like a great product manager.
Use code thinking to save $200 at checkout on our premier course, Product Management Foundations.
It's making me think about Discovery too.
So in user -facing products, we talk a lot about experimentation and, you know, MVPs and getting things out fast to customers and iterating on it.
You talked a little bit about how you can't iterate on everything in the back end with the platform because you have to think about scale, where it's going to go in the future.
Is there room for experimentation on platform teams?
And if so, what does that look like?
What can you experiment with?
What can't you? Oh yeah, there's plenty of room to experiment with, like from a platform.
In fact, I think shipping platform capabilities is actually like a very cheaper way for organizations to get quick signal from, right?
Because let's take, for example, like I'll talk about from my personal experience, right?
Like when we build platform capabilities, one thing we usually tell our PMs is, let's ship the API first and let's go and give the API to like 10 customers and see how the customers are able to interact with the API, get the job done.
And then based on that, we'll go and figure out whether like what the user experience is going to be later, if we need to build the user experience and things like that, because it really helps us to quickly validate concepts, quickly validate ideas.
And so that's just how platform teams can quickly iterate on because again, like it really depends on how you're going to measure success over time, because like if you say, okay, I'm going down a certain path and this is the goal for me the next three, six months, you have to get that customer signal
as you evolve over time.
So it sounds like you can actually be the experiment person for some other people, too.
So you're using all these components to run experiments.
Yeah, exactly. So think about like, again, let's take the other scenario, which is I'm building platform components for individual product teams internally, very well, the heart of a product PM for a second, and I'm dependent on a platform team to give me a capability.
I can just work with the platform PM to be like, Hey, can you just give me this capability?
Let's go do a beta on just the capability alone.
We'll try to get signal if like, you know, customers are able to do it because I might just write a script on top of the platform component to interact with the API and get a pulse of I can use a postman query to get a pulse of inputs and outputs.
And then I can go show this to a customer to say, Hey, here is the data that you're going to get from the platform.
Is this data valuable or not?
What are the data you would expect to see?
How would you interact with this kind of data?
What would you expect to see?
Those are all really valuable questions and inputs you can get with very limited product investments.
And so that's what I meant by like, it's very easy to quickly get the desired inputs from a platform perspective.
So if there's a product manager out there listening to this right now and going, Hey, I'm going to go to my platform team to see if we can build some API's with it.
How do you suggest they help get buy in to do that with the platform team?
If it's something like, Hey, we want to run a quick experiment or we want to do this, and you're not necessarily in the full on roadmap, how do you go back and justify that between teams?
So one of the ways I found success is so usually, I mean, this is true on both sides of the spectrum, whether it's a platform PM or a product PM.
But there's always room to negotiate like the one or two weeks worth of effort.
And so my guidance to any PM watching this is have like a time boxed experiment.
So think of these as small product experiments that you do.
Like, so that's something I encourage my PM's to do as well, which is, how can we time box something to like two weeks and see if we can ship something quickly that is dirty, but it's okay.
That's like a non regrettable investment.
So let's see if we can ship something in two weeks, really get some good ideas validated and see that based on that signal, whether we have to continue down this path or not.
And so like the techniques you could use is like think about frame it as a this is a non regrettable two week time box investment that is going to have significant ROI if we get this right or if we get the right signal early.
And it helps avoid a lot of waste if we just don't get the signal.
So that would be my recommendation.
So frame it in a way such that you time box this.
Go back to the business values here.
I heard you in there.
Exactly. Yeah, always connecting back.
I like that. So this one, I think, resonates with a lot of people out there about, you know, discovery as we would know, testing with customers.
What about like discovery for, you know, scale or other platform components?
Like what type of discovery work goes into platform products that might not be here or is the user actually going to do this?
Does the user find this valuable?
It might be something like we just need to do this to scale or how should we architect ourselves to scale.
The way we've done it is you will find yourself usually in two scenarios.
Scenario one is when you're building a platform or you're trying to evolve the platform to be newer use cases, let's say in a company like Okta, you're most likely going to have a lot of internal data on how customers are already engaging with the platform.
So you might have things like, OK, how many identities a customer has, how many applications a customer has.
And so you have a lot of that internal information to really figure out and have a good high level of confidence that here are the non -functional scan requirements that I would need.
Then there is the other side, which is I'm building platform capabilities for new products where there's a lot of unknowns over time and I don't know, right?
Like this is this might be a new area that we're going after and I don't have all of that data that I might have.
So in either of these scenarios, like if this is the first scenario, leverage the existing data, make sure you make well informed, educated decisions on scale or discovery of how do you make sure you determine your other scale limitations.
If this is a new product offering, I think you would have to just go with a specific baseline and then be like, OK, here are the first set of cohort of customers that I'm going to target.
I'm going to target a specific cohort of customers who are going to come or who are going to have a specific non -functional requirement and be comfortable saying any customers who want scale requirements or non -functional requirements that are more than what I've specified.
It's OK to evolve the platform to be like, to target those customers later.
I think it really comes down to having that conviction of if I'm building a net new platform to go and target customers, how do we make sure that I target a specific cohort of customers first, ship the platform for them.
Then evolve to meet newer customers, newer segments.
And usually, you know, that's the crawl walk around approach.
What I like about this approach to is it's very much like thin slicing it where you're looking for that business value and pulling that out.
I've seen a lot of companies not quite understand that, you know, when it comes to platforms, you don't have to build the entire platform and then ship all the stuff on top of it.
Like you could start building the infrastructure underneath little slices of value.
What do you encourage for leaders who are listening to this or product managers who are thinking, hey, I just need to go build all of these things to do to come back and then slice that value?
How should they be thinking about it?
I think it's very important for leaders to make big bets on platform to really first get by the long term vision and value of the platform.
Because if you don't have the conviction on the long term bet of the platform, I think we need to do that discovery to ensure that at least there's a two to three year hypothesis on here is where I think platforms going to take us.
And here are all of the new opportunities we're going to look.
So having that buy in initially, I think is very, very critical because if not, then the entire journey, you're going to question whether this platform even needed in the first place.
So once you get that buy in, then I think as a platform product manager, I think it's my job to really make sure that we set the team up for success.
So work with your engineering counterparts, design counterparts and make sure you ship tangible end to end customer outcomes.
And that might be, hey, break it down into your phases.
Like, hey, phase one, my platform is going to do things XYZ and it might only target 10 percent of my desired customer base.
And that's OK. And that's completely fine because you're setting expectations up front, not just with your internal stakeholders, but the external stakeholders as well.
And you set a specific roles of engagement on how do you engage with the platform?
And then over time, you evolve and meet new use cases based on feedback and based on how you get input from customers, any new unknowns that you might have uncovered yourself.
And so in terms of just getting that value, I think that's how you would look.
Pippening a little bit on this thread of innovation.
How do you innovate in platform teams with AI out there, which nobody will stop talking about?
It is a back end thing.
A lot of companies are like, oh, my God, we just need AI.
We need to innovate with AI.
We got to do all these things.
And I think some of that work does fall back on to the platform team where it's like, hey, go do this.
What's the right approach to innovation when it comes to platform components?
And what are some examples of innovation that makes sense?
There are things that you should be looking at.
I'll try to answer this internally from an actor perspective.
So one of the things that we've done is when we are building the directory platform or the framework, we think about newer platform components.
And how do we think about elevating the platform to meet our customer needs?
And when your question is around innovation and AI and stuff like that, I think the way we think about innovation from platform components is, does it answer two questions?
Question number one is, does it actually solve our immediate business case?
We talked a lot about the business value and how this drives.
The second question we always ask ourselves is, does it help us unlock potential new scenarios or new customer outcomes that we just thought were never possible before?
Because you'll be surprised from a platform component perspective.
I'm pretty confident any platform PM here at listening to this will say, I ship this platform component and wow, my customer has been using this components in ways I've never even thought about.
And so it's very important when you think about innovation in that way, where as you spend more time talking to customers and understanding the cohort of people who engage with your platform, I think it's really important to one, identify and to articulate if there are these inane outcomes, which you'd
be like, I think these are newer possibilities that sets the business up in a really powerful way.
And if you really think about it, I actually want to prioritize those ones or the ones that actually move the immediate business outcomes, because I think those are really powerful to experiment and show the business how the platform's moving the way it will go along.
How do you dedicate time in your team for that?
So with technology just rapidly evolving, all these things are popping up left and right.
How do you make sure people aren't distracted, but they still are given time to go explore?
So we break down our roadmap into buckets, right?
Like so our roadmap buckets are usually four things.
So roadmap buckets are usually a new products, solving the new platform components, basically addressing the direct business outcomes.
Then we have to keep the lights on, which is like things that tech, traditional tech tech, which are pretty important.
You think about customer origins, customer bugs that come up.
And then the fourth one is the innovation bucket, which is like your 10, 20 % of like your sprints, for example, in terms of, OK, here's a new idea, one experiment.
Here's how we would go about it.
So we usually split our roadmap into these four buckets and usually like the innovation bucket usually have like a 10, 20 % allocation.
Well, we'll be like, OK, maybe for the next two months, let's see if this innovative idea actually makes sense.
And we'll have to just have some trade offs and like how the other buckets evolve.
But that's usually how we split our roadmaps across the board.
And that innovation bucket, how are you prioritizing hypotheses?
I've seen a lot of companies make this mistake.
I think of just being like, oh, it's the innovation team.
They can go figure out whatever they want to do.
But then they end up going in 40 ,000 different directions, which sometimes is good.
But a lot of times it comes up with nothing.
Like how do you make sure they're exploring valuable things?
It really comes down to I think one of the reasons why I think teams veer off in like 20 different directions is if there is not a proper guidance on what are the expected outcomes that we want the team to deliver.
And so what something we do in our teams internally is we clearly lay some guardrails for the team in saying, hey, team, I want you to go explore innovation.
But I want tangible outcomes of these innovations that can land in like the next 12, 18 months.
I don't want like something that can land in the next 10 years because I don't know how software is going to do.
I don't know what's the next AI technology that's going to sound in the next 10 years.
And so we really try to set those guardrails and boundaries.
So like time is one.
And then the other thing is just the level of effort that goes into this.
We basically say, okay, team, I want to give you two weeks to go figure this out or three weeks to go figure this out.
And so we want to make sure we rapidly iterate and get those hypotheses.
So setting these guardrails up for the team really helps the team focus and drive in like a direction that delivers tangible outcomes as opposed to like going down like the 10 -year path.
When you're structuring that team to go after the innovation pieces, are you like mixing it up and changing different teams every time?
Is there just like a set innovation team?
How do you find the people to do that?
So one thing we do really well inside our doctor is we try to rotate PMs inside our teams.
And so I'm a firm believer that PMs need varied exposure.
So one thing we do is we try to rotate PMs also across different projects where we say, hey, okay, like maybe for the last two years we've been a very strong product PM.
And we want to put the product PM in a position where they can maybe spend 20, 25 % of their time in a platform problem.
And I would love to see how they think about in a platform environment and whether they're able to think more end -to -end.
So having this rotation of making sure PMs get these varied experiences, one keeps them very engaged and occupied and making sure they get newer experiences.
And two, it also helps me to understand the strengths and weaknesses of PMs and what they really excel in.
So I can like cuff my team better.
So that's like something that is like something I put me and my boss.
We both like to do this every year.
It's like we'll see what are like the new rotation opportunities that we have.
I love that. How long typically does somebody stay on a rotation?
I mean, it really depends on the projects because sometimes projects are as small as three months.
Sometimes projects are as big as like a year.
And if we find out like in these year -long projects or someone's really doing well, we try to make sure we encourage them and take those risks.
And then we'll find out other ways to make sure that old responsibilities are covered.
But at the end of the day, it really comes down to the experience.
We want to make sure all the PMs in our teams have the best experience and they're growing and learning as they grow.
And so that's like really the main focus is how do we ensure we can provide experiences to our PMs?
You probably have to have in order for like people to switch teams up and not feel like they're starting from scratch.
You probably have some things in line that are a little standard across teams.
What do you do to make sure that it doesn't feel like a complete overhaul every time somebody switches?
That's super important, right?
So one thing we make sure is when we do these rotations, we try to pull them in areas which are like adjacencies.
And we try to find opportunities in that space which they know because they should not be in a place where they don't know what the hell's happening because it's going to be really difficult for them to make an impact.
And so one of the things that we do is make sure if there are opportunities in the areas that they know.
And if not, one thing that I ensure that we do is make sure that we give them a good two to three weeks upfront to get them up to speed on the problem.
And I spend a lot of time personally with my PMs to make sure, hey, like because sometimes I've done this to my team.
So like, hey, I know you can solve a problem.
I think this problem is super important for you.
I know that you have no idea what this problem is.
So I'll sit with them, whiteboard them two to three weeks, give them some room to grow into the problem.
And then that's a good signal for me on whether they're actually engaged with the problem or not.
And so they usually like I really get very strong signal quickly in terms of, okay, what kind of health they need.
So I usually spend a lot of time with my PMs to get them up to speed on the problem.
I like that career development opportunity especially.
Yeah, because like, I mean, who wants to like the challenges like you discussed, right?
Which is if you're a platform team, I don't want to keep being a platform PM forever.
Great. I love it. But like also one varied experience and the same from a product perspective as well.
So mixing things up, I think, helps the PMs be more well rounded and really thinks about like, how do you grow in your career?
That's really neat.
So Vijay, we've got a couple minutes left.
I'm very curious on how you see platforms evolving in the future too.
Like, what are you looking out for as a platform PM, especially?
We had a lot of a lot going on in the security industry this last week.
We're going to hear this in the future, but a crowd strike just happened this last Friday.
And it's Tuesday, Vijay and I are talking about what are you looking at in the market out there and how are you staying on top of things?
One of the things for us when we think about platform teams and platform PMs, it's going to be really, really important that you have a curious mindset.
Because for you to be a platform PM, I think it's really important to have a curious mindset on all of the different ways someone might engage with you on the platform.
So that's really something I am looking for when I really build out like platform teams, for example.
And when I think about the evolution of platforms, speaking of an identity company, our goal internally is we are trying to build products that ensure we keep our customers safe.
We want to build the most secure identity platforms that customers can use to protect their identities.
So whenever we build a platform, security comes forefront.
That's really the first thing that comes to mind, and anything that compromises on security is just a no -go.
And so as we evolve and as we build platforms that scale, our goal is to ensure that, okay, how do we build a platform that addresses thousands and thousands of customers keeping security at the forefront?
Because the cost of these things are really massive for both the organization and our customers as well.
Well, that's some really wise words for people to listen to, and hopefully everybody will go check out Okta and Vijay.
Vijay, if people want to see more about your work, learn more about your work, can they go?
Reach out via LinkedIn.
My LinkedIn profile is up to date.
Ping me, message me.
Happy to always have a chat about platforms and how we structure platform teams internally and how we execute platform projects, so happy to chat anytime.
And we will put the links to Vijay's profile and to Okta in our show notes at productthinkingpodcast .com.
Thank you for listening to this week's Product Thinking Podcast episode.
We'll be back next week with another fabulous guest.
And in the meantime, you can submit all of your questions to me at dearmelissa .com, and I'll answer them every single Wednesday.
We'll see you next time.
