← Product Thinking
Loading summary
Transcript51 lines
- [00:00]
A
Hello and welcome to another episode of the Product Thinking Podcast. Joining us today is Uday Marappalli, Director of Product Management at upwork, where he leads innovative initiatives on the Emerging business team with a strong focus on the AI category. With a career that spans building and scaling products from inception to maturity, Goodeye has honed his expertise in navigating the unique challenges of launching zero to one products, particularly within large organizations. His background also includes roles at marketplaces like Glassdoor and SmartAsset, as well as experience in venture capital and strategy for AI startups. Uday is a recognized speaker on topics related to product management and machine learning, making him a valuable voice in the world of product innovation. But before we start talking to Uday, it's time for Dear Melissa so this is a segment of the show where you can ask me all of your burning product management questions. Go to dearMelissa.com and let me know what they are. Here's this week's question. Dear Melissa, how can a product manager make a significant impact when an IT company wants to re engineer a legacy mainframe solution into a cloud native digital product? Especially when it thinks they already know everything? All right, so this is a really common scenario that I have run into quite a bit. A lot of time we treat a cloud migration like a IT project or an engineering only project and that is where I see them crumble. They just go to hell. It's happened so many times, I can't even count on both hands how many times I've seen this happen. Why does this happen? One we're not thinking about the outcomes. A lot of times we go, hey, let's just move to the cloud. When you move to the cloud there are more costs usually associated with it than when you have something that's on prem and you have to take that into account. So the cost of actually servicing your products now is much higher. But cloud does offer a bunch of benefits. So what are we trying to get out of the cloud migration? We can actually track product usage a lot better. So we know now if people are adopting our products, if they're using it, we can also iterate and deploy that back to a lot of people in a seamless manner instead of trying to do updates in roundabout ways like we used to with legacy mainframes. There's a lot of benefits to this cloud architecture. It allows us to have multiple points of failure in a lot of different ecosystems so that we're not just reliant on one location. Hopefully a large company isn't reliant on one location. But if we start modernizing and thinking about cloud, what we really want to recognize with our products is that product experience becomes much more important when we move to the cloud and it becomes possible to do a lot of things that we weren't able to do before when we were working on a mainframe infrastructure. So when you're approaching this though, you have to know what your objectives are and you have to know where the value is to move something off a legacy mainframe. Especially in a really large company, it's not going to be a one and done thing. It's usually approach where you carve out pieces and you start migrating them to the cloud and you're trying to figure out where to start. As a product manager, you can come in here and help them figure out where to start. I would start with things that are critical for our users and especially things that we might want to update or modernize. So this is also a perfect opportunity where you can rethink your UX out as you move to the cloud. You don't have to do a one for one transfer. You might be able to harness a lot of stuff that you did not have on your legacy mainframe. So I would approach this as how can we rethink some of our products and our critical products when we make this move and what might we do to take the things that we have and re architect them and release them in a cloud approach instead of just copying it one for one, this can give you a leg up. This can actually help increase a lot of business metrics here. But if you're not approaching the migration with that mindset, a lot of times what we're doing is just duplicating one from a mainframe up to the cloud. It provides us a lot of opportunities to get in there and actually update our products, make them better, make them more usable for our customers, get us better data on how people are using it. And if we're not taking advantage of that in a transformation, you're losing a lot of the value here. So that's where product management becomes really important. So what you can do is take a step back, try to figure out why are we moving to the cloud. Do people recognize the significance of moving to the cloud? You know, we got costs incurred here, but we get all these upsides. All right, with those upsides, what can we do to further our business goals and carve out pieces to move to the cloud instead of just trying to do it all at once? What are places where we can release to the customer and Provide value. Now if you don't handle this well, you also have churn risks, right? If you don't onboard people to the cloud cause you're going to need them to adopt those products and move over to the cloud. If you mishandle that or things go down or things start breaking and it's clunky and it's weird, people are going to get upset. So there's churn risk. You want to manage the risk here. You want to manage the long term vision of what you're doing to go to the cloud. You want to make sure people understand why you're moving to the cloud. You want to make sure that there's value metrics associated with it and then you want to see what you can do to leverage and provide better customer experiences along the way. That's going to make people really excited about this switch and that can also help bump up a lot of your product metrics and your company metrics in turn. So I hope that helps and good luck with your migration. Again. If you have questions for me, go to dearMelissa.com and let me know what they are. Now let's go talk to Udai. Welcome to the show, Uday. It's great to have you.
- [05:23]
B
Thanks Melissa. Good to be here.
- [05:26]
A
So you've had a very interesting career in product management. You've also worked in venture capital. Can you tell us a little bit about what drew you to the art of product management and getting into it?
- [05:37]
B
Absolutely. I was fortunate to have started my career in venture capital backing really early stage startups. My job was to basically listen to the pitches of founders, analyze the market and business they operate in, and assist them to get to the next phase by providing financing over time. One aha moment I had was that most successful founders, and by extension the products they build, either solved a really unique problem or solved a problem in a unique way. Using technology interacting with them was a joy. I truly enjoyed brainstorming on product direction over the course of time. At some point I realized I want to be actually building products and and product management gave me the opportunity to do that.
- [06:25]
A
That's great. So you've been focusing a lot of your career too on zero to one products, which can both be challenging but incredibly rewarding. From your perspective, what makes building zero to one products such a unique and exciting area within product management?
- [06:39]
B
Yeah, firstly there's this unique thrill of solving unstructured problems and actually creating something from nothing which can be very joyful if you enjoy the uncertain ride. If you think about it, 0 to 1 is just a list of hypotheses the team has, and to go from concepts to the actual product by testing and validating those hypotheses. The pace of progress is exciting, although I must caveat by saying that you want to balance speed with the thoughtfulness and validating hypothesis. And thirdly, I think it's a solid training ground to build foundational mindset that helps you be successful in any product role. Things like resilience, curiosity, and willingness to challenge assumptions are foundational skills that you can leverage as you move on to different roles and also climb up the product management ladder.
- [07:31]
A
What do you think makes the aspect of zero to one products good for honing those foundational skills?
- [07:37]
B
Three things that you need to absolutely get right while working on zero to one products. The first one is absolute customer obsession. You want to be focusing relentlessly on understanding the key customer problems, pain points, and essentially have a way of directly engaging with customers to validate them. So you start to build a muzzle of direct customer interaction and engagement and are really close to what their needs are. Secondly, there's a lot of iterative thinking that goes into play. Like you want to be embracing a test and learn approach to validate ideas quickly and reduce risks. And a big part of this is prioritizing progress over perfection. So you want to launch small, see how it goes, and then refine based on customer feedback. Thirdly, it helps you build the skill of storytelling and influence, which is foundational to be successful in any role in today's. Well, to be honest, if you're up for a challenge, sign up for launching a product in a slightly larger company and you will realize the number of things you need to do in order to get it out of the door. So it's a real ground to build stakeholder influence, which is like a critical skill to have.
- [08:50]
A
So when you are building zero to one products, which you've done in these large companies, where do you start? Right? How do they come up? Where it's like, hey, Udai, I need you to go do this. How's the idea happen? And how do you start to make sense of what you need to do?
- [09:06]
B
Yeah, it's a combination of what the user needs are, what the business needs are, and the intuition. You're building it on a particular space. Oftentimes we are having these customer conversations where customers would be like, hey, I wish your product did X, Y and Z. And you start to hear these themes consistently. And now you're building like a point of view of, hey, here's the way that I can extend the product and how it serves my customers. So that's one natural way of discovery and understanding of customer needs. Then there are instances where this is driven by some of the business requirements. For example, let's say a business is operating in a smaller market that's quickly saturating or has competitive pressures. Then you're starting to think about, hey, who are the adjacent customers I can serve and what are the technology products that I can build in this space? So it's driven up by like a business requirement and the need to essentially grow your footprint. So that's the other way it happens oftentimes though. It's just like a combination of both coming together. You usually have a team that is chartered to think about innovation and growth, and that team is constantly on the lookout for unmet customer needs and creative ways to solve them.
- [10:22]
A
When you're figuring out how to get started, do you rely on any specific tools or frameworks?
- [10:28]
B
Yeah, it's a great question. It's a mix of relying on frameworks and intuition. I do want to underscore the importance of intuition here. Oftentimes you have a really strong product manager manifesting a vision in order to address a customer problem. There are times when you rely on frameworks like one of the framework that I consistently use is the jobs to be done framework. Like what is your user trying to achieve? I think it helps anchor the team around core customer problems. Sometimes while building new products, it's easy to get carried away by the awesomeness of technology. But anchoring around the jobs to be done framework and what customers are seeking helps reent that instant and make sure that you're truly building value.
- [11:11]
A
So when you're working on a brand new product, one of the common things I hear from product managers too is that traditional success metrics can sometimes feel like irrelevant or premature. For example, we might care about retention, but we have nobody on our product right now. So what do we do? In your experience, what are the most meaningful indicators of progress or success when you're working on zero to one products? And how do you track them?
- [11:35]
B
Absolutely. If we had an ideal metric, that'll be awesome. But the fact of the matter is you try to find proof points along the way. Just a note on retention, like I want to underscore the importance of retention and it being a measure of product market fit. In the past, every successful product I've launched has had shown great retention and in areas where I skimped over retention, it did not land well. So I just want to Underscore the importance there. That said, retention is often a lagging metric, so ideally you want to be pairing it with a leading indicator, and that is usually customer satisfaction based on things that have had success in the past. Now, there are multiple ways to measure customer satisfaction. You could wait for your initial customer to complete the usage of the product and then seek their feedback at the end. The other option is to have continuous touch points and make sure that you are receiving feedback as they experience and engage with the product. I think continuous options can be a good way in order to regularly assess how much value your customer is getting out of your product. Recently, one of the most popular ones I've heard is lscore. Have you heard about lscore?
- [12:48]
A
I haven't, yeah.
- [12:49]
B
It's basically, I believe, from Sean Ellis, who is a partner at Reforge. I'm not sure I'm remembering that correctly, but maybe that's something I need to check up. But the question he proposes is asking your customers, like, how would you feel if you could no longer use the product? And then you seek their responses on the range of very disappointed, somewhat disappointed and not disappointed. And he recommends that the goal is to reach a stage where at least 40% of your users would answer very disappointed that they could no longer use your product. And from their experience, it is a good measure of a product that has achieved product market fit. I like that approach in the sense that it's actionable to early stage product development teams. And the 40% benchmarks sets an industry standard that teams can strive towards.
- [13:42]
A
I like that one, too. I have always thought NPS sits a little difficult because I've heard people say, would you recommend this to a friend or would you recommend this to a colleague or whatnot? I've had people literally turn around and go, no, because I don't know anybody else who needs this right now. I don't have a friend who would be interested in this. So that's why they answered no rather than I don't like it. But I think that's a much more effective way of gauging if people are satisfied.
- [14:06]
B
Yep.
- [14:07]
A
Yeah, I really like that. Now I know a new score that I'm going to recommend to people. So when you are in here measuring these leading indicators, let's say you encounter some conflicting insights. Maybe what's happening in the market is different than customer insights or you're hearing different things come through. What are you relying on? How are you staying true to your success metrics? And how are you dealing with things where you Might get information that's canceling each other out or conflicting with what you thought.
- [14:37]
B
Yeah, that's a great question. I think first off, this is one of the reasons to importantly define the vision upfront. As you're starting to build zero to one products, your vision needs to be a clear customer centric North Star that helps you make these decisions as new information comes along the way and new information is going to come come along, which is basically how the zero to one efforts go. The way that I tend to handle information is you want to be able to constantly going back to what are the hypothesis that you're making and try to fit this information in context of that hypothesis. So you're essentially trying to figure out if the problem is valid, the solution is valid, what is this new information trying to tell you. So looking at it in the context of the overall hypothesis and using that informed decisions is one way that I consider this. And then really every product team has two choices. You either continue iterating on the direction you're pursuing or you pivot to an entirely different direction. My general framework is you want to be able to iterate if the problem is clear and the execution is off. But if the problem access or the hypothesis you're using starts to change, that's when it's time to pivot. So essentially the ways in which you can react in your information changes and the direction that you choose changes. The third one I have found helpful is really being transparent with insights and sharing with them with broader teams to ensure alignment. A lot of times somebody on the team might have some context that helps you process and see this new information in light. Being able to rely on your stakeholders or the domain experts in the space has also been a helpful tactic for me as I navigate and process new information that's coming. So to summarize that point of view, there like one anchor on your vision, make sure that you're constantly revisiting the assumptions based on this new information. Figure out if you want to be continuing iterating, which is a path to go if the problem is clear or to what? To an entirely different path. And then just make sure you're leaning on the experts on your team in order to drive these conversations forward.
- [17:05]
A
So Udai, with the success metrics, it gets us into talking about products that fail, right? So when we're launching 0 to 1, as you said, there's always a hypothesis and many times that hypothesis proves to be wrong. Have you encountered any situation like that and how have you approached it?
- [17:24]
B
Absolutely. This has happened A couple of times over my career. The first time this happened was when we launched a product to address the needs of SMB customers as it relates to their hiring needs. Within a few months of launching the product, we reached a point where the adoption was stalling. The lifetime value and CAC at which we were acquiring made no sense from a business standpoint. And there were some friction points between the team too because the product was not growing. The approach that I took was to really lean in on customer feedback and data and we figured that the product itself was like a multi step funnel and there was drop off at each steps of the funnel and which was essentially overwhelming to customers. There was some feedback on how our pricing was also not transparent and ultimately that informed adoption. The interesting thing in this case is going back to the Iterator pivot decision. It was increasingly being clear that the problem we were going after was A not validated enough. So not a lot of customers had this problem that made it justifiable for us to continue investing and B, is there were some fundamental technology shifts underway with AI that could have solved this problem in a better manner. So part of that vision was we were like, hey, are we solving a meaningful problem here? And the answer was no. And then the next one was for those who have this problem, can we solve it in a completely different way versus how this product is structured today? And the answer was yes, based on the technology capabilities of that day. So we made addition that sunset this product sent an email to our customers and explained why and ultimately offered them different products in its portfolio. That said, a couple of years later, we're approaching solving the same problem in a completely different way using technology that feels more promising and more aligned with customer needs. So that's one of the instances where I had to make the hey, do we continue iterating or do we kind of pivot decision? And the framework laid out made it clear that pivot was the need of the hour in that instance.
- [19:47]
A
In this case too, it was a situation where the problem wasn't strong or like the problem wasn't strong yet. Right. Like it hadn't emerged over time.
- [19:58]
B
Yeah. To be candid in this place, it was like the problem was not strong enough for a meaningful number of customers. So there was like a small set for whom I was ahead on the fire problem. But for a majority of them it was not. And more importantly, there was like a meaningfully different scalable way of solving it. And the team just felt strongly then we could potentially skip focusing on what we're doing here until technology becomes better and a different solution can be offered in a more efficient manner.
- [20:30]
A
So the solution that you're currently revisiting, it's that the investment and it justifies solving that problem. But before the solution didn't.
- [20:39]
B
Correct. Yes. Cool.
- [20:41]
A
That's interesting. I think that happens too over time where I've seen people launch products. Right. Where either the market hasn't caught up yet or the problem isn't strong. But it doesn't mean that it won't be strong one day, it's that it's just not strong today.
- [20:55]
B
Absolutely. One of the mentors that I work with raised an interesting point. They said that every product or feature that PMs propose investment in needs to answer why not? So why is this the right moment for the company or the team to be investing in this direction? And it usually is, hey, it's a head on fire problem, or we think there's a meaningful number of people who have this problem, or it's more around, hey, the technology is there, it's the right time to do this. So why now is an interesting question that most teams should ask themselves.
- [21:32]
A
Yeah, I like that one. I think a great example of that is like vine and TikTok. Vine completely went out of business, basically did the same thing, but everybody wasn't quite used to what we see now with the short videos and the creation. And they approached it slightly different than TikTok. But now TikTok's huge.
- [21:48]
B
Absolutely. That's a great example.
- [21:50]
A
Yeah, I like that. How do you. So here's one though, which I've run into a lot at organizations. Say we go out there and we tested a product like you did and we decided not to move forward with it when we go back to revisit it. I've heard pushback from people who have been there for a while saying, oh, we already looked into that and it wouldn't work, it didn't work, don't go after that, don't do that. And I feel like that's pretty common in organizations for people who've been around for a while say, oh, we tried that, we did this, we did that, and sometimes that's justified and other times it's not. How do you track the progress, let's say, of what you're testing in zero to one products, whether you decide to pivot or sunset it in a way where you can address some of those organizational hurdles when you want to go back and try it again.
- [22:35]
B
So that's a great question. One way to think about it is how can product teams be really effective at documentation, even from conceptualizing the product? So my company leverages the PRFAQ process, which was popular or made popular by Amazon, and in this setup, a product person writes a press release, ultimately putting themselves in the shoes of a customer, actually using the product. And then there's a set of external FAQs that are customer facing and a set of internal FAQs that are company facing. I think the internal FAQs like a great spot to document these assumptions that the team is making and also reference some of the earlier efforts of the company and really put out a point of view of what were the gaps back then and what is correct, what can be done now. And the key is to draw this true line through. So the document is like a living source of truth that as you make progress, as you test these hypothesis, as you make iterations, you want to be able to fully centralize and capture all the credit descriptions or key changes within the context of that doc. So in my experience, one of the examples I can share is, remember we spoke about having to pivot a product and actually sunset it towards the end. I actually wrote out like a section in the PRFAQ to outline the reasons we are sunsetting. And it's been about like three years since that decision was made. And I still get incoming brings from other colleagues in the company who want to know more context around why that product didn't work and how it applies to their product space. So being very crisp about documentation, maintaining a single source of truth, and really drawing the through line from having the document capture why a product was conceptualized to why a product was killed is a good way to anchor the discussion and make sure that folks in the company are aligned. As you pursue a new direction, what's.
- [24:38]
A
Important for product managers to include on the part about why a product was killed, what kind of items should they put there?
- [24:44]
B
You want to anchor around what are the customer needs that you set out to solve? What were the learnings while trying to solve for the adjacent needs? And tee it up with what are the key reasons why the team recommends not continuing with the product anymore? And essentially have a section on how are the customer needs going to be met in the future. For example, for the product that I had to sunset, I actually made a point to note that the rate at which technology was growing, the same customer problems could be solved in a more efficient way a couple of years later. And that actually held true and that held the test of time. So being able to document the hypothesis the reasons for sunset and then essentially build a point of view of how critical or how relevant the customer problem is going to be and how you can solve it going forward are a few things that should be captured here. As I think through it, the only other thing I would think about is essentially it's highly likely that a certain set of customers are using the product today. Now, as you make the decision to sunset this product, how are these customers going to be impacted and and what is the kind of messaging and features and benefits that you want to offer to them so their needs are being met? And there are different approaches here. Do you want to issue them credits, do you want to grandfather them into a new product or do you want to introduce them to different products in the portfolio? All of them are different techniques to take care of. But it's really important to have a customer transition plan and have that be like visible and shared across the org so your customers are not left in the tray.
- [26:25]
A
I like that. My next question was going to be how do you manage that risk of rolling it back? And from the customer's point of view, I hear so many companies that don't want to experiment because they think they're going to alienate all of their customers if they have to roll it back or if they have to kill it. So how do you manage that risk when it comes to rolling out a new product, testing a new product, and what happens if you have to bring it back so that you don't lose all of your customers?
- [26:51]
B
Yeah, a couple of ways that I've seen teams do this and some best practices from my experience is one, you want to start off by setting real expectations that the product is something being tested. A popular technique I've seen teams use is they ship with a beta label. So it's clear to customers too and it sets expectations on what to expect. I would also like there are instances when you have to kill these products and helping your customers navigate the transition is as critical as launching the product itself. A few things that worked in my experience is one, you want to be consistent in your communication. Treat it as a product launch. So when you're launching a product, you want customers to be aware that you're launching it and it's going to be out there. When you're killing a product, that's the same rigor that you should apply to and make sure that your customers hear about it because ultimately it's going to impact or affect their workflows. The second one is you can offer alternatives from your product portfolio Are there any relevant products that address the same needs? And can customers be transitioned to the product? That's the other way to go. Three is you want to be providing a grace period. Hey, you can continue to use the product for X days. Realizing that this is critical. This is a critical workflow for your business. So that's one direction that they could take. And then there's some standard tactics around offering them incentives to acknowledge their loyalty and make sure that they feel they're getting something in return. So I think these are a few common techniques that can use to ensure that the transition is smooth. From my experience, if you do all this right, then customers understand why businesses make this decision and it's really, I wouldn't say it's super palatable to them, but at the end of the day, their business workflow is being affected. But they understand the why. And the trust in your brand and the trust in the other products in your portfolio will continue to remain the same or increased in how smoothly you handle this transition for them.
- [28:54]
A
That's great advice. Yeah, I think communication is everything when it comes to that. With the type of risk we're talking about too. A lot of organizations put in a lot of red tape, a lot of bureaucracy and their processes that kind of inhibit us from being able to be innovative or build zero to one products. What are some common hurdles that you've experienced in companies that prevent them from being as innovative as it could be or making more zero to one products? And how have you been able to navigate around them?
- [29:22]
B
Absolutely, that's a great question. There is red tape and organizational hurdles. That's the reality of working in these kind of roles. There's a few things that work for me and my team here. One is to address the concerns of bureaucratic processes. Our product ops team, which kind of maintains our product development and launch process, has built out a streamlined path for approvals for zero to one products and risky bets. So if you're a product leader, you want to be working with the right teams and making sure that your team has the right set of processes in order to test 0 to 1 products. And there's like just a different yardstick of, hey, what are the risks and what are the like, approvals needed in order to go live with in the hands of customers? So that's one approach. The second one is in general, you have instances where there's a limited resources who are working on the 0 to 1 effort. 90% of the company is working on like this app aspect of the core business that generates Millions of dollars in revenue and you have about 10% working on the zero to one idea, which has to show which probably has a great financial model but nothing else in order to go for it. A couple of ways to tackle that is one, you want to push for dedicated teams fully staffed up in order to execute on the 0 to 1 direction. Because you want to be sure that you're failing because of an issue with a problem or the solution space and not due to lack of resources and lack of trying. So dedicated resources to a new space makes sense. And in general, like, you also want to make sure that you're prioritizing ruthlessly and anchoring on like the top hypothesis. So those are two things that you can do to get past resource constraints. Third, there's also a bit of risk aversion within large companies. For fortunately, it's not a challenge I've experienced in my career so far, but something that I hear a lot of friends do. My advice in that situation is you want to start off by framing new product initiatives as early experiments to reduce the perceived risk and then use early success to build out that momentum. Like it's not palatable if you go in and say, hey, we're going to completely transform the business model or how the company builds products or serves a set of customers. But if you're framing it as, hey, I'm going to run a test with these hundred customers in order to prove out A, B and C, that's a bit more of a palatable approach and gives you the license to go test and build out your point of view. So those are a few common techniques that I had used in the past in order to help sure that me and my teams are unblocked.
- [32:13]
A
It can launch 0 to 1 in some organizations. I've seen them with dedicated innovation teams where there's this friction between the other teams, right? Oh, they get to do all the shiny cool new stuff and we gotta go deal with tech debt and all these existing products. How do you handle those cultural differences and make sure that you're not being ostracized by the rest of the organization?
- [32:37]
B
Yeah, absolutely consistent lines of communication. The rest of the ARC is going to be like super critical. You might be working on this shiny zero to one space, but it's imperative that when you meet stakeholders in the other parts of the arc, they're brought along the journey. Common techniques I've used is presenting during like large company forums, being up, being really honest about the team's progress, what's working, what's not and having frequent check ins with some of these stakeholders. Having has worked well. And in general you want to make sure that your teams are sticking to these practices too in terms of being empathetic and kind while working with colleagues across the arc. That said, a lot of times I've had teams surface that hey, XYZ team is blocking my progress or I'm not able to get this because this team doesn't know the same rate as I am. And one of my first questions is what is their point of view? Because a lot of times they're trying to really put you on the right path and making sure that they are doing the work that is important to their domain, which is stopping you or blocking you from doing yours. So how do you really display empathy for each function and bring them along? The ride is one aspect that product people and other drivers need to focus on. So those are like some common techniques to make sure that there's no friction. And if there is friction, you want to be like addressing it effectively so it doesn't go further.
- [34:10]
A
That's great advice when it comes to organizations as well. Once we decided to pivot or kill a product, sometimes that can lead to low morale, especially on the teams that you work with or anything adjacent. People who had some skin in the game. How do you make sure that people don't dismiss something like, oh, you guys did it wrong and blame you for killing the product and how do you keep people's morale high that you're going to find something good?
- [34:39]
B
Yeah, just to clarify, are we talking about the morale of the working team or are we talking.
- [34:44]
A
I guess I'm thinking like of both sides because right. Like the team can feel very much man, like we just put so much effort in there. Some cost fallacy. No, let's just not roll it back like we already did it. It's already out. Like just leave it. And you can also hear that probably from other people in the organization too.
- [35:00]
B
Absolutely, that's a great question. I think the People part of 0 to 1 is so critical here and it becomes like more critical when the product doesn't work as intended. Which to be really candid is like 90% of the times. Right. There's a couple of techniques that I've leveraged. One is this is one of those instances where as a leader you want to balance transparency with sensitivity. As you're going through the process earlier on, it's important to be open but also understand that there's an emotional impact of any information you share. Lean towards sharing what's necessary for the team to stay informed and focused, but avoid overwhelming them with every detail where you're forming the plan. So just maintaining the balance of transparency and sensitivity is one thing to keep in mind. Secondly, you want to be honest about the why In a lot of cases, if you've made the decision to kill a product, the team probably already feels it, they know it, it's just they've not voiced it to you. So being transparent about why you're making a certain decision is helps them process this information and also helps them reach the reasonable, the same reasonable conclusion that you did. The third thing that I felt more tactically is as you go through this process, you want to be explicit about what next steps for each individual are. And ideally, as you go through this process, your team is starting to flex into new projects, different roles and new opportunities that are setting them up for success. And they're able to quickly see that, hey, there is a path for me and the product is going to go away, but here's what I will be focused on in the next six months. So as a leader, it's up to you to create that clarity for the team. Essentially, once you're able to give them the clarity, now they also want to dive back in and help you execute on the sunset. And in most cases, since they're the most closest to the product, they are the ones who can provide a smoother transition for customers. So those are a few tips of engaging your immediate team. And as you think about the rest of the org, part of this is around how do you message the charter of the team itself? If it's widely understood that your charter is to take zero to one efforts, there is a certain level of levy baked in with the assumption that hey, this team probably will only meet 50% of their goals or they will probably sunset more products than they launch. So you want to be able to set those expectations upfront with your leaders, the leaders of the org, and consistently continue to message that. So if hard decisions are made, it is in line with the charter of the team versus something that happened in a silo. So those are a few techniques on motivating your team while also making sure that the rest of the arc continues to see you as like a growth vector, really chattered on to take new bets that might even fail sometimes.
- [38:12]
A
So, Uday, you also have experience working with AI products. What is unique or challenging about doing zero to one AI products these days?
- [38:22]
B
That's a great question. AI is naturally the most exciting technology out there at this point in time and most product teams are starting to think about, or probably are actively thinking about, how do they incorporate AI? It's been a couple of years now. In the zero to one space you want to be ensuring that it aligns with user needs and delivering practical value. I'll start off by saying that. And then there's a few tactical things in order to get there. One is how do you get the right kind of data? By definition in the zero to one space is a lack of data. And ensuring that you have enough data can be difficult, especially for new products. In general, I recommend starting with like smaller high quality data sets in order to bring your product to market and then implement really robust data collection strategies. So you might start off with a data set of thousand rows that are likely curated by experts. But as you roll out your product, you want to be building these mechanisms for users to directly contribute to data that can be fed into your models, making them more intelligent. So that's one challenge and tips in overcoming it. The second thing, and this might not be unique to 0 to 1, but I see that there's a lot of desire for explainability and trust. Like users and stakeholders, while excited about AI, are also wary of AI driven decisions, particularly if they don't understand how the model works or why it's making certain recommendations. Generally, providing them context and pairing it with smart explanations is something that can assuage some of those concerns. The other option is to consider human in the dope experiences. For example, if you're building a product that automates business workflows, you want to absolutely make sure that the technology is reliable and it's not hallucinating. Can you include like a workflow expert within the process so they're able to serve as like guardrails and are able to essentially monitor how the AI is performing might be an interesting direction to consider. So those are a few like aspects to consider as you think about building zero to one AI products.
- [40:39]
A
You have so much knowledge on building these types of products. What are your biggest lessons learned as you have developed a lot of zero to one products? And what would you recommend for product managers out there who want to build more of these?
- [40:52]
B
I think I have three high level takeaways that I want to share as you build zero to one product efforts. Firstly, start with a clear problem and not a solution. A lot of the space is around innovation. I get that. But innovation really thrives when addressing real customer pain points. So starting with the problem allows for more like creative and flexible solutions. The second one is around customer Feedback Customer feedback is gold, but always think about the context in which it's shared. You want to be balancing direct customer feedback with trends from the market and what your internal goals are, so always try to map customer feedback back in the context in which it is being shared. The third one is fail. Fast experimentation and iteration are crucial. The faster you test and learn, the quicker you find what works and gives you an opportunity to double down on what's working. So if I had to put that in one word, you need to take more shots on goal in order to move forward and make sure you're landing.
- [42:04]
A
The product Uday, thank you so much for being on the podcast. If people want to learn more about you, where can they go?
- [42:10]
B
You can find me on LinkedIn Uday Mariapalli or hit me up on email uday.maripallimail.com A lot of thanks to the listeners out there. Would absolutely love to ref on this space and continue discussions about product building in general.
- [42:27]
A
Amazing. And we will put all of those links so that you can reach out to Uday on our blog@productthinkingpodcast.com so make sure that you go over there and check out the show notes. Thank you so much for listening to the Product Thinking podcast. We'll be back next Wednesday with another amazing guest. Make sure that you like and subscribe so that you never miss another episode. And if you have any questions for me in the meantime, go to dear melissa.com and let me know what they are. I'll answer them on the future episode. Thanks and we'll see you next time.