How to Build Successful Products with Radical Product Thinking | Radhika Dutt | Glasp Talk #24

How to Build Successful Products with Radical Product Thinking | Radhika Dutt | Glasp Talk #24

This is the twenty-fourth session of Glasp Talk!
Glasp Talk delves deep into intimate interviews with luminaries from various fields, unraveling their genuine emotions, experiences, and the stories behind them.

Today's guest is Radhika Dutt, an entrepreneur, product strategist, and the author of Radical Product Thinking: The New Mindset for Innovating Smarter. Radhika's book has resonated globally, translated into multiple languages, and is built on her extensive experience in product development. She has been involved in five successful acquisitions, including two companies she founded, and now advises organizations ranging from high-tech startups to government agencies on how to build products that drive fundamental change.

In this interview, Radhika discusses the concept of Radical Product Thinking, a framework born from her own experiences and mistakes in product building. She talks about the common "product diseases" that derail teams and shares her insights into the importance of a clear, actionable vision in product development. Radhika also explains how companies can balance long-term vision with short-term business needs and offers valuable advice for product managers on how to evolve their strategies. Join us as we explore Radhika Dutt's journey, her innovative framework, and her vision for the future of product development.


Read the summary

How to Build Successful Products with Radical Product Thinking | Radhika Dutt | Glasp Talk #24 | Video Summary and Q&A | Glasp
- Radhika Dutt presents her book “Radical Product Thinking,” which outlines a framework designed to help product managers avoid common pitfalls and build successful products by focusing on a clear vision and strategy. - The concept of “Radical Product Thinking” emerged from Radhika’s personal experi


Transcripts

Glasp: Welcome back to another episode of Glasp Talk. Today we are excited to welcome Radhika Dutt, author of Radical Product Thinking: A New Mindset for Innovating Smarter, and her book has resonated globally, being translated into several languages including Chinese and Japanese. Radhika is a serial entrepreneur and product strategist who has been involved in five successful acquisitions, including two companies she founded, and she advises organizations ranging from high-tech startups to government agencies, helping them build products that drive fundamental change. With a rich background spanning industries from media, telecom, robotics, and consumer apps, Radhika’s insights are invaluable. So please join me in welcoming Radhika. Thank you for joining, Radhika, today.

Radhika: Thank you so much for having me. I’m excited to be here and to talk with you.

Glasp: Thank you. So first of all, we are a huge fan of your book, Radical Product Thinking, and I think, the book helped many founders, and product managers a lot and we are one of them. But in your words we—I want to know what is radical product thinking because some of our audience may not be familiar with the concept yet.

Radhika: Yeah, thank you. And by the way, it’s always so rewarding to hear that the book resonated with people and it’s been helping people make change. So, I’ll share the background and why radical product thinking even came about. Really, to summarize it all in just a few words, it’s a book based on a lot of the mistakes that I’ve made as I was learning to build products, when I was an entrepreneur, or when I was building products—just all the hard lessons that I’ve learned are basically summarized and packed into this book to help people build products better. So just to elaborate on that: my first startup was something that I had founded with four other co-founders, and we were still in our dorm rooms at MIT when we founded that startup. It was called Lobby 7. And when I think back to that startup, our vision at the time was revolutionizing wireless. If you ask me what it means to revolutionize wireless, honestly, we had no idea. We just wanted to be big, right? That was when we encountered the first product disease that I now call hero syndrome, where you’re focused on being big without really knowing what problem you’re trying to solve in the first place, right?

Glasp: Right.

Radhika: And after that startup, we ended up building other startups. Maybe I didn’t encounter the same product disease, but it was other product diseases that I ran into like pivotitis or obsessive sales disorder. I talk about these in the book. And every time I learned to build better products and learned to avoid these diseases, at a certain point in my career, I realized that I had learned from these hard lessons, but now I had to watch others make the same mistakes that I’d been making. And so, that’s what led to this burning question—the question of, are we all doomed to just learning from trial and error and learning these hard lessons to figure out how to build good products, or can we offer people a very systematic step-by-step process for building successful products? I was sharing this burning question with a couple of ex-colleagues of mine, talking about these product diseases, and they had faced some of these same experiences. And so, that’s when radical product thinking was born, because we came up with a framework to really help people translate a vision into strategy, priorities, execution, and measurement. We put out this framework for free, and people started using it organically. And that was just wonderful to see—that people were just organically finding it and using it. And that’s when eventually the Radical Product Thinking book came out because people were asking, “Well, you know, we’re using this framework. How do I know if I’m using it correctly?” And so, the book was born as a voice-over basically to help people use this more effectively in building successful products.

Glasp: I see. And was it like, you had the idea of writing a book, but writing a book takes time, right? How long did it take for you to write? You published it back in 2017 or 2016-ish, right?

Radhika: Well, the framework—we put it out there in 2017, but that was only the raw framework in PDF format, right? The book came out in 2021. I started writing it in 2018, and it took me three years basically. And so what you said about writing a book—I think yes, it takes an obsession to write a book, but I’m really thrilled at how it came out. I feel like it offers—it’s the kind of book that I wanted to write. You know, very often you read a book, and you go, like, “Wow, well this could have just been a blog post, and it’s been stretched into 10 chapters.” Instead, I feel like the Radical Product Thinking book, every chapter could have been a book by itself. And it really condenses a lot of deep thinking into one book, and so I’m grateful for all of the experiences that led to writing a book like that.

Glasp: Yeah, that’s amazing! So, is there any reason you named it Radical Product Thinking, the title?

Radhika: Oh, I’ll tell you two stories why. So one is that there’s a lot in the Radical Product Thinking book that challenges conventional wisdom, and I’ll give you just one small taste of it for our listeners. You know, in a radical product thinking way, there are five elements of radical product thinking that help you translate a concept into reality. The five elements are vision, strategy, prioritization, execution, measurement, and culture. But when I say these words, like vision, strategy, you go, like, “Oh yeah, you know, we’ve visioned before, and everyone needs a good vision.” Except this is the part that’s radical about it. In the radical product thinking way, a vision isn’t, big and broad like, you know, it’s not one of these fluffy statements like, “To be the leader in...” or, you know, nothing like “revolutionizing wireless.” It has to be truly a deep and meaningful vision that answers: whose world are you trying to change? What is their problem? Why does the world need changing—because maybe it doesn’t. Then you can answer: What is the world like when? When can you say you’ve arrived? And finally, how are you bringing it about through your product?

So, I’ll give you an example of such a vision statement. Here’s a vision for the startup that I founded in 2011 and sold in 2014. Today, when amateur wine drinkers want to find wines that they’re likely to like and learn about wine along the way, they have to find attractive-looking wine bottles or wines that are on sale. This is unacceptable because it leads to so many disappointments, and it’s hard to learn about wine in this way. We envision a world where finding wines you like is as easy as finding movies you like on Netflix. We’re bringing about this world through a recommendations algorithm that matches wines to your personal taste and an operational setup that delivers these wines to your door. Now, this is a radical vision because I hadn’t told you anything at all about the startup that I had, and yet when I shared this vision with you, you knew exactly, hopefully, what we were doing and exactly why we were doing it, right? And so, this is why it’s called radical product thinking because it challenges a lot of conventional wisdom. And instead of having such fluffy ideas about vision and strategy, it makes it very tangible. So, that’s the first reason.

The second reason, I will say, is that “Radical” was my nickname in high school, and I thought I should just embrace it. So, there we go.

Glasp: Yeah, that’s what I thought! It’s so easy to remember—Radhika wrote Radical Product Thinking! Interesting. So, you are strongly emphasizing the importance of vision, right, in radical products. I have some questions about vision. People set up visions at a certain moment, but in the future, say 10 years or 20 years, the vision might be outdated. How can companies stay current with a vision that’s not outdated? How can companies repeatedly update it?

Radhika: Yeah, I think one of the things that we’ve learned about a good vision—and this is conventional wisdom—is that your vision has to be everlasting, which is why we come up with vision statements like “to be the leader in blah blah,” because we think that way, we never have to change our vision. But I think, exactly as you were saying, markets change, your customers change, times change, and your vision has to evolve with it, right? So, we need to rethink this idea that your vision has to be everlasting—it really should not be constant. So in the radical product thinking way, you should actually revisit your vision every year, at the very least, to see if this is still accurate. And, you know, actually, if you’re an early-stage startup or if your product is not mature, you should be revisiting it much more often than every year. For an early-stage startup, I’d say even every month or at least every quarter, you should be looking at your vision and saying, “Is this still valid?”

And so, how do you go about doing that? One of the ways is to, first of all, start thinking about your vision as a hypothesis. It’s not something that is unquestionable. This is your best guess at this current moment in time. So, you write out this fill-in-the-blank statement. By the way, one of the reasons the radical product thinking version of a vision statement is a fill-in-the-blank statement is so that you don’t fall in love with your own words. It’s okay to change them, let’s say, a few months down the line, right? So you fill it in, and then as you execute, you might discover that, oh, it actually turns out that maybe the “who” I was targeting was wrong—that those are not the people who need this whole solution; it’s actually these other people. Or you might discover that the problem that they have right now is slightly different from what you actually thought originally. And so, whatever this new learning is, you rewrite your vision statement based on that. This way, you can share it with your team, and say, “This is what we thought was the right answer. This is now what we see as the correct answer, and so based on that, here is what we’re going to do differently.”

Basically, it means that the updated vision allows you to pivot without catching the product disease I call pivotitis. And so, this is how, as a company or as a product team, you can continue to evolve your vision, and it helps you bring your whole team with you on the journey.

Glasp: I see. And in that sense, do you recommend founders or PMs to have two visions? Like, as you mentioned, a three-month or six-month short-term vision, but also sometimes having a long-term vision helps the company or team align with what they do. How should the team balance between the two? If we only have a short-term vision that changes a lot, employees might feel, “Oh, what’s happening in the company?”

Radhika: Yeah, great question, right? I think what you ask is so fundamental to the dilemma that we have about how short-term or long-term should your vision be. I think the first thing I’ll say is, you know, if you think about the song that Freddie Mercury sang, it says, “One Vision.” He sang “One Vision” for a reason—that it has to be one vision to rule them all, as opposed to having lots of different visions, right? Because having multiple visions creates more confusion. So, that’s the first thing.

The second thing is, you know when you write a vision, I think it should be a vision that usually carries you through probably for one to two years. Don’t feel like you have to write a vision that is valid for five years, because the reality is, you don’t really have a five-year vision—the vision for five years can get very fuzzy, right? And the fuzzier your vision, the harder it is to make it actionable. And so, this is why I think in the one-to-two-year horizon and know that as a team, you’re going to be revisiting your vision anyway. Like, every time you do strategic planning, you should be looking at your vision and saying, “Is this still valid?” This is how you keep evolving your vision.

And this question you asked: Don’t you need a long-term vision to keep everyone aligned? Let me reframe this question a little bit. The broader your vision and the more high-level, the better it is for giving you the five-year timeline. But at the same time, that makes it a lot less actionable. So, when you look at that tradeoff, what I’ve always found is that having a clearer vision is what helps your team actually translate that into reality. If I think about building a house, right, I could draw you really beautiful renderings of a house, but that rendering isn’t going to help you actually build that house. If I give you a construction floor plan for what I want this house to be, it may not look pretty, but it’s actually what you need to build that house. So, I would err on the side of having more detail to be able to create that alignment.

And so, how do you make sure your team doesn’t feel like, “Oh, you’re changing your vision all the time?” You know, the interesting thing that’s actually counterintuitive is that it’s pivotitis or diseases like pivotitis that make your team feel like you’re constantly changing your mind, and they have no idea what the vision is, right? And so, when you catch product diseases like pivotitis or obsessive sales disorder—pivotitis is the disease where you keep on pivoting from one idea to the next. Obsessive sales disorder is when anything that any customer wants, they ask for a custom feature, and you’re like, “Yes, okay, we’re going to do it,” you know? And this is how it feels to your team that you’re saying yes to everything. They don’t understand what the vision is here.

On the contrary, when you have details in your vision statement, and if you end up saying, even six months or a year down the line, “We need to change our vision,” you’re really helping your team understand what it is that has changed. You’re conveying the rationale for why that vision needs changing, what you’ve learned, and therefore what your next experiment is. So, you’re really bringing people with you on the journey, and it creates less instability for your whole team. So, I’d always go with a more detailed version.

Glasp: I see. And at the same time, this happened to me at the first company I started. Sometimes as a founder, I was confused about the difference between mission and vision. Do you have some thoughts on a mission and how the company or team should align with the mission?

Radhika: Yeah, great question. I think the whole concept of vision, mission, and values—it’s truly outdated. We need to rethink things. What I said about “one vision to rule them all,” like “one ring to rule them all,” you know, Freddie Mercury—all of those ideas, they all point to one direction. It’s having one thing to create alignment as opposed to multiple things. What I found is that vision, mission, and values—they’re trying to create more details in this cascading order, right? There’s a better way to do it, and this is what I often do with organizations. At a leadership level, you write out your vision in the same radical product-thinking format to the best of your ability.

If as a company, let’s say you’re Amazon, that vision I described—the one that answers the who, what, why, when, and how—that becomes very broad because Amazon targets consumers, but then AWS, for example, targets businesses. So if you had to write this vision statement, it would be, “We do everything for everyone,” which isn’t really useful. So I would write a vision statement for a portfolio of products. Maybe, for example, you’d write a vision statement for AWS, and then within AWS, you have different product managers who are managing different aspects of AWS, right? And each product manager would write a vision statement for their product, and their vision aligns with AWS’s vision. So in this way, you start to cascade your vision statements.

One last thing I’ll say is that we focus a lot on memorizing vision statements. That’s part of why this aspect of changing vision statements is scary for employees because it’s like, “Oh, does this mean I have to memorize a new vision?” But really, it’s not about memorizing at all. For instance, when I was sharing the vision statement for that wine startup, every time I rethink that vision statement, I might use slightly different words. It’s not the words that are important. What’s important is truly the answers to the who, what, why, when, and how, and how you fill in those blanks. When you answer those profound questions, you create so much alignment across the team. You don’t want anyone to memorize the statement. You want them to describe it in their own words in a way that makes you realize they’ve internalized it. That’s how you know your vision is really spreading.

Glasp: Yeah, thanks! That’s so interesting. At some companies or some startups, even if employees product managers, and founders decide on the mission and vision, it’s so difficult to apply it in daily actionable things—daily actions, right? How do you advise founders and product managers to apply what they decided as a mission to daily behaviors?

Radhika: Yeah, and I think there are two elements to what you said because what you brought up, I mean, it’s so interesting, I think. So, one thing we have to think about when a company has a vision, mission, value structure, right? Very often, if you’re a product manager who is way down in the hierarchy, you know, you might not be able to go there and say, "Okay, you know, I don’t think we should deal with vision, mission; it’s outdated. You know, we should use this new approach." Like, you may just not have the power to be able to say that. And even if you have that power, it might just be that you’re being this bull in a china shop where nobody appreciates this direct challenge to the vision, mission, etc.

And so, the way I’ve often approached this is very tactfully and gently, where you don’t directly challenge the vision. So instead of that, I use the vision in my prioritization. So let’s say I’m the product manager, and I’m coming to you with some ideas on how I want to prioritize things in my product. Rather than challenging your vision as my boss, I’d come to you showing an X and Y axis, and there I would talk about prioritization. So the Y-axis that I draw up is the vision statement that I wrote up for the product, right? And so, I don’t even necessarily have to tell you as my boss what this vision is that I wrote up, right, because I’m not trying to directly challenge your vision.

So I write this vision statement for the product, and I draw up a Y-axis, and I call this "Is this a good vision fit or not?" And the X-axis is, "Is this good for survival or not?" Right? So basically, what I just drew up is the yin and yang of long-term, which is vision, and the short-term, which is survival. And so, now I’m making this yin and yang very explicit and visual. And things that are good for both vision and survival, those are the easy decisions, right? Those are the decisions that generally people are not going to protest. They’ll be like, "Yeah, let’s do them." Then there are decisions that are good for the vision, and they’re not that great for survival. So an example of this would be if there’s technical debt we have to fix, or I need to spend some time refactoring code, or if I need to do some user research. That’s investing in the vision because it’s good for vision, but it’s not, let’s say, bringing in short-term revenues.

And the opposite of that is when I’m creating vision debt. This is good for survival, so maybe this is like a custom feature that is going to bring in sales, so it’s good for survival, but it’s terrible for the long-term vision, so it’s vision debt. And so now, when I talk to you as my boss, and I’m telling you about all these different features that I’m thinking about, I will categorize things as investing in the vision versus vision debt versus what is ideal, right, or easy decisions. And as I’m talking you through all of these things, it makes prioritization decisions less contentious because it begs the question: "Hmm, are we aligned on the vision?" And that’s when, you know, you would say, "Well, I think this is a good vision fit," and it gives me an opportunity to say, "Well, you know, here’s how I think about the product vision." I don’t even call it the company vision, right? I talk about it as the product vision, and here’s how I’m thinking about it—like, do you agree on this as the vision? And that opens up this dialogue. Like, I’m not directly challenging anything but sharing some thoughts that I’ve been working on.

Or maybe we’re not aligned on what is survival, and you might discover that maybe survival isn’t about financial survival. Maybe it’s stakeholder support, where, you know, if our CEO is going to disapprove of this, maybe that is what survival is about, right? So it helps you create this alignment by using your vision for prioritization purposes, and it allows you to sort of sneak in the concept of challenging the vision without directly doing so.

Glasp: I like that—like, the X-Y axis and metric, interesting. So, vision debt or I understand it. But as a product manager or at some point, we need to have iteration. I mean we understand that vision is so important and long-term vision is important, but at some point in the short term, we need to do something that is beneficial for our business, right? So how do you balance it? So every time we cannot work on long-term vision things, but vice versa, we cannot work on only short-term things. Like any framework?

Radhika: Yeah, that’s a great question, right? And I think this is what product managers typically struggle with. Like, and in a sense, when you think about that X-Y axis of vision versus survival, I think your question boils down to, "What’s the right balance between investing in the vision, vision debt, and, like, the easy quadrant, right?" And the answer to that is—I think that truly depends on your particular company and the situation that you’re in. Not even the company, but that product team that you’re in.

And I’ll give you a couple of examples. You know, when I was running my startup and we were bootstrapped, so we had very little funding, and so survival to us was financial survival. And we had to be super careful with how we were using money, and so sometimes we took on more vision debt because that was the only way of surviving. So, for us, the right mix was taking on more vision debt and more of the ideal quadrant because we had to survive to be able to live long enough to achieve our vision, right?

On the other hand when I was working in—or on the other hand, in my current work with the Monetary Authority of Singapore, right, when I work with the Central Bank of Singapore, I mean, the organization is a public organization, and it’s not a matter of finances. It’s not—survival isn’t about financial survival. They’re not trying to make a profit. They’re supported by the government. But at the same time, survival means making sure all the stakeholders are in alignment, so that’s how we define survival. And in that case, we can actually invest in the vision more. And, you know, we are able to take more time, let’s say, or not worry about the financial—just trying to constantly make a profit, right? Like, we’re able to do the right things in terms of investing in the vision to think more long-term about how do we create the right experience for financial institutions, etc.

So, the most important element of how do you find this right balance for your team and your organization is the communication—being able to draw up this X-Y axis and talk about, how you would prioritize it. And your stakeholder might push back, or they might support whatever you’re saying, like, "I think we can, in fact, do maybe more of investing in the vision." Or they might say, "Look, we have to win this deal, and we have to take on vision debt." But the good news is, right, at least as a group, you’re all actually acknowledging how much vision debt you’re taking on.

What causes the disease, like obsessive sales disorder, is when you have no idea that you’ve taken on vision debt, and you just keep on taking vision debt without acknowledgment from everyone. So that’s why this communication is so helpful—it helps you keep track of how am I creating this balance.

Glasp: Yeah, so insightful, thank you. But it’s a great question from you.

Radhika: Yeah.

Glasp: Yeah. But I mean, balancing short-term so that survival also long-term. So as I mentioned, our mission and vision are long-term vision, but we are not sure how long does it take to achieve it or realize it. But we cannot only focus on short-term things.

Radhika: Yeah, but you know, what you just said about vision and mission being so long-term—like, one of the things that I found is when you have a vision and mission that is so long-term, like that five-, ten-year horizon, that far-away horizon that you can’t see, one of the things that happens is when it’s that fuzzy, your short-term business needs come more into focus as a result. So, if I think about, like, how you intuitively start balancing—if I’m not drawing up vision versus survival—when everything, you know, when my vision is so fuzzy and not in focus, what is in focus is your short-term needs. And that’s why you end up making more short-term decisions with a fuzzy vision and mission.

Glasp: Thanks so much. Yeah, and we feel—we understand the situation pretty well. And I think, so in the book, you mentioned a company you worked for a broadcasting company in Hollywood. And you mentioned that you were trying to digitize working flow, so instead of video tape. And you mentioned that you were persuading or convincing customers to buy a digital workflow instead of video tape.

We are kind of struggling with, like, preach our mission and vision to the customers, but for customers, they are demanding utility, short-term utility. "I want this highlighter, I want this PDF uploader." So, we tested our landing page, we just showcased our long-term mission, vision, but customers didn’t, they resonate with us, but they don’t sign up. So, I’m just curious how you overcame that situation.

Radhika: That’s a great question. I think that boils down to building a very clear product strategy. I think the vision gets you so far in terms of clarity. I think the next step is creating clarity by really understanding, by building a clear product strategy.

So in the Radical Product Thinking way, a good product strategy requires you to answer four questions, and the mnemonic is RADICAL or RDCL. The "R" stands for Real pain points. So first, you have to uncover who are the personas who are going to be using your product, and what is the pain that makes them come to your product? And then, once you’ve identified that, you can ask the next question, which is the "D" for Design. You can say, "Okay, for each of those pain points, what’s the solution in our product that addresses it for them?" Then comes the "C" for Capabilities, which is, "What’s the functionality, or what’s the underlying infrastructure or the engine that allows us to deliver on the promise of the solution or the promise of the design?" And the last is "L" for Logistics, which is where we think about the business model, pricing, support, training, etc.

So now, going to this question that you said, you’ve shared a vision, and the vision resonates, but people are still asking for all these features and pushing for certain features. I think what that points to for me is really building a more detailed RDCL strategy. Sometimes when that happens, maybe it’s that we haven’t really understood our personas, because there might be personas who need different things. You know, people can—it might sound like it happened to me that when I was working in a particular robotics for warehousing company, you know, we were targeting different verticals, different industry verticals. Like, for example, if you’re building warehouses for beverages, like Pepsi, or if you’re building them for, let’s say, frozen foods, the functionality in the end at a high level sounds similar. You’re like, "Well, both companies need packages moving in and out of their warehouse." But when you look at the details, the actual business drivers, etc., are very different, and so that leads to very different products.

And so, I think a similar thing here: when you look at the pain points and the personas, uncovering, really through perhaps user interviews, what is the pain, and how are you going to solve it, might lead to more definition than the vision. And maybe that’s the next step to pursue.

Glasp: I see. At the same time, sometimes people don’t know what they really want, meaning people sometimes are short-sighted. So, let’s say, especially in the consumer space, application or software space, let’s say Airbnb, in the early days when they launched and asked for money for BnB. You know, most people told them, "Who wants to stay in a stranger’s house?" Like, "Why would I stay at someone’s house?" But now Airbnb is a really big market, tapping into a really big market. But in the early days, people didn’t know what they really wanted.

So in that sense, how do you balance the innovation or innovative approach to solve the deep pain, or potential pain, to the existing pain?

Radhika: Great question. And this is one of the things that I really work with teams on when I do workshops on the RDCL strategy. You know, the technique here is not to ask users what they want, because they cannot know. We also cannot ask users, "Would you use this?" because they won’t know the answer to this. Like, it turns out that humans are terrible predictors of their future actions. We also can never be relied on to dictate the right requirements or to say, "I want this functionality," right? So, what can we do instead?

This is where user research comes into play. That as product people, we have to ask questions in such a way that we are relying on evidence from past behavior. And so, we ask questions about past behavior, we ask questions in completely neutral ways, so that I’m not going to bias your answer. So, if I ask you, for example, "Will you stay at this—?" or let’s say I’m building an app that encourages you to go to the gym, right? And I ask you the question, "Will you go to the gym if I do this?" You know what I’m hoping to hear, and you will most likely tell me, "Yes, I will go to the gym." The answer of whether you’re going to the gym or not—it can’t be relied upon for me as a product manager, right?

And so, I have to ask you questions based on what you actually did, like, "Did you go to the gym yesterday or last week? How many times did you go?" That is a better predictor, right? Then I can ask you other questions, like in terms of how you—or like, you know, which kinds of things—which kinds of nudges you have actually clicked on, or observing what you’ve done in terms of accepting rewards. There’s a set of things that you can do to, first of all, understand what a user needs, and then test out whether they will do something or not, right? And so, you do as much of this user research followed by user testing, and then you put out your solution and launch it, right?

And so, it’s never based on asking users what they want, but it’s rather understanding their workflow or mental models enough that you can then build based on what their intent is and based on, like, what will fit their user workflow and mental models.

Radhika: And by the way, like, this whole thing of user research—I’ve found that it’s actually a very rare and hard skill to build. Like, I find a lot of user research, like, asking questions because we want to know what people think. Like, we want their feedback, but we often ask it in terms of, "Let’s get your feedback in terms of what we’ve built." And so, there we really have to figure out the distinction between user research, which is purely exploratory research to truly understand workflows, mental models, and separate that from user testing, which is where we test solutions.

Glasp: I see. That was what we were actually working on these days. And yeah, thank you for the feedback.

Radhika: Yeah.

Glasp: Thank you for the advice. And also, nowadays AI is trendy, many people are using ChatGPT, Anthropic, etc. How do you think AI will impact product manager roles, jobs, or product development?

Radhika: Yeah, interesting question too. I think right now we overestimate the impact of AI on product managers. I feel like if you—so, for example, one angle that I’ve seen is product managers using AI to say, "What are the metrics I should be measuring for my product?" And I think that’s a very dangerous line to go down because AI can often tell you lots of things that you could be measuring, all based on popular metrics, based on what others are measuring. But the reality is, right, the vision and strategy are really what should be driving what you measure. So, if you think about your vision and strategy as hypotheses, what you measure is really derived from those hypotheses, and every metric is basically a way of telling, "Is my strategy working or not? And what should I change within my strategy?"

And so, when I think about measurement in this way, or even when I look at the concepts of vision, strategy, etc., AI isn’t really going to help you be that vision-driven product manager. You know, at best, you can use AI to write out different marketing messages and see what resonates. You could—like, I don’t really see AI as helping the product management function. In terms of how AI can be used by product managers, I think on that front, like, to be able to include it within their product—this is the other fad, right? Where everyone wants to use AI in their product, and that’s the expectation from a lot of investors. Like, if you don’t have AI in your product, you’re kind of left behind.

But even that, I feel it’s a lot of development to have decent enough AI in your product that makes enough of a difference. And if you are building all of that, you have to have this clarity of, "What exactly is your vision in terms of the problem that you’re setting out to solve by using AI in your product?" Your strategy should be clear enough that it really is solving for something. And if it’s not, it seems a little worthless to try to include it, right?

And there’s one last piece that I will say. Using AI in your product, right, it’s more likely to introduce biases within your product or to create unintentional consequences. There are so many instances of this where there was AI that was giving people really terrible advice on dieting or recipes, and things like that, where, you know, you really don’t want to introduce such hallucinations within your product. And so, one thing to think about carefully is, "What is the impact you want your product to have on society? And if there are biases in AI, which you should assume there are, you know, how will that affect that impact? How will it change the impact you’re going to have on society? And would you still be willing to take that risk?" And sometimes the answer is no, it’s not worth it.

And that’s something to consider. I think all of this goes to the question of, as a product manager, "What’s the legacy you want to leave behind through your product? Like, what’s the change you want to leave in society?" And if AI can harm that, don’t do it, you know, or be very careful with how you introduce AI into your product. Like, AI too has to be very vision-driven in how you include it.

Glasp: I see. And, by the way, do you use AI in your workflow? Like, you’re working with companies, other things—sorry, I’m just curious how you...

Radhika: Great question. Yeah. I don’t. I’ve tried, actually. I’ve tried to see if I could use AI for marketing purposes and to, help me craft blog posts or to craft even LinkedIn posts. And I haven’t been able to use it effectively in the sense that I hate what AI created. It just sounds like a bunch of, you know, wordy trash that I just end up discarding. And to me, like, that is a big piece of my brand, which is I want to write really thoughtful blogs or thoughtful LinkedIn posts, and AI doesn’t fit into my product strategy or my vision. So, which is why I don’t end up using it. But I wish I could, honestly. I really do wish I could use it. It would make just marketing so much more scalable for me, and it takes me time to write blog posts and LinkedIn posts, so I really wish I could use it. It’s just not the right thing for me.

Glasp: Yes, thank you. And so, moving to your daily information consumption—and because we are building that tool for knowledge management and note-taking. Do you use any journaling app or note-taking app when you—because a lot of things, right? You have a lot of ideas. You’ve learned a lot from your experience. Do you keep notes somewhere or synthesize ideas somewhere?

Radhika: Great question, fascinating. I’ll share a little bit about my workflow. So, yeah, often, I—so, when I read news, I will pick out stories that I actually feel are very interesting or that convey a certain point about being vision-driven or lack thereof. And my workflow is that I’ll send myself an email with a link to, you know, what I read and why it was interesting. And then the other piece of my workflow is, on a regular basis, I might write in my notebook, like, a whole passage. And I find it kind of meditative to write with a fountain pen and on a notebook where I kind of write up these ideas and describe, you know, concepts to myself.

And the last thing is I also use blog posts or work on blog posts to process some of these ideas and use these stories that I emailed to myself to be able to process kind of what are the main ideas that I’ve learned from them and how we can apply these ideas in our work.

Glasp: I see. And I saw a lot of examples in your book. You use Boeing 737 or, many examples you used. And do you search for the ideas you send to yourself then to write it? And I mean, in writing, processing writing a book—how did you, you know, get many ideas or examples and crystallize them into the book?

Radhika: Yeah, great question. So I end up searching—well, not searching later, but it’s more like I continue to create a collection of stories that I then email to myself. And then when I’m writing a book, for example, I do a search of emails from me to me. It’s not the best workflow. So if you have a better workflow, I’m more than open to it. So I search for these emails that I have written from myself to myself, and then I scour through those to be able to see what are some interesting stories that illustrate my point? And then I’ll use those in whatever I’m writing up.

Glasp: I see. And for product managers, do you have any tool recommendations for them? Like, aspiring product managers, senior product managers, like, let’s say, "Oh, like, Notion has this feature so that communication is better for something XYZ," or "Google Docs is enough." Do you have some preference or recommendation on tools?

Radhika: Oh, great question. I think this has been something that a product manager often doesn’t have a choice on. Like, you come into a company, and it’s pretty much whatever the company already has. So it’s mostly like, how do you just sort of get on with it? So I think I’ve developed personal preferences for what I like or don’t like, but even those preferences, they are so completely shaped by, you know, the organization and the complexity of the product in itself. Like, when I was running my own startup, we used Pivotal Labs because I think the features and the stories were just easier for us to deal with in that format. And then, you know, later when we, um, when I was working on Radical Product Thinking, we worked on Trello, but then, you know, when we were working in the robotics company, we used Jira. So I’ve used all of these different ones, but, you know, and, and I can say Jira is my least preferred one in terms of just the complexity of, uh, of user interface. It has tons of features, but I also see that it has its value, and developers find it useful. So you, you kind of go with whatever it is that, um, that you end up finding creates the maximum group value, I guess.

Glasp: Thank you. Yes, I have, yeah, the same opinion on Jira. But yeah, thank you. So I think, uh, yeah, so because our audience are aspiring product managers, or senior product managers, CPOs, or sometimes founders. Do you have some advice for those people in terms of career or their work and product thinking?

Radhika: I think the one thing that I found in my own experience is that it’s really easy to get stuck in a tactical role. You know, whether you’re a leader or an individual contributor, the pressures of short-term business needs are such that it very often pushes you towards a tactical role and being more reactive in your role. And so the question is always how do you take on a more strategic role as a product manager or as a product leader?

And a lot of my work more recently focuses on how do you level up, right? And a lot of that has to do with being able to create this clarity of vision, being able to help your team understand how to systematically translate the vision into reality. And so, along those lines, there’s a new course on vision setting that I’ve co-created with Pendo and Mind the Product, and it’s a free Radical Product Thinking course on vision setting. And then there are live online workshops where people can learn to translate that vision into strategy, priorities, execution, and measurement and culture. And the live workshops actually give you also personalized feedback so that as you’re working on your specific product, you know how to do this.

So those are the things that I’ve currently been working on in terms of really helping people level up. But I think the summary of all of it and what I was trying to say is I think the challenge, the biggest challenge for leaders and also individual contributors is don’t let yourself just be always sucked into this tactical role. And it’s a question of making sure that you can be vision-driven, and if you constantly communicate your rationale for how you’re thinking, you’re able to then spread your influence across the organization more, and you can really level up as a result and get other people to think strategically as well.

Glasp: That’s a great advice. Yeah, thank you so much. And lastly since Glasp is a platform where people can share what they are reading and learning as a digital legacy, we want to ask you what kind of legacy or impact do you want to leave behind for the future generations?

Radhika: It is a big question, and I love that question. So to me what I really wanted to do with Radical Product Thinking was to really allow people to create the change that inspires them. So if there is any legacy, it isn’t about, like, the fame of the book or it’s not about the fame of the methodology, but rather, like, if people can really learn how to create change in a way that inspires them and leave the world a little better than when they found it, that’s really what I hope to achieve.

And so when I wrote the Radical Product Thinking book, like, one of the reasons I was so obsessed, and it took me three years to write the book, was really because I wanted to focus on how do you create the change that inspires you? And it can be in so many different ways. It’s not just being vision-driven at work, but whether it’s thinking about the volunteering that you’re doing or political activism or even parenting—if you think about it as a product, you can apply these same ideas of vision, strategy, priorities, etc., even to parenting, right? And so that’s what I really wanted to leave behind—to have people be able to be vision-driven in what they’re taking on.

Glasp: That’s a beautiful statement. Thank you so much. And thank you for taking the time and joining today.

Radhika: Thank you, I really enjoyed this conversation, and thank you so much for all the insightful questions that you’ve asked.

Glasp: Thank you, yes.


Follow Radhika Dutt on social


About Radical Product Thinking

Radical Product Thinking (RPT) is a methodology that helps you build world-changing products systematically. Instead of being iteration-led, it helps you become vision-driven and translate a concept into reality step-by-step through the five elements of RPT: Vision, Strategy, Prioritization, Execution & Measurement, and Culture.

Twitter

Share Your Excitement

Ready to highlight and find good content?

Glasp is a social web highlighter that people can highlight and organize quotes and thoughts from the web, and access other like-minded people’s learning.

Start Highlighting