Episode 206: Building and Scaling Zero to One Products with Uday Marepalli
In this episode of the Product Thinking Podcast, I am joined by Uday Marepalli, Director of Product Management at Upwork, who brings his expertise from leading AI-driven initiatives to our conversation. Uday shares his insights on building zero to one products within large organizations, emphasizing the importance of understanding customer needs and leveraging AI in product development.
This episode dives into the challenges and strategies for innovating in a way that aligns with both customer expectations and technological capabilities. Want to learn how to effectively launch and scale products in complex environments?
Tune in to gain practical insights from Uday's extensive experience in product management.
You’ll hear us talk about:
06:24 - The Thrills and Challenges of Zero to One Products
Uday delves into the unique excitement and difficulty of creating something from nothing, stressing the importance of balancing speed with thoughtful validation of hypotheses
14:37 - Handling Conflicting Information and Making Strategic Pivots
Uday discusses how to manage new, sometimes contradictory, information by aligning it with the overarching vision and deciding whether to iterate or pivot.
38:54 - Building AI Zero to One Products
Uday explores the peculiar challenges of AI products, including data collection and ensuring trust and explainability in AI-driven decisions.
Episode Resources:
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | Twitter | LinkedIn
Episode Transcript:
[00:00:00] Melissa: Hello, and welcome to another episode of the Product Thinking Podcast. Joining us today is Uday Marepalli, 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, Uday has honed his expertise in navigating the unique challenges of launching zero to one products, particularly within large organizations.
[00:00:25] 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.
[00:00:41] 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
---
[00:00:53] Melissa: 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?
[00:01:08] Alright, 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.
[00:01:29] 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.
[00:01:48] 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 and 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 and a lot of different ecosystems so that we're not just relying on one location. Hopefully a large company isn't relying 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.
[00:02:52] 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.
[00:03:10] So this is also a perfect opportunity where you can rethink your UX 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 rearchitect them and release them in a cloud approach instead of just copying it one for one.
[00:03:38] 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.
[00:03:54] 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?
[00:04:12] Do people recognize the significance of moving to the cloud? We've 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?
[00:04:32] 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. So 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.
[00:04:47] 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.
[00:05:03] 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 dear Melissa. com and let me know what they are.
[00:05:18] Now let's go talk to Uday.
[00:05:20] Melissa: Welcome to the show. It's great to have you.
[00:05:23] Uday: Thanks, Melissa. Good to be here.
From Venture Capital to Product Building
---
[00:05:25] Melissa: 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?
[00:05:36] Uday: 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 solve a really unique problem or solve the problem in a unique way using technology.
[00:06:10] Interacting with them was a joy and 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 product management gave me the opportunity to do that.
Thrills and Challenges of 0 to 1 Products
---
[00:06:24] Melissa: That's great. So you've been focusing a lot of your career to 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.
[00:06:39] Uday: Yeah firstly, there's this unique thrill of solving unstructured problems and actually creating something from nothing. It 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 like concepts to the actual product by testing and validating those hypotheses.
[00:07:01] The pace of progress is exciting, although I miscaveat 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.
[00:07:30] Melissa: What do you think makes the aspect of zero to one products good for honing those foundational skills?
[00:07:37] Uday: To 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.
[00:08:16] 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 a skill of storytelling and influence, which is foundational to be successful in any role in today's world, to be honest.
[00:08:35] 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.
Core Skills and Starting Strategies
---
[00:08:49] Melissa: 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, I need you to go do this. How does the idea happen? And how do you start to make sense of what you need to do?
[00:09:06] Uday: Yeah . It's a combination of what the user needs are, what the business needs are, and the intuition you're building around a particular space. Oftentimes we're 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.
[00:09:28] And now you're building like a point of view of, Hey, here's the way that I can extend the product and have it tell us 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.
[00:09:53] 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.
[00:10:10] 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 greater ways to solve them.
[00:10:21] Melissa: When you're figuring out how to get started, do you rely on any specific tools or frameworks?
[00:10:27] Uday: Yeah, that'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 world product manager manifesting a vision in order to address like 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.
[00:10:49] 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 it on the jobs to be done framework and what customers are seeking helps read in that instant and make sure that you're truly building value.
Tools, Frameworks, and Metrics for Success
---
[00:11:11] Melissa: 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 any right now. So what do we do in your experience?
[00:11:27] 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?
[00:11:34] Uday: 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. 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 skipped over retention it did not land well. So I just want to underscore the importance there.
[00:12:02] That said, retention is often a lag 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.
[00:12:25] 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.
[00:12:42] Recently, one of the most popular ones I've heard is Eliscor. Have you heard about Eliscor?
[00:12:48] Melissa: I haven't.
[00:12:49] Uday: Yeah, it's basically I believe from Sean Ellis, who was a partner at Reforge. I'm not sure I'm remembering that correctly, but maybe that's something I need to check out. But the question he proposes is asking your customers, like, how would you feel if you could no longer use the product?
[00:13:06] 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 percent 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.
[00:13:30] I like that approach in the sense that it's actionable to early stage product development teams. And the 40 percent benchmark sets an industry standard that teams can strive towards.
[00:13:42] Melissa: I like that one too. I have always thought MPS 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? But people literally turn around and go, no, because I don't know anybody else who needs this right now.
[00:13:57] 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.
[00:14:06] Uday: Yep.
[00:14:07] Melissa: 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.
[00:14:24] 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.
[00:14:37] Uday: Yeah that's a great question. I think, first off, this is one of the reasons to importantly define the vision up front as you're starting to build 0 to 1 products. Your vision needs to be a clear, customer centric, not star that helps you make these decisions as new information comes along the way. And new information is going to come along, which is basically how the zero to one efforts go.
[00:15:06] 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, or what is this new information trying to tell you?
[00:15:28] So looking at it in the context of the overall hypothesis and using that to inform 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.
[00:15:59] But if the problem axis 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 to new information changes and the direction that it shows changes. The third one I have found helpful is Really being transparent with insights and sharing with them with broader teams to ensure alignment.
[00:16:24] 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, just to summarize that point of view there, like one, anchor on your vision.
[00:16:46] 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.
Handling Failures and Pivoting Decisions
---
[00:17:04] Melissa: So Udai with the success metrics, it gets us into talking about products that fail, right? So when we're launching zero to one, as you said, it'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?
[00:17:24] Uday: 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 Assembly 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.
[00:17:45] 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, which was essentially overwhelming to customers.
[00:18:14] There was some feedback around how our pricing was also not transparent, and ultimately that informed adoption. The interesting thing in this case is going back to the iterate or 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.
[00:18:42] 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 the addition 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 was structured today?
[00:19:08] And the answer was yes, based on the technology capabilities of that day. So we made addition there to 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.
[00:19:34] 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.
[00:19:47] Melissa: 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.
[00:19:57] Uday: 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 it was ahead on the profile 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 that 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.
[00:20:30] Melissa: 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
[00:20:39] Uday: Correct. Yes.
[00:20:40] Melissa: That's interesting. And 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.
[00:20:51] It's that it's just not strong today.
[00:20:54] Uday: 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 now? So why is this the right moment for the company or the team to be investing in this direction?
[00:21:12] And it usually is. It's a hair 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.
[00:21:31] Melissa: Yeah. I like that one. I think a great example of that is like vine and Tik TOK. 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 Tik TOK is huge.
[00:21:48] Uday: Absolutely, that's a great example.
Revisiting Products and Customer Transitions
---
[00:21:50] Melissa: 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've been there for a while saying, oh we already looked into that and it wouldn't work, it didn't work.
[00:22:08] 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 and 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.
[00:22:35] Uday: Yeah, that's a great question. In general. I'd like to think that PMs should index heavily on documentation. And for example, at my current employer, it all starts with a PR FAQ, which we have bought out from the Amazon practices. So a product person puts their point of view, works with the team, incorporates their feedback, and ultimately you have a list of questions.
[00:23:04] One. Cut. 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.
[00:23:34] 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 are 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 or what can be done now.
[00:24:00] 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 hypotheses, as you make iterations, you want to be able to fully centralize and capture all the credas descriptions or key changes within the context of that doc.
[00:24:20] So in my experience, one of the examples I can share is remember we spoke about having to pivot the product. And actually sunset it towards the end. I actually wrote out like a section in the PR FAQ to outline the reasons we're sunsetting. And it's been about like three years since that mission was made and I still get incoming prings from other colleagues in the company, who want to know more context on why that product didn't work and how it applies to their product space.
[00:24:48] So being very crisp about documentation, maintaining a single source of truth, it's 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.
[00:25:09] Melissa: What's important for product managers to include on the part about why a product was killed? What kind of items should they put there?
[00:25:16] Uday: You want to anchor it on what are the customer needs that you set out to solve, what were the learnings while trying to solve for the additional needs. and teed 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.
[00:25:40] For example, for the product that I had at 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.
[00:26:14] 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 what is the kind of messaging and features and benefits that you want to offer to them?
[00:26:34] 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 you do 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 dry.
[00:26:57] Melissa: 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.
[00:27:10] 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?
[00:27:23] Uday: 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.
[00:27:46] I would also like, there are instances when you have to kill these products and helping your customers navigate the transition is one of, 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.
[00:28:07] 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.
[00:28:20] The second one is you can offer alternators 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.
[00:28:44] 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 you can use to ensure that the transition is smooth.
[00:29:02] From my experience if you do all of this right, then customers understand why businesses make those decisions. 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 increase based on how smoothly you handle this transition for them.
Overcoming Bureaucracy and Team Friction
---
[00:29:26] Melissa: 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.
[00:29:42] What are some common hurdles that you've experienced in 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 it around them?
[00:29:54] Uday: 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 zero to one 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.
[00:30:40] 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 zero to one effort. Like 90 percent of the company is working on like this aspect of the core business that generates millions of dollars in revenue. And you have about 10 percent working on the zero to one idea, which has to show, it probably has a great financial model, but nothing else in order to go for it.
[00:31:08] A couple of ways to tackle that is one, you want to push for dedicated teams. fully stacked up in order to execute on the zero to one direction because you want to be sure that you're failing because of an issue with a problem in the solution space and not due to lack of resources and lack of trying.
[00:31:27] 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.
[00:31:49] 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.
[00:32:13] 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.
[00:32:38] So those are a few common techniques that I have used in the past in order to help show that me and my teams are unblocked and can launch zero to one.
[00:32:47] Melissa: In some organizations, I've seen them with dedicated innovation teams where there's this friction between the other teams, right? It's Oh, they get to do all the shiny, cool new stuff. And we got to 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?
[00:33:09] Uday: Yeah, absolutely. Consistent lines of communication with the rest of the ARG 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 has worked well.
[00:33:44] And in general you want to make sure that your teams are sticking to these practices to 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 move the same rate as I am.
[00:34:09] 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 versus 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.
[00:34:33] 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.
Keeping Morale High After Failures
---
[00:34:42] Melissa: That's a 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 are Don't dismiss something like, Oh, you guys did it wrong.
[00:35:04] And, blame you for killing the product. And how do you keep people's morale high that you're going to find something good?
[00:35:11] Uday: Yeah. Just to clarify, are we talking about the morale of the working team, or
[00:35:15] Melissa: Both, I guess I'm thinking like both sides. Cause right. Like the team can feel very much man, like we just put so much effort in there, sunk 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.
[00:35:32] Uday: 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 90 percent 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.
[00:36:01] 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.
[00:36:20] 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.
[00:36:36] 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.
[00:36:59] 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, that is a path for me. The product is going to go away, but here's what I will be focused on in the next six months.
[00:37:17] 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 then, 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.
[00:37:37] So those are a few tips, engaging your immediate team. And as you think about the rest of the ARG 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 leeway baked in with the assumption that, Hey, this team probably will only meet 50 percent of their goals, or they will probably sunset more products than they launch.
[00:38:11] So you want to be able to set those expectations up front with your leaders, the leaders of the org, and consistently continue to message that. 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 chartered on to take new bids that might even fail sometimes.
AI Zero to One Products and Key Insights
---
[00:38:44] Melissa: So Uday, you also have experience working with AI products. What is unique or challenging about doing 0 to 1 AI products these days?
[00:38:54] Uday: 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.
[00:39:18] 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 there's a lack of data and ensuring that you have enough data can be difficult. Good. 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.
[00:39:49] 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.
[00:40:08] The second thing, and this might not be unique to zero to one, 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.
[00:40:35] is something that can assuage some of those concerns. The other option is to consider human in the loop 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 is not hallucinating. Can you include like a workflow expert within the process?
[00:40:57] 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 is that a few like aspects to consider as you think about building 0 to 1 AI products.
Closing thoughts
---
[00:41:10] Melissa: Uday, you have so much knowledge on building these types of products. What are your biggest lessons learned as you have developed a lot of 0 to 1 products? And what would you recommend for product managers out there who want to build more of these?
[00:41:23] Uday: I think I have three high level takeaways that I want to share as you build 0 to 1 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.
[00:41:45] 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.
[00:42:09] So always try to map customer feedback back in the context in which it's, 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 the product.
[00:42:37] Melissa: Uday, thank you so much for being on the podcast. If people want to learn more about you, where can they go?
[00:42:43] Uday: You can find me on LinkedIn, Uday Maripalli, or hit me up on email, uday.marepalli@gmail.Com. A lot of thanks to the listeners out there who would absolutely love to ref on this space and continue discussions about product building in general.
[00:42:59] Melissa: Amazing. And we will put all of those links so that you can reach out to Udai on our blog at productthinkingpodcast.com. So make sure that you go over there and check out the show notes.
[00:43:08] 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.
[00:43:22] I'll answer them on the future episode. Thanks, and we'll see you next time.