Episode 189: Prioritizing Platform Products with Vijay Pitchumani of Okta
I recently had the opportunity to sit down with Vijay Pitchumani, Director of Product at Okta, for an engaging discussion on the Product Thinking podcast. Vijay, with his extensive expertise in product strategy, shared invaluable insights into the world of platform product management and the unique challenges faced by platform teams.
In our conversation, Vijay and I delved into the essential role of product managers in platform environments, exploring how they can define success metrics, experiment with API-first approaches, and balance short-term experiments with long-term strategic goals. Vijay's perspective on the importance of innovation within platform teams, and his strategies for managing PM rotations to foster diverse experiences, provided a comprehensive look at navigating the complexities of scaling and evolving platform products.
We also touched on how product managers can effectively secure buy-in for experiments and new ideas, making a strong case for experimentation within platform teams. Vijay’s insights were not only enlightening, but also highly relevant for anyone involved in managing and scaling platform products in today’s technology-driven landscape.
You’ll hear us talk about:
17:37 - Crafting a Platform Vision
Developing a vision for a platform is distinct from crafting a vision for user-facing products. Vijay emphasizes the need for platform PMs to think long-term and anticipate future use cases and non-functional requirements. Unlike user-facing products where MVPs can evolve incrementally, platform decisions must account for scalability and future capabilities from the outset. This involves providing engineering teams with a clear understanding of market trends and future needs to guide technology choices and ensure the platform can evolve to meet new demands.
26:21 - Balancing Short-Term Experiments and Long-Term Goals
When it comes to justifying experiments to platform teams, Vijay advises framing them as short-term, time-boxed experiments that demonstrate potential value with minimal investment. He suggests that PMs propose experiments with clear, short-term goals (e.g., two weeks of effort) to test hypotheses and validate ideas. This approach helps in avoiding waste and ensures that the experiments are manageable and deliver actionable insights quickly. By setting clear expectations and timelines, PMs can secure buy-in from stakeholders and ensure that experiments align with broader business objectives, reducing the risk of wasted effort and resources.
39:39 - The Evolving Role of AI in Enhancing Productivity
Vijay discusses the rotation of PMs across different teams and projects as a strategy for both career development and ensuring diverse experiences. By rotating PMs, organizations can keep them engaged and provide them with varied experiences, which helps in identifying their strengths and weaknesses. This practice also ensures that PMs bring fresh perspectives to different problems and projects. To support this, he advises setting clear expectations and providing sufficient onboarding time to help PMs acclimate to new challenges. This approach not only enhances PMs’ skills but also benefits the organization by leveraging diverse insights and experiences.
Episode Resources:
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | Twitter | LinkedIn
Intro - 00:00:01: Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perri.
Melissa - 00:00:37: Hello, and welcome to another episode of the Product Thinking Podcast. Joining us today is Vijay Pichumani, Director of Product Lifecycle Management and Governance at Okta. Vijay has been instrumental in building and optimizing identity governance and lifecycle management products. His impressive career includes leading integrations with Microsoft and Azure, driving predictive analytics at SparkCognition, and winning the VMware Hackathon. Today, we're gonna 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 our 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 leadership is doing. Are you creating a 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 I would 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 come 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? 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.
Vijay - 00:06:10: Hey, Melissa, thanks so much. Pleasure to be here.
Melissa - 00:06:12: 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?
Vijay - 00:06:19: 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. 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 directory. So directories are a fundamental portion of any identity and access management platform. So I own the core platform. And then I also own left cycle management and governance, which are two other new product offerings that we've had.
Melissa - 00:07:02: 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?
Vijay - 00:07:10: 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 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 lifecycle 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.
Melissa - 00:08:01: What are the challenges of building out products that don't have user interfaces?
Vijay - 00:08:07: 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 I 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 or 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 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 data.
Melissa - 00:09:05: What are the types of customers that you are serving for and different types of personas you're looking at?
Vijay - 00:09:09: So think about 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.
Melissa - 00:09:55: 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.
Vijay - 00:10:03: Exactly. Because the needs of these different types of developers are also evolving. From a customer perspective, the specific job to be done is different compared to an internal developer or internal employee compared to 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.
Melissa - 00:10:28: When you're looking at that too, roadmap is always like a hot topic when it comes to platforms. How do you approach roadmapping 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?
Vijay - 00:10:43: 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 roadmapping 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 the fears of the platforms evolving so that they can go ensure that expectations are met correctly.
Melissa - 00:11:46: When you're communicating those trade-offs, I found a lot of people struggle when it comes to highly technical products or platform backend 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 the business value here. How do you explain that?
Vijay - 00:12:12: One of the things that we want to do is reduce the amount of infrastructure that we want to consume in terms of just sinking 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 that? Why would your CPO care? Why would 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 or the ways we justified it was saying, hey, we went and found our 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 retention. And more customer satisfaction. So if you think about it, it doesn't always have to tie to new revenue and getting new customers. It can also tie to how do we improve existing customers, improving CSAT, improving the overall experience of using the product, which I think is really important.
Melissa - 00:13:28: Can you tell us about a time maybe 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.
Vijay - 00:13:42: 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 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 product investments and things like that? And so this is where I think PMs can add real value because 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 just how we were able to get ahead of the curve in proving value to 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 we had. And that's how you justify value over time.
Melissa - 00:15:07: I was involved in a big replatforming one set of a company as well. And we originally didn't have product managers associated with it. So the strategy was 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 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.
Vijay - 00:15:43: Totally. Yeah, because it really comes down 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 our external stakeholders as well, because 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 salespeople, 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.
Melissa - 00:16:24: 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.
Vijay - 00:16:48: 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 we over-index on building new product capabilities. Sometimes it might be like, hey, the business is really trying to ensure we incentivize 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 in the platform and track metrics. So I think... 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 misaligned with the business outcome, then I think that's a recipe for trouble.
Melissa - 00:17:59: 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 planning meetings or cadences that you follow there?
Vijay - 00:18:08: 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 the OKR framework that's used by Google. So internally, we have the vision, methods, and targets, and those are set at like the business level. And then eventually, we can then trickle down into the planning process where, you know, there's like 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.
Melissa - 00:19:07: What are you looking for too, 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?
Vijay - 00:19:18: So I lead a team of awesome PMs who lead 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 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 sell 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.
Melissa - 00:20:23: 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 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?
Vijay - 00:20:38: Think incentives. So one of the things I always tell my PMs is think shared incentives. Because 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 to them how you're going to make the other team successful. And that is how you really drive alignment. Because 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 a shared incentive model, plan properly where you can articulate to them, okay, here's 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 into it.
Melissa - 00:21:42: Platform too, it's interesting because we think of a lot of like user-facing products having a vision, right? That's clearly 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?
Vijay - 00:22:07: 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 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 X, Y, Z, and then I'm going to track adoption of the products. But 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 NetTube 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 the 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. Because from a product PM perspective, you'll 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. There's no changing API contracts after you go out the 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 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 non-functional requirements. Think about scale. Think about 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 kinds of questions so they can go make the right decisions.
Melissa - 00:24:14: So what types of things should a PM be helping their engineers understand when it comes to these long-term visions?
Vijay - 00:24:21: 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 they build the platform in the right way that are not going to lock you in from expanding to those use cases. Because it's really important that you expand over time and address your use cases as you go.
Melissa - 00:25:20: 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? How is that different than somebody who's working with user interfaces?
Vijay - 00:25:41: 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, 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. And 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. 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, it 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 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 you're building the platform 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 PMs could add.
Melissa - 00:27:22: 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 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 backend with the platform because you have to think about scale and where it's going to go in the future. Is there a room for experimentation on platform teams? And if so, what does that look like? What can you experiment with? What can't you?
Vijay - 00:28:17: Oh yeah, there's plenty of room to experiment. In fact, I think shipping platform capabilities is actually a very cheaper way for organizations to get quick signal from, right? Because let's take, for example, I'll talk about from my personal experience, right? 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 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 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, it really depends on how you're going to measure success over time. Because if you say, okay, I'm going down a certain path and this is the goal for me in the next three, six months, you have to get that customer signal as you evolve over time.
Melissa - 00:29:24: 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.
Vijay - 00:29:31: 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. If I wear the hat 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 other 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.
Melissa - 00:30:31: 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 and see if we can build some APIs 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?
Vijay - 00:30:51: 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 like a time-boxed experiment. So think of these as small product experiments that you do. So that's something I encourage my PMs 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 the techniques you could use is like, think about, frame it as a, this is a non-regrettable two-week time-boxed 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.
Melissa - 00:31:56: Go back to the business value too. I heard you there.
Vijay - 00:31:58: Exactly. Yeah.
Melissa - 00:32:00: 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 discovery for, you know, scale or other platform components, like what type of discovery work goes into platform products that might not be, hey, is a 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?
Vijay - 00:32:27: 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 at 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, okay, 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 scale requirements that I would need. Then there is the other side, which is I'm building platform capabilities for net new products where there's a lot of unknowns over time. And I don't know, right, like this might be a new area that we're going after. And I don't have all of the 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 like scale or discovery of like, how do you make sure you determine here are the scale limitations. If this is a net new product offering, I think you would have to just go with a specific baseline and then be like, okay, 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 okay 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. I'd suggest.
Melissa - 00:34:18: What I like about this approach too 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 when it comes to platforms, you don't have to build the entire platform and then ship all the stuff on top of it. You can 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 thin slice that value? How should they be thinking about it?
Vijay - 00:34:47: I think it's very important for leaders to make big bets on platform to really first get buy-in on 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 the platform is going to take us and here are all of the new opportunities we're going to unlock. 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 is 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, work with design counterparts, and make sure you ship tangible end-to-end customer outcomes. And that might be, hey, break it down into phases. Be like, hey, phase one, my platform going to do things X, Y, Z. And it might only target 10% of my desired customer base. And that's okay. And that's completely fine because you're setting expectations up front, not just with your internal stakeholders, but their external stakeholders as well. And you set the specific rules of engagement on how do you engage with the platform. And then over time, you evolve and meet newer use cases based on feedback and based on how you get inputs 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.
Melissa - 00:36:16: Pivoting 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 backend 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 onto 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 that are things that you should be looking at?
Vijay - 00:36:46: 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 a 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 listening to this will say, I shipped this platform component and wow, my customer has been using these 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 core cohort of people who engage with your platform, I think it's really important to one, identify and to articulate if there are like these inane outcomes, which you'd be like, I think these are newer possibilities that sets the business up in like a really powerful way. And like, if you really think about it, I actually want to prioritize those ones over 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 needle overall.
Melissa - 00:38:32: 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?
Vijay - 00:38:43: So we break down our roadmap into buckets, right? So our roadmap buckets are usually four things. So roadmap buckets are usually new products, solving the new platform components, basically addressing the direct business outcomes. Then we have the keep the lights on, which is like things that tech tech, traditional tech tech, which are pretty important. You think about customer urgence, 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, okay, here's a new idea I want to 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, you usually have like a 10, 20% allocation where we'll be like, okay, 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 in how the other buckets evolve. But that's usually how we split our roadmaps, because that was the board.
Melissa - 00:39:41: In 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. How do you make sure they're exploring valuable things?
Vijay - 00:40:01: 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, was 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 innovations, but I want tangible outcomes of these innovations that can land in like the next 12, 18 months. I don't want 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 come 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, we're going 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 a direction that delivers tangible outcomes as opposed to going down like the 10-year path.
Melissa - 00:41:12: And you're structuring that team too, 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?
Vijay - 00:41:23: So one thing we do really well inside of Okta is we try to rotate PMs inside our teams. And so I'm a firm believer that teams need varied exposure. So one thing we do is we try to rotate PMs also across different projects where we say, hey, okay, 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're really excellent. So I can like half my team better. So that's like something that is like something I, both me and my boss, we both do like to do this every year. It's like, we'll see, what are like the new rotation opportunities that we have?
Melissa - 00:42:25: I love that. How long typically does somebody stay on a rotation?
Vijay - 00:42:29: I mean, it really depends on the projects because sometimes projects are as small as three months. Sometimes projects are as big as a year. And if we find out like in these year-long projects that 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 their 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 get the right experiences to our PMs?
Melissa - 00:43:02: You probably have to have, in order for 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?
Vijay - 00:43:17: 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 is 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 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 up front 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 teams. I'm 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 help they need. So I usually spend a lot of time with my PMs to get them up to speed on the problem.
Melissa - 00:44:31: I like that career development opportunity, especially.
Vijay - 00:44:34: Yeah, because like, I mean, who wants to, like the challenges like you discussed, right? Which is if you're a platform PM, 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 how do you grow in your career?
Melissa - 00:44:56: 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 going on in the security industry this last week. We're going to hear this in the future, but CrowdStrike 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?
Vijay - 00:45:25: 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'm looking for when I really build out platform teams, for example. And when I think about the evolution of platforms, so, 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. And 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, really 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.
Melissa - 00:46:41: 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 you, where can they go?
Vijay - 00:46:51: 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.
Melissa - 00:47:06: 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.