Is Automation the Future of Product Ops? | Satyavati Kharde
In Episode 16 of Talking Roadmaps, host Justin Woods speaks with Dr. Satyavati Kharde about the evolving role of automation and AI in Product Operations. Satya explores her “Clarity Stack” framework, showing how solopreneurs and teams alike can streamline workflows through automation, metrics, and data-driven insights. Together, they discuss how Product Ops can evolve from reactive support to a proactive, strategic force built on clarity and efficiency.
Dr. Satyavati Kharde is a product and innovation leader with a deep expertise in AI, automation, and data-led product strategy. She’s built systems that have saved teams hundreds of hours and helped scale products across life sciences, publishing, venture studio and tech consulting.
As a solopreneur, Satya has embedded Product Ops principles into her own workflows, proving that operational clarity isn’t just for big teams. She brings an AI-first lens to efficiency, insight flows, and decision-making. Her work transforms Product Ops from reactive support to a proactive, strategic function built for speed, scale, and signal clarity.
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
-
- To me, product operation is both. It's human and automation together. So for me, I cannot say that it's purely automation or purely human-AI collaboration. Then AI or any automation tools gives you the insight, like summarises you the stories that you've read or the user stories or the customer interviews. And then in while the machines can do that, what matters or what humans bring to the table is the context as to why it matters.
- Welcome, everybody, to the "Talking Roadmaps," channel. When series two, we're talking about product operations. And today, I'm joined by our special guest, Satya. Satya, it's lovely to have you on the channel. Please introduce yourself.
- Thank you, Justin, and thank you for invitation. So I am Satya, my full name is Dr. Satyavati Kharde So, I have a PhD in in Life Sciences. And I am also called as the clarity catalyst within my teams and across teams I work. Nowadays, I am a solopreneur, so I am doing multiple product projects or product consulting gigs. One of them is with a venture studio called Nobody Studios, and the second one is with Zuhlke. It's Zuhlke consulting firm. It's a tech consulting firm. And I am a one person team as of today. And yeah, here we go.
- If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. And also you've got a rich history of product management, of product operations. You've done a lot of things with Product Tank at Mine the Product, heading that up for communities within India. So a really relevant background, a lot of experience that we are looking forward to speaking about today. We've also spoken off camera about some of the similarities. We both run individual consulting companies. We both go and love helping larger companies with things. So, I'm really looking forward to that. And one of the things we spoke off camera was that this concept of product operations or even operations in general can be as applicable to a team or a company of one as it can be to a company of a thousand people. And so, I'm really looking forward to exploring that today because I think it will make product operations more accessible to maybe a product management function of one that thinks, "Oh well, I couldn't possibly introduce product operations here," and yet I think we can dispel that myth today. What would you say is the purpose of product operations or just even operations in general?
- That's an amazing question. The purpose for me, the basic or the fundamental process of product operations is to turn the chaos into clarity. You know, so for me, product operations or any kind of operations is that invisible engine that ensures the product is being built, the teams are aligned, and they are built in a way that is smart with lesser efforts and with higher value and impact. So for me, I also compare, or an analogous example, I think when I'm looking at or I'm thinking about product operations is that it is very similar to an air traffic controller. So as someone who flew multiple times this year from one airport to another, I always wondered how... Like it's such well coordinated system, right? Like it's so streamlined that all flights, some of them are landing, some of them are taking off, some of them are parked. How all of this is taking place, it's because there's some controllers sitting there who is looking at this entire process, streamlining it to the T, right? Like it's everything is to the point. And aligning with pilots and the other stakeholders, and then ensuring that all the decisions that are being taking place is safe. Everyone, every single person that is coming in and out of the flight in a safer place, right? Like it's grounded, and it's properly, and it's all data driven. It's in reality and not based on someone's opinion on it, so yeah.
- Yeah, it's coordinated. It lets the pilots get on with their jobs, which is flying, and landing, and taking off in the plane, right? It's allowing those other functions, it's enabling them, and it's adding that coordination on it. So, that's an interesting analogy. I've not heard that before, but it makes total sense. And so, I wonder then who product operations helps. If it's not just pilots, who do you think product operations helps in an organisation?
- I see that it helps every person that is in the organisation working towards the product because everything is tied together, isn't it? It's like there are product managers who needs to come to a faster and a well-informed decisions, so that they are smoother launches, there are timely launches, and there are less friction. Then, there's leadership team who needs to get enough visibility as to what is happening and whether things are happening without friction or whether the launch will happen or not and how is it happening in the, at the ground level. And the data engineering team, they get the correct context, the relevant context to build that product, to really release the product on time And customers for whom all of these being is built, right? Like at the end of the day, they are the one who are buying the product and they have to be kept informed. The feedback has to be taken in on time, integrated into the product and released. So, I see that the product operations is essentially for everyone who is involved in that ecosystem.
- Yeah, and actually what's interesting about bringing the analogy about the pilots and the air traffic controllers is often people worry that there are a crossover between product tops and product management or they're treading on each other's toes. Actually, when you think about the pilot and the air traffic controller, you can see such clear differentiation of duties, but very important supporting roles that you can absolutely see why those are both needed. So, that's put an interesting lens on it for me. Thank you for that. And so, I wonder what the key responsibilities of product operations are. That's probably our next logical question. If we've talked about the pilots flying and the air traffic controllers controlling and coordinating, what do you feel are the key responsibilities of product operations?
- For me, I have divided the responsibilities into five pillars. And so, first one is the data that is collected, right, the data and insights and how are these structured, like the infrastructure of it, how is the data chaos is converted into some kind of clarity in it, right? The second pillar for me is the process design or the governance of it or the cadence of it. Like how do you have processes in place that is discovering new data or processing new data, analysing it, how do you create a checklist to launch all of the governance aspect of it, right? Like of the road mapping and all of it, like it comes in the second layer for me, or the second pillar for me, the third pillar is the automation. So as someone who automates quite intensely all of her work, for tooling and automation becomes the third and the important pillar. And reducing as much as possible the human friction and the overlap, which can be into efficiencies, more into efficient workflows. The fourth pillar for me is communication. So something that we are doing now, right? Like how do you sync across different team members who are distributed, who have different roles, who have different functions, and how are, how all of them are tied together at the same time? You know, it's like a, they all have their function, but they still have to come together, exchange the notes, and then go back to what the role is meant to be. And the fifth is metrics. No matter what metrics, like it can be OKR, it can be KPIs, name it, but there has to be a metric that understands and that explains the outcome in a numerical fashion. And then, it creates kind of a backbone to all what is happening. So, you can track back. You see where the pipeline is not working so well, and see which pillars need more, better foundation and then build on top of it, basically.
- Yeah, it reminds me of a quote that I'm probably gonna do a horrible job and I don't even remember who it was from, but it was something around the lines, "If you can't improve what you can't measure," and it just resonated with me because that is exactly the way to think about it, you know? And so, I'm really pleased to see that metrics is one of your pillars. It makes me happy to see how much you lit up talking about automation in there. And I know there's so much we're gonna learn from you later on, but I think that's a really great way of looking at it data, process design, automation, communication, which is, let's face it, is absolutely vital. And then, the metrics behind it, which is great. So yeah, thank you for sharing that really considered thought with us. I wonder then if we think a little bit around the team of product operations, because I think for some companies it starts off with a borrowed role. Sometimes, someone does that function even though they're not a product operations person all the way through up to bigger teams. What teams have, what have you seen in terms of teams when it comes to product operations within these companies?
- To be honest, the teams I have worked so far have been smaller teams when compared to the teams that I listen, the numbers like 50, 100. So at the team level, it was mostly a function that was like everyone, every single person was responsible for it, right? For me lately, it's like because I'm now a one person team, it has, it's much more important as product operations. So for me, like when I say that like as a team of one, it's important that all my high impact work or every work has some kind of bottlenecks, right? It's not that if there is a work. It because it has to be done because there are some bottlenecks that are hindering for it to be done. It's like jobs to be done because there's a pain, there's a problem somewhere. And if there's work to be done, I think there's bottlenecks somewhere. So I, as a team of one for me, what product operations really mean is I need to automate things that are redundant, that are repeatable. That I think that after two times of me doing, the third time can be done by a machine. So it's I can delegate to a machine, right? The second is standardising, like really stand as a scientist, I have been standardising experiments for a longer time. So, I bring that to my own work style is how do I standardise processes things that are scalable. Let's say if I have to send 20 emails a day and tomorrow I have to send a hundred emails a day, I need to standardise the process. I need to automate that process and to templatize the process. Like emails, let's create a template, why, whom, what, like, you know, why are we doing it, whom are we sending it, what is the purpose of the email. So, you have a structure in place or a template in place. All of these three together, for me, forms a product operations being as a one person team.
- Yeah, that makes sense. It reminds me a little bit of something that I learned earlier in my career, where somebody told me about how to, how you learn about things. So see one, do one, teach one was kind of like you observe someone doing something, you then do that thing with them observing you, and then you teach one to crystallise your knowledge. And I dunno what the equivalent of that is in for you, but it might be you do one, you document one, and then you automate one, right? And it's kind of like that type of process, so that you are very quickly taking yourself out of being part of that process and instead you are observing that process and seeing it action by something else. Be that a machine, be that a person.
- Yes, so you put that right, Justin. So the job, my job I think is to make myself less necessary for that repeatable job. So, it has to be over time that this is, the repeatable tasks are less than necessary and I'm required lesser there and not more.
- Yeah, exactly. So, I'm gonna get the feeling that you look to operationalize parts of your personal life, as well as your business life. And I do too, right? I write myself these little procedures. I'm curious how you approach that. How do you operate, how do you operationalize your own workflows, whether that's in the company or for yourself? How does that look for you?
- So, I bring that my experimentation in the lab and then the product management that I did for many years, I created my own workflow, which I call it the clarity stack. So basically, this is the stack, like it includes multiple layers. Like one is a data layer is how do I collect data, structure the data that I can derive insights easily. The second layer is the automation layer. I think you cannot skip automation in this discussion of ours. I do have an integration layer, which automates most of my processes. And then, the third one is the communication or the signal layer, like which signals me that there's a data that is collected, that there is something in the pipeline that needs to be analysed, and that needs to be communicated to my stakeholders. So these three layers is something that I work with. It's hence I call it clarity stack because I have them structured in that way. I also think about, because of my experiences with uncertainty and ambiguity. So any research, any product discovery process, it's full of ambiguity, right? You just don't know what you're creating. Sometimes, you're still collecting data. You're still talking to customers, you know the problem, but you don't really know the solution. How does it look like? And, and so on. The roadmap is longer to get there. So, it's full of ambiguity. So I say that you can also time box ambiguity. Time box it like you, you know, something is ambiguous, be comfortable with it because if you knew what the product wasn't at all easy to all of us. It's just that we just don't know yet. We are learning about it, but time box every aspect of it, like, Hey, I've been learning enough from this. And then if something is fuzzy for too long because it does happen that you don't get answers quickly or it takes quite a long time, then it is for me, for that process, for that time, it's not priority because it taking long Maybe it can go into the backend, and then it runs on its own. It's kind of giving us data by the way we would auto automate it and/or it needs much sharper questions. You just have to ask the right question. One thing that I do say that like I know it can be quite controversial or people say there are no right or wrong questions. I say, no, there are right and there are wrong questions. It depends on context, where do you ask them and whom do you ask them, so yeah.
- Interesting. Yeah, that makes sense. One of the things that was coming to my mind when you were talking about time boxing, the aspects, one of the things I quite like to do when I'm setting goals or working with teams on OKRs and things is to think about the measurement. So the key result and how we're going to measure it, but then critically, what does good look like and what does bad look like? So, what's going to look like when this is going well and what's it going to look like when it's going badly. And we've also got a time box aspect of that. And it sounds like one of the things that you are doing with your data is that you are using the automation on top of that data to provide a level of interpretation, but then there's going to be some data that we expect. But what you are then looking at is not only to see that data that you expect, but to be particularly interested in when it a, is outside of those bounds, so that you can then go and do something that, you know, that something has happened or the data's signalling something to us and we need a human component on top of that.
- Absolutely. Absolutely. I think automation only tells you how to do things, but the why and what is still human beings who still have to define. And you're right with metrics is without metrics, I don't think so we can create any good product. It's very difficult for me to imagine otherwise. It's an essential. It's a bare essential in my opinion.
- Yeah, absolutely. It can be difficult to measure, the right metrics might even be difficult to measure, but it's worth going after so that we understand how we are delivering those benefits. You talk about automation a lot and we've talked about this being a really important part of the clarity stack. I'm wondering then, can product operations be a machine, or human, or maybe a combination of both? What are your thoughts on that?
- You are asking someone who is heavily biassed towards automation. To me, product operation is both, it's human and automation together. So for me, I cannot say that it's purely automation or purely human. We are in 2025, so we all are using tools that are AI supported or AI enabled. And I see that product operation is more along the lines of human AI collaboration than AI or any automation tools gives you the insight, like summarises you the stories that you've read or the user stories or the customer interviews. It helps you summarise. It surfaces anomalies or noise that you know clearly that what is signal to noise, like what is noise and what is really something. that customers are telling together. And then while the machines can do that, what matters or what humans bring to the table is the context as to why it matters. Yes, there's noise, why does it matter? Does it matter now? Does it matter later? And what is still very much a human territory is the domain aspect. is understanding and connecting all the dots together and looking at the problem from the bird's eye view, and then zooming in, zooming out. I think this is still a human territory and I think it'll remain with human for a very long time.
- Yeah, I think it needs to. I think, I very much see AI as not being necessarily something distinct. It is part of an automation that we might have been doing for decades in the past, you know. It could be just speeding up those elements, but it's an enabler. It's not necessarily something distinct in its own way. And I think that's where people often get quite frightened by it going, it's coming after our jobs. And actually I feel that actually it's just, it's enabling our jobs. It's taking some of the heavy lifting away to allow us as human beings to do more of that. As you say, that 40,000 foot view that zooming back down again or zooming in and out, that's the value of us as humans. There is sometimes there is not as much value doing manual data affinity mapping when it is much better done by a machine. It just doesn't make sense to do that.
- A hundred percent agreed. I think product operations, it was more a supportive role, but I see that it isn't evolving into a strategic one wherein a human have to really think beyond what's visible, what's being seen. So, you're right.
- Yeah. And maybe we can ask that question a bit more explicitly, which is how does automation impact product operations? From what you're saying, it should already be partly there, but how do you think automations can impact product operations?
- So, I think it shifts product operations from, again, like a very supportive back bench, like backend role to a very strategic, it becomes part of the process. It becomes a part of the decision making. I see that most product operations or like it converts from a spreadsheet person, like a spreadsheet operation focus to something that will start to ask or the product operations would be part of is why are we doing this? Kind of like there's a spreadsheet with numbers, then you go, "Why are we even doing this?" And then also, automation lets you to monitor signals like very early on. So while we are doing things, I think it's like, I'm not a football person. I do not know a lot of it, but I can, whenever I watch a game, I don't even know how these things even function. But I would say that as an audience, I know what is happening on this, on the field. The coach knows what is happening on the field, but players wouldn't know much. They're focused on the ball. They're focused on achieving the goal. What product, what automation leads to you is even the players will have that signals early on. You know, when you are in the game, you sometimes don't know, you just have that very narrow view, but the automation gives you that early signals. It helps you prioritise things early on. I would say that as you, one example I can give something that I really I'm doing these days is because you asked me about how does automation really would evolve, operations would evolve is I'm now creating some kind of a campaign for a product and to understand whether the customers or users would be even interested in. Okay, so very, very early and I don't even know whether they will be interested. This is a hypothesis that, the first hypothesis I have is A, whether users will like our feature or a proposition that we have, then how do I monitor it or how do I even look at it. So, I started an email campaign with a clear metrics, with a clear hypothesis, and why will they do it, what is the outcome of it. And I have created the campaign in a way that every day only a fewer emails are sent with templatized manner. And while this is being sent, I can monitor, I can monitor it. I can see the mail is being sent. I've automated that process. Now, I'm sitting and seeing whether the users have clicked it, whether they're doing something with it, whether my outcome, let's say is to fill a form, are they're filling the form, where is the fall off, right? It has to monitor this and not write the emails myself, not send click, send myself, right? Just taken care of. I'm looking at it. It helps me prioritise a okay, not a lot of people are opting to fill the form. I need to change my strategy now, so I can do this real time while this is taken place, while the machine is running the experiment, right? It also gives me a decision making power early on. So, I'll not wait for a week and just think, "Okay, you know, I'm still sending my email," I look at it next week. It's been taken care of. I'm taking decisions right now in an hour instead of waiting for a week.
- And that's getting the best from you and it's getting the best from the tooling, right? And so, that's where you get this compounding value of things. Something that came to mind when you were talking about using AI for that problem identification or that that that early stage discovery, helping guide your email campaigns, was that one way that people could use AI for product operations is if product operations is a new function or role within a company. Maybe that person that owns it, either part-time or full-time, could go and do a load of user interviews within the company to say what are our pain points, what are you finding are the problems. They might then get 60 or 70 pieces of feedback that they could absolutely put into AI in order to identify the patterns, the themes, what the most common thing that people are saying is in order to help that product operations person go, "Well, I think communication is the most important thing that we need to focus on." And that then becomes the beginning of the priority or their roadmap that they're going to follow. And so, I can absolutely see how AI and automation can be helpful and empowering to even somebody that is just part-time product ops. You can see how it gives them immediate time back to do the thing that's most valuable.
- A hundred percent. I really love the way you put this, Justin. It's, yes, I think for part-time people, definitely because I'm one of them and it has given me a lot more empowerment than I could have imagined otherwise, right, so yeah.
- Incredible. So, I'm excited talking with you about this and where my mind is now going is is that as an operational expert, kind of someone that really enjoys the process side of things, but obviously a deep knowledge in data and analysis and a lot of things that you've done in your career and in your doctorate. What tools or processes have you found most useful? You know, you talk about these, this email campaign and the fact that it's going in and looking at the analysis. What tools are really important to you as part of that process right now?
- Excellent question, Justin. So I was just yesterday writing, okay, what, how many tools have used over the last year and how many I've stuck with and I'm like I really like and I'm using it every day. So for data collection or for summarising data, so I use this app called Capacities App. It's kind of a hybrid between Obsidian and Notion. So if I'm learning something, if I'm reading some reviews or something, I just copy and paste it in my notes. I tag it with the right tags. And I have, I may be writing a blog, I may be writing a product review, I may be writing the next PRD, but these notes help me to construct over time like, okay, what did I learn. And then, it automates like it has a tagging and all. So, Capacities. And I also use good old Google Sheets because you can still do a lot with it. So, I've taught myself the app script, you know, like you can automate a lot of numbers. You can understand what text is where. So yes, I've done that. For visualisation and for understanding what does the data even mean, I do use Notion from time to time, but I mostly use, let's say Napkin AI. It's excellent at visualising data. So if you have tonnes of data, it helps you, give you what data would mean, but it's at still at a smaller level. But then, tableau is where you can do excellent with it. For drafting emails, templatizing, and all of course are good old ChatGPT. So, I created my own custom GPTs that helped me with particular tasks. Let's say one GPT is only for brainstorming on ideas, so I don't dilute it with my other GPS you know, so something like that. Then for automation, for my email campaigning, for tying this all together, many tools together, I really, really like make.com. So make.com is something that, let's say you want to send a notification or a email to someone and you have a list of emails, but then you can't click, and then send to each of them, right? So, you can tie them all together and time it. Say and ask me.com to like, "Hey, this is my scenario. I want to send emails to these 10 people over the next 24 hours." And it does that for you. So make.com is more like integration. You can do a lot. I saw that people also use it for posting on LinkedIn, posting on Instagram, connecting with GPTs and all, but I'm still using it for a simpler integration. For making and all I use Canva. So, I think Canva. Figma, I used it with a few of my clients. I really like Figma. But then, you know, as freelance, you can only pick for so many tools. I think these are the only tools that I use. Editable I used once, but yeah, again, you hit the paywall so soon that you stick to your whatever you are aware of as well.
- Yeah, that's fascinating. I feel like we've just had a free look inside your toolbox that you carry around of all of the things that you use. And I find that personally rewarding 'cause I'm gonna go away and have a look at these at some of these myself. You know, we've spoken in the past about Capacities and it's something that I'm looking into. I know that you had a project that you are looking to specifically use that for. The reason why it resonates with me is it's probably my former coding and development background, but I think of the world in an object oriented way. And so, the ability to have different atomic notes that are certain, that represent certain things like a reference, or a contact, or a place I find very appealing. But again, it's that classic problem of, oh, I don't need another tool or I've got two and a half thousand notes in Obsidian that I don't want to bring across to Capacities in case that's not right. But I feel like we've had a very special glimpse there into to things that have worked for you. So, thank you for sharing that 'cause I think certainly myself and the audience, if they're just looking out, we'll now be able to go and check out some of these things. I love to hear a little bit around data-driven insights. I know that you are really passionate about this. It fits in with your background. It fits in with how you work as a person. How can people incorporate data-driven insights into the work that they do?
- That's an excellent question. So, the way I see how one can incorporate that is to build the data collection system that is repeatable in the first place. So, let me have a product journey. So I will say that you're thinking about a problem. You are thinking how to test a solution and then releasing a product. Like you have so many checkpoints in all of your product journey. Each of the journey point you would interact with customer, or there's a stakeholder, or a tool, or data that is collect or some numbers or market data. All of these are data points. It has to be collected on a repeated basis, not that like, "Oh, I did my market research two years ago." No, doesn't work in such fast changing world. It has to be collected repeatably and imagine that repeated happen at multiple checkpoints. Like, you know, you're continuously collecting this data and you are built a pipeline around it, of collecting, of deriving insights. So something like if you think about an electrical thing or the electrical plugging system, there's electricity always there. You just have to plug it. And imagine you just, I have plugged it and switched it on so that you have collecting it most of the times and there in your kit. To build that system, I think that's very, very important. Integrating that data collection into some kind of method. Let's say you have NPS, people have NPS for the product. You have dashboards that makes you see what's happening there. I think that is very, very important to have some kind of a system, which has three metrics or three measuring points. So, there's a law, I'm sure you're aware of. It's called Goodhart's law. So if you're only measuring one thing, then you might be measuring, there's a higher possibility of measuring a wrong thing. So one famous example people give is imagine your goal is to hit many nails to the wall. You would not care whether the nail has hit the wall properly, whether the nail is bent, whether it'll fall off. The only goal is that you have to hit the nail. That's not the... Hence that only one metric would not work. The second metric has to be there that says, "Yeah, nail has to be inserted properly or moved properly and it should not be bent." So, I think to have that three or four metrics that talk to each other and are complimenting each other, so hence NPS and some other metrics. And to have a system that moves noise in all of this, you know, with so many things happening. It's we are bound to collect a lot of noise, but to have a system that cleans this noise early on, I think that... It depends from product to product. What is noise for someone, is a signal for other but yeah.
- For sure. Yeah, that's such a good concept that really lit up a bulb in me thinking there, because you could take it, for instance, I was a customer support manager for a company for three years. And so, I had to answer a lot of emails. Now you could look at that and say, "Well, the more emails you get through in a day, the better the job that you're doing." But the thing is, if I didn't give a satisfactory result to those customers and they were unhappy, then it doesn't matter if I did more than other people, I was making people unhappy. So, I think to bring that back to what you're saying is we would need to balance the number of support emails that I can close in a day, but tailor that with the fact that I actually solved the problem satisfactorily and the customer is happy 'cause otherwise you are measuring the wrong thing. So, I love that thought of supporting metrics because sometimes a positive movement in one metric is actually a bad thing.
- Absolutely, yeah. Spot on, spot on, Justin. Thank you for giving that example.
- Yeah, of course. It's just, you know, I wanted to solve a lot of customer problems in my time. So look, as we come to towards the end of our session together, I'm curious whether there are any product operations resources that you have used or recommended. I know that you're not a product operations within a company, but have there been resources that you've found useful in kind of bringing your knowledge of product operations together?
- So, I have read this book by Melissa Perry a long time ago, and she does run a fantastic podcast. I do hear it from time to time, I hear your podcast time to time, because I think that gives many views many perspectives from many different companies. So, I think that that gives an overall view as what's happening in what type of company, what type of industry, and so on. And I do read a lot of papers. So again, I have a system that it gives me an alert that there's a new thing that's happening in product ops or there are new tools that are being introduced, and I do look at it from time to time. And honestly like, it might be a shameless plug, but also work with me. So yeah, I think I really love watching companies how they take decisions. I read their press releases, some of theirs, not all of them, but some of them, which I really like. I do read them, I did try and understand how did they come to this conclusion, why did they come to this conclusion, what were the metrics, what was the method. And this is how I've created the series. I do not know, Justin, if you've seen it, it's called Clearer in Hindsight.
- So, I saw it mentioned on your LinkedIn, but I haven't delved any further than that. Tell me about that.
- So, the Clearer in Hindsight is all these studies that I do, so I read about a company about how do they come, how did they come to a decision. So for example, I did one on Intercom as to how did they evolve over time, because many of these companies see including Notion, right, they started at some other goal and slowly evolve into what they have been. So we only see the finished product, we don't see what's happening behind the scene, what failures, what decisions made them to come here. So, I dive into one case study. I don't dive into all of them. I dive into one. For example, I was intrigued by Notion AI. So, I try and understand how did they even come to this? Like, you know, it's curiosity driven basically. So, I create those small carousels just for also help myself put that thoughts in clearer.
- I love that. Yeah, that makes sense. Well, we'll be sure to check that and in fact today, but I'm curious if you had to, and this is a tough question, but I'm gonna preempt you because you actually shared a five word framework with me earlier around data process design. So you can use that to answer this question if you like. But what we always ask our guests is if you had to distil your philosophy of product operations into one or two sentences or five words, how would you describe it?
- So for me, again, I come back to the clearer thing, right? Like for me, the product ops is the architect or the quiet architect of clarity. I think it's something that is operating in your favour. It's clearing the chaos for me. Yeah, if I have to put in five words, product operations is the quiet architect of clarity.
- Wow. Not, I mean, that's a mic drop moment there. And actually it's, again, this is why I love the podcast episodes that we do. I learned something new from everybody, and that's a totally different angle that I hadn't thought of. So, thank you for sharing that with us. Satya, as we wrap up, I wonder if there is anything about product operations or maybe just a question that I should have asked you, but haven't yet. Is there anything that we should have talked about?
- I was thinking that because I said so much about automation, like being like, so like structured. You had asked me how did I become this process police.
- And maybe yeah, tell us a little bit about it. I mean, I wouldn't say it was the police, but it's a passion, right? And this is about enabling humans to do what they're best at by automating the stuff that we don't need to be doing. So, I mean, I can see it in your career and in your education, but tell us a little bit about how this became such a passion for you.
- So I was in this, I was a person of pure chaotic, like I just did everything. I wanted to do everything. But what helped me was I saw that structure was bringing me more freedom. So, I really liked that. So for me, operations and all isn't about processes. It's more about creating that freedom of creativity, right? And it's about understanding where friction, where it matters and where it does not matter, and then clearing it out step by step. So, that's why I'm more like an experimentation, hypothesis, and structured person. So yeah, I hope I answered.
- Yeah, you did. It's fascinating to see how we've come to where we are by looking back. It becomes almost clearer in hindsight, does it not? So Satya, where can people find more information about you? If they've been as enlightened by today's episode as I have, where can they find you? How can they get in contact?
- I have, I'm on LinkedIn. I'm trying to be active on LinkedIn by posting my thoughts on a regular basis. I'm thinking of starting at Twitter, but I haven't yet. So I had a page, but I think it's deactivated. I haven't logged in into it, but my primary point of contact is LinkedIn. You can connect me on LinkedIn. I'm quite active. I'm becoming quite active on LinkedIn, yes.
- Perfect, yeah, and it sounds like you're working on some things, say some new social media avenues, the work that you're doing with Clear in hindsight, I think LinkedIn is a great place for people to find you. So yeah, if anyone's listening in the audience and you are really interested in learning more, go and check out Satya's social media sites. I know I'm gonna be doing that and hopefully we get to stay in contact after this just to learn about some of the tools. I'm sticking with Obsidian for the moment, but I'm very interested in Capacities and I'm looking at what they're doing so. Satya, all it leaves me to say is thank you so much for spending time with us today. I've loved your perspectives and I think our audience will get a lot from today as well.
- Thank you so much for inviting me and asking me such wonderful questions. Happy to contribute.
