Episode 116: Beyond the Basics: Non-Traditional Approaches to Product Management and Leadership w...

You have to align everyone with data and actual, you know, information rather than say, this is a cool idea. Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole, the systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perry.

Hello, and welcome to another episode of the Product Thinking Podcast. Today, we're going to talk about product management in some non-traditional senses. So, not pure SaaS. We're going to talk about physical products and products with services and all those complicated things. We're also going to talk about how to structure teams well and what good product leadership looks like. And I'm joined by Yasi Baiani, who is the Senior Vice President of Product and Marketing at Clio. So welcome, Yasi.

Hi, thanks for having me.

It's great to have you here. So can you tell us a little bit about your career as a product leader? You've worked at some really amazing companies, had a great journey over the past decade. How'd you get into product management and what are some of the things that you've done so far?

Yeah, absolutely. So, I kind of think of myself as a product and strategy leader, and how I stumbled upon product was, you know, non-traditional, I think, similar to maybe many different people. They all come from different backgrounds. I've been kind of leading different products and product teams in companies like Teladoc, Livongo, Fitbit, Athenahealth, and most recently at Clio, which has been really fun. And where it all started has been different. I became into product as an entrepreneur myself. So, I started a company while I was at business school at Harvard, which was the company that basically connected people for sports and sports activities, so they can find local activities or partners nearby. And that kind of was my first entry to the product and how you build and craft something for the end users, basically from nothing, how that discovery works, how you go out there and talk and realize what to build. And when eventually we decided to wrap up Active Pepper after a certain amount of growth, we still had like challenges to grow it in every location we wanted to launch. I kind of reflected back on that experience. And as a CEO founder, you wear a lot of different hats. And what I found, like when I reflected back on that, I'm like, what did I enjoy the most? Like sales process, partnerships, hiring and building an engineering team and product team, crafting a product itself. And really, a lot of the kind of R&D part of my role kind of stood out to me and really understanding and doing discovery around what people want. How do you find that product-market fit? How do you scale a product? That was what really resonated with me versus some of the kind of partnership and sales type of activities of the CEO and founder role. And that's how I kind of found my way into product and particularly health tech product. And from there, I never looked back. I love what I'm doing. A lot of it is kind of matching my personality and my skills. And I have had really fun building products that have been used by millions of people. So, it's been a really awesome journey.

What I really love about your career and what you've done as a product leader too, is that you have not worked primarily in SaaS. Like, you've jumped around to a bunch of different things. And on this podcast, we get asked a lot about unique situations where you've got products that are, you know, physical products. Like, how do we manage both software and hardware in the same company? things with services or, you know, not just pure SaaS. So, can you tell us a little bit about how your journey as a product leader has been different than those of typical SaaS product leaders?

Yeah, absolutely. I think one thing that kind of stood out in my career when I get gravitated towards companies is their mission. So, a lot of the companies I've joined have been really mission-oriented. And with that, a lot of times it comes that it has a, it has something beyond just a digital solution that they're offering. Most of the times these companies have service component, would it be the clinical teams and doctors or kind of experts and specialists? And also in terms of like Fitbit has been components of hardware and software. So always in my role as a product leader, I've been partnering up with the rest of the organization. You always do that, even in the SaaS company, you'll do that. But I think in a company that you have digital solution in addition to something else, it's even more important because a lot of times we think of our role In those types of companies, as basically chief experience officer, you're not only laying out the strategy and the product, but you're also laying out that end-to-end experience, all the people and constituencies that you're touching. For instance, when you're building a product for a company that has service component, not only your end user are your clients and who buy your product, you also have people who are end users and using the products. For instance, in terms of Teladoc, we had members who were using our product, we had clinical people and doctors who provide the services, and we have internal people who are enabling those things. So all of those are our constituencies, and we have to think about all of those people experiences and touchpoints. It's very similar at Clio. We have our guides and experts who are delivering services to our members. We have our members who are the end users, and we have amazing clients like Salesforce, Pepsi, and the rest of the, you know, amazing companies like Red Bull that they buy our product. So, that's kind of like how we think about that. It's like an end-to-end experience. And as a result, the product team and the product leader have to work exceptionally closely with operations team, with the clinical team, with the, of course, engineering. We always work super closely, but also with the, you know, in terms of Fitbit, for instance, working really closely with the hardware engineering team, not only the software experience team, but only hardware engineering team. And really think about how do you bring those products and experiences to the market. So, the touchpoints are broader, the surfaces are broader, and in order for you to deliver an amazing digital solution, you have to make sure that you have those really awesome kind of rest of the touchpoints. So, a lot of times myself and my team very much think about those experiences, we influence them, we'll shape them to make sure that, for instance, not only when members come to our digital solution at Clio and use our product, they have a great experience, we collect the right data from them so we can better serve them and surface the services we offer, but also how do our guides approach them? How do they work with the members? How do we have data float from our internal tools and what our guides are using, you know, with, with what the members will see and what member will receive? So, that's kind of the holistic experience, which is different, but it's also more challenging. You know, you have, it's not just a digital solution that you're looking at.

It's basically the whole business that you're impacting as So, as a product leader in those types of companies too, a lot of people ask me about structure and I'm curious both at, you know, the team level, but also at the executive level. When you have these different components, are they overseen by like one person to bring the whole experience together? Do you have multiple stakeholders? How do you typically set that up?

Yeah, that's a great question. And different companies do that, you know, differently. So, I think sometimes the chief product officer looking, overseeing multiple of these functions to make sure they all come together in a right way. So, it's like a still a very cohesive experience. We also seen it like in some companies, they have COOs looking at both operation and product. So that's another way to kind of set it up. There are companies that kind of set them up differently. You have the kind of chief product officer on one side, and you have the, you know, COO or the chief clinical officer on the other side, and they kind of, they work closely. So each of those kind of structure could work and it kind of trickled down depending on how you structure it, you know, it will be you know, different. What's really important is to make sure, like, either way, as you know, Amazon also famously talked about that you don't want your internal structure show up on the external experience. So, your end users should not know how you're internally structured and work. At the end of the day, these functions have to work so closely and so seamlessly that the end experience is very seamless and a solid experience for the ultimate users. So, kind of in terms of, like, how do we think about, you know, structure? So, a little bit depends also what talent you have in place. what kind of, you know, teams you have, how you wanted to kind of structure that. But the way I personally like to think about the structure of the team, and that's relevant both for product and design and other kinds of functions that I lead right now, at this point, I run a multidisciplinary team. And also, it's valid for how you organizationally structure, you know, the teams. I like to kind of think about this as like a COPA framework, which is basically Complementary skills among the team members we have. Would it be within the product and with their— or with their counterparts on the other side? Would it be the hardware team or the operations team to make sure, like, they have complementary experiences while everyone is still strong within their own area? So, C stands for COPA, like, C stands for complementary skills. Ownership of the OKRs. I like to structure the product team such that they can own the OKRs, so it's a lot more clear what initiatives they pick so that they can actually impact the kind of areas that they wanted to impact, rather than every time you have to decide about the initiative specifically, that empowers the team more. The P in COPA stands for process. I like to think of, like, it's not just about the structure of the team, but, like, how do you structure your processes around the team and/or structure your teams around your processes so that you actually have an effective product and development process? That's valid for partnership between product and engineering. It's valid around the processes within the product team, but also it's important around, like, what are the processes and touchpoints and communication between product team and the rest of the organization? And as you have this product experience more broadly, because it's a whole, you know, not only digital component, but also services component, those processes and touchpoints become so much more important to make sure everyone is moving, you know, in the right direction and Really hand in hand. And then the last piece is the alignment. Alignment of the product team and engineering team structure is really important because when you think about if you have Scrum team or if you have like different types of structures, how do you make sure you structure your team as independent as possible? I know some organizations have shared engineering resources, for instance. That's one model, but I'm personally like much rather to partner up with the head of engineering and structure our teams in a more independent Scrum, again, with the clear OKRs they own and they can impact, and really allow them to move fast. When you have shared resources, I've always seen it gets really complicated in terms of when someone moves from one project to another project, who owns what, who needs to be experts in what area. It just makes things so much more complicated, both from product and engineering perspective. So, I'm personally more a fan of independent teams. They can run faster and more I like this COPA framework.

I think that's a really neat way to think of it. So, you mentioned before too, when you don't organize correctly, you could see, or you don't work together, let's put it that way, you could see the internal organization on the outside of the product. For some of the companies and people listening to this, what are signs that your structure is impacting the way that people are doing your product? Like, what should they look out for? And go, oh, you know, I am observing these things. Maybe, you know, it's actually an internal structure that's not aligned correctly.

Yeah, 100%. There are multiple signs. One is product shipping with low quality. If you have a lot of bugs and issues, or you are getting into the kind of launch time and you realize, oh, we missed this thing, or, oh, this part of the group didn't do what we needed to. For instance, if you're launching a feature that has dependency on operations and operations cannot deliver at that time, either someone didn't communicate with them or didn't realize that. If you have this aha moment that things have to stop because something went wrong, you need to look and really identify what was the root cause of it. And a lot of it is like the, you know, the COPA framework, the process might be the problem, or the structure might be the problem. So, you really want to kind of diagnose and identify and fix that. But that's one area that you'll see that. A lot of times is when you see people finger-pointing, and it's not clear who owns what. So, your structure and your accountability and your RACI are not clear for the team. So, they think someone else owns it. They think that another one owns it. So, it's not clear who's owning what and who's the decision maker and who's the responsible and accountable person. So, getting that RACI and accountability right is so key. But if you see a lot of confusion around who needs to drive what, it's a moment to pause and say, okay, is our structure not correct? OKRs are not clear, our processes are not clear. So, that's another area. Another piece is, like, really slow development. If you have a lot of challenges shipping things, and you're constantly falling behind as an R&D team to deliver, it's most likely some version of process and structure issues that you have. So, really looking into that. And I always say, you know, a lot of CEOs or founders ask me, I wanted to hire the best head of product. How do I do that? How do I search for that? How do I always hire the best product managers? I always encourage them and give them all the clues on how to do that. But what's also important, product has so much dependency to other functions to do their area well. Otherwise, and that is particularly true with engineering, in an organization that you have services and hardware and other components of the product experience, they have so much more dependency to all those functions. So, it's not only enough to invest in product team or hire the best product people, because if they're not combined with the best engineering team and best processes, you still have the same fault. problems. You won't have the velocity you need. So, going back to your question, if I see that product team is always falling behind and they have issues with delivery or always behind in their roadmap, there's some version of either engineering team is not highly performing, and our R&D processes are not strong and solid, or our structure of the teams. And again, like RACI and those clarity around OKRs and who does what and how do we achieve those goals are contributing to that. So, like, 3 signs: product quality is not there. The second is a lot of confusion within the team, who does what. And the third piece is really falling behind in delivery.

So clear. And I think you were getting into one of the questions I had next, too, which is like, you're, you're an outstanding product leader. Let's say somebody wants to bring you onto their team. You mentioned, I'm looking for quality of the other teams as well. What are you also looking for in a leadership level? I know you mentioned that Many companies can structure, you know, services and products and the ownership of that by a leader in many different ways. But what have you seen work best that's going to— like, what— and even if it's not just one structure, what are the qualities that make each one of these structures actually work better in those organizations?

Yeah, absolutely. And I think it's a bit different in different stages of your career, what you're looking for and the type of impact you can have. Like, for instance, at this point in my career as an executive, I look into how product-focused the organization is, how R&D-focused the organization is, how much they're willing to invest in the R&D, even if there might be some other components like services that is critical part of the offering. So that's definitely something that's top of mind. Like, what's the role of the head of product? Like, and head of product, we all know it could be director level, it could be CPO level, but who's the, who's the driver and decision maker for the product? What's their role and where do they sit? What seats they have at the table? For instance, are they part of the executive team? Are they not part of the executive team? That also tells me how much impact you can have and how much, as an organization, you value product. So, that's another thing to think about. The other thing is the structure of the engineering team and/or operations team. Like, again, sometimes engineering team report to the CPO, sometimes product reports into the CTO. So, thinking about some of these structures, it tells you something about the view of the organization and how they build product. A lot of times, if the product is super technical, you may put the product team under tech. you know, CTO. If there are other components of experience and strategy, you put the rest of, you know, maybe teams under CPO. So, again, like, looking at those structures, it will be telling to you. Also, like, at this point in my career, given that I work very closely with CEOs and generally report to the CEOs, I look at the CEO's mindset. What kind of a CEO is this person? Is it, like, a clinically driven CEO? Is it a technology-driven CEO? Is it, like, a very much sales and marketing and, you know, commercial-driven CEO? And that will also tell you how much the CEO will be involved in the product decision and shaping that with you, or they won't. So, and then depending on what type of a product leader you are, that kind of impacts how, how you make your decision if this is the right fit for you or not. At a kind of director level or like early VP level career, it's a bit different. Like, you know, it's like, again, some of these things are coming into consideration, but it's a different structure. Generally, if it's a larger company, you're still reporting to a CPO or, you know, head of product. You may not directly report to the CEO, and also, like, structure of the teams might be different. But again, some of the same questions still are very much valid. Is this an organization, a product-driven organization? And then assess that based on if this is the right fit for you or not. And maybe you are also coming from operationally driven background or engineering-driven background, so maybe actually a very good fit. But it's a healthy type of question to ask to really understand what is the kind of nature of the product and company. And how does that match what you're bringing to the table? And then kind of make your decisions based on that.

Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past 7 years, I've been working with individuals, teams, and companies to upskill their product shops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations. Facilitation is a skill I see as a fundamental difference between good and great product managers, yet it's often overlooked. Great product managers focus on guiding clear conversations and steering stakeholders to the best You can develop these facilitation superpowers in Voltage Control's Facilitation Certification Program. Ready to unlock your greatness? Apply today at voltagecontrol.com/product. Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past 7 years, I've been working with individuals, teams, and companies to upskill their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations. When you were talking about the product vision piece too, I think that's really important. So we talked about how the CEO might be involved in it. Specifically for hardware and services companies, I've seen a lot of companies struggle with who owns the product vision, right? Like, if you're Fitbit, we take that as an example, like, what do you do for who's going to craft the outside and how's the software going to go on the inside? I've seen places where nobody talks to each other. It's like the hardware goes over there and the software goes over here. Like, how do you work together as a team and as leaders to make sure that everything is accounted for there, and the whole product is going to be successful.

Yeah, that's, that's really the art of product management, I think, and one of the hardest parts of the role, because you need to be so good in influencing everywhere in the company and shaping that. But also, it's not like you just say, oh, this is what I think, we should do this. Like, you really need to have data information to support your argument and vision, but also partner up and understand the constraints or strengths of other parts of the organization. So, I think at the beginning of my career, I kind of did that first at Fitbit, but I somewhat stumbled upon it. I was doing it, but not realizing that, oh, actually, this is my craft and way of doing product strategy. But when I look back at it, it became my way of doing strategy, and now I do it very systematically. And any, any company I advise or anything I do, I always approach it the same way to get the strategy right. And that's what I did at Clio. I think there are 4 components to make a product strategy successful, and if you approach it from that perspective, it allows you to really start building the organizational kind of alignment needed and have that end-to-end view of how to do it effectively. One is that, first of all, you want to involve multiple functions. The product strategy that is only crafted from the product team, it's a lot harder to get legs, you know, under it versus if you involve other teams. So, what I did when I came early on at Clio and we were trying to make some strategic decision, I asked our CEO that let's involve most teams. I don't want the product strategy just to be shaped from, you know, product team. And that's what we did. And we went through the 4 steps that I, you know, became my kind of way of, you know, leading to an effective product strategy definition. One is like collecting data internally. You know, if you're super early, you may not have data, but like most of the other companies have some level of data about the performance of their product, the performance of their business. So, making sure you get that. And also, one thing that's important around that is like also build some alignment with executives around what OKRs matter for the business. For instance, like in the environment we are now, Revenue is always important, but margins become so much more important. Like, maybe a year ago, margins for most of the businesses was not as important. Like, it was growth at all costs. But now that margin is important, so having a conversation with your executive and teams, is margin more important or engagement? Where do we put the money? So, build alignment. Not only just look at the existing data, but build some alignment on what OKRs matter for the business in this stage of the company in the next 6 to 12 months, and really try to use that as a kind of framework that helped define and craft this strategy. The second piece is be super customer obsessed. Get out there, talk to customers, talk to users. And, you know, for a lot of the products, you have multiple constituencies. For instance, for our case at Clio, we had our clients who purchase our product. They are, you know, end users. We have consultants who sell our product, so we talk to them. And we have our internal users, our guides and experts who deliver services to our members. So, we talked with all of them, understood cons and pros of our offerings, the need each of these constituents have, and brought that voice of customer to product strategy kind of enablement. The other piece is the competitive advantage of the company itself and what the other competitors are doing. Of course, no one knows what their competitors directionally are going, but try to have a sense of that, and more importantly, really deeply look into your own competitive advantage. When I was at Fitbit initially, we did some of this, and I spent a ton of time with our R&D team. And during that process, I realized we actually have a golden opportunity because it was the first time that we were able to track hardware— sorry, heart rate continuously on hardware products. Some of our other competitors falsely claimed they do that, but when we dug in deeper into their product, we realized actually it's a false claim. They actually do not have that technology. So, and I knew that that's foundation for getting a good sleep stage in place. So we use that to build more and more and give more, you know, wind behind our sleep strategy. We said, okay, if we do sleep, and we can track sleep stages, and we can show all this information, we can show sleep score, and we can give them sleep insights that are actionable, that all makes sense. And we are the only one who can do that. No one else has got into continuous heart rate tracking. So, again, understanding what do you have as an asset in the company that really is your moat, your competitive moat, and what other competitors have, and decide your kind of strategic direction. And then, the last piece is really— and part of that competitive analysis, when you do that, you also do market trend analysis, the consumer trend analysis. So, you collect all the competitive and market information, plus your own competitive advantage information. And the last piece is really stakeholders interview. Really understand, because CEO may want to go certain directions, COO might want to go different direction. Really understand how do everyone see the growth of the company, and what is their vision, and really try to align that with all the other information you crafted. So, that, I eventually, I've done it at Fitbit with sleep. I've done it with female, you know, health expansion, which initially, we had a lot of challenges. We wanted to get into that sector, but a lot of our executives were male, so they didn't realize, like, what's the benefit of having female health tracking and fertility tracking information on your app? It just doesn't make any sense. We collected data, we said, first of all, 52% of our users are at that point women. Second of all, they all want to come to one app to manage all of their health, not just go to different fertility tracking products, or cycle tracking products. And with all the work we've done, we proved that. And what happened is when we, we got a lot of initial hesitations around getting into that, you know, area. And to your point, like, Our head of marketing was also a woman, so she and I partnered up. We did a lot of user research, market research. We collected all the information. Ultimately, we were able to convince our head of product at that point and CEO and the rest of the group. So, we put engineering effort behind it. We built the product, and within the first month that we launched it, we had over 2 million people using the capability, which was really awesome. So, basically, doing all this work and combining these different types of information together will allow you to come up with a strategy that everyone can understand, get behind it. It's not because just, I thought this is a cool idea. This is a cool idea, but market supports it, data supports it, internal view supports it. Then, it makes it easier to kind of build alignment. And ultimately, it's all about executing the strategy too because you can go— we go direction A, but there's a lot of craft of how do you bring the product experience? What's the design of that? What nudges you have? So, there's a lot more still to be done to make that a great product and experience that will have adoption. But that strategic alignment and North Star, that is one of the most important things that any head of product can put in place, is so critical to then allow everyone to kind of move fast in the next phases and next stages, rather than constantly having debate and discussion that if this makes sense or it doesn't.

That's such a good case, too, for having more women on your leadership team, especially if half of your customers are women. It's like, hey, we found this thing that 2 million people We'll use immediately. Maybe we should look into it. I love that. That's such a great story. So Fitbit might be a good example to dig into this. When you uncover the different things, like, for example, with sleep, you were mentioning that you looked into the data and found out that their trackers could not actually do heart rate continuously, and you could. Was that something that already existed in your hardware, or was it something that you had to partner with your— hardware team to say, like, hey, is this a capability we can actually do? And what does that look like when you're coming up with this new idea? And I know testing cadences for software is very different than testing cadences for hardware. How do you work together on those things when you have different types of release cycles or different types of ways of building things?

Absolutely. I think at that point when I joined Fitbit, they were in the early phases of getting that hardware, continuous hardware, tracking on the hardware product. I would say it was more at the beta or prototype phase. But I spent a lot of time with R&D team, like probably so much with them. Like, we were kind of hip attached, spending so much time together. Because one thing was important, like the kind of moats of Fitbit was the sensors, was the hardware. So, and even though I was responsible for bringing software experiences to the product, at the end of the day, I knew that For me to bring the best and most unique experiences to the product, I need to really utilize the sensors. And eventually, as my role kind of got expanded, I would impact some of those decisions to make sure we have the right sensors in the right product with the right cycle, so we all build the right things. Because, as you probably know, the lifecycle of product development for hardware is really, you know, long. Like, generally, 18 months before anything, you decide, and pretty much your PRD gets locked down, and you know what sensors are in the product, the look and feel of the product. Software still has some cycles to provide the experiences, but in order for us to launch any hardware product, we needed to know what are the marquee features and experiences that's going to sell the product, what is new in this product, and how my team is going to enable that. So, it was like a super close partnership between our R&D team, between our engineering team, our marketing team to bring some of that market and voice of the customer to our teams. But I spent a lot of time with the R&D team to kind of— a lot of times, we would kind of ideate stuff together. They would go hack some stuff and build them beyond just sleep, but around our mindfulness, about our breathing capability that we brought to the product. We had breathing app. But in order for you to track all of that, we needed to kind of test product and prototype, and then eventually bring them to actual productization. But it was like a hand-in-hand collaboration and ideation to kind of enable some of those from early on. And I think communication was key, and kind of everyone had that mindset that we are in it together, and every function is successful if you do it right. Product was leading a lot of, like, what are the opportunities? What are the things we think we can sell, and it's appealing to consumer, and all that, and how do we enable the experience? R&D will bring their expertise of prototyping and what's technologically possible. So, a lot of their kind of research team brought that capability to the team. And then, with the marketing, like, go-to-market strategy, and how do we tell the stories, and all that stuff. So, we had some really cool, you know, case studies. One of the other examples, like, pretty early on in my time at Fitbit, we were thinking about, you know, again, we were looking at data, we were thinking about multiple capabilities we wanted to bring to the market. And at that point, there was a lot of coverage around sitting is the new smoking. So, and we were looking at our data, and we were like, Actually, despite the fact that people think people who— early adopters of Fitbit are fitness junkies, and they're always moving, and they're always doing activities, they were not, actually. Even the ones that they do, they do work out in the morning. They sit, like the rest of us who work, in front of their computers for really long boats of hours. And then, they maybe do, again, activities. Some of them will do activities in the evening. But during the day, majority of our users are actually pretty sedentary. And we also looked at some research and showed that if you have movements every 30 minutes, you break your cycle, your metabolism. increase, you reduce your risk of cardiovascular diseases. So, the science and literature support that getting people to move is actually really beneficiary for them. Our data also supported the fact that our user base can benefit from that, not only a small group, but a large group of our users can actually benefit from this. But, initially, our head of product and our CEO were concerned about that. They're like, this is not aligned with Fitbit's brand. We kind of stand for a lot of activities and stuff. Like, we remind people to move. It kind of feels like off track from the brand. But they still gave us opportunity to do prototyping and test that. So, what we did, I remember, it was early days at Fabi, so I was packaging prototypes and stuff and send it to a bunch of users. We recruited people, we crafted a survey, we had multiple versions of the prototype that we built, and we sent out to end users. And what we learned after 2 months of testing, first of all, one of our designs really was promising, which was 10 minutes to the hour remind people. Both qualitative and quantitative information came really strong in terms of, yes, I will use this. It was a— we were also seeing some qualitative fun information that people were saying, this was a great excuse that I walk out of a meeting and say, I have to go get my 250 steps. Or, I walked out of a boring conversation with my wife. This was the best thing you guys built. So there was some fun stuff like this. But also, there was a lot of really meaningful information that people actually reacted to this because it was always 10 minutes to the hour. It was always something that they now know, OK, I have to do my workout— sorry, my walk. So, they, you know, we structured in a way that both from design of experience on the hardware and design of experience on the visual components, it actually resonated. And we realized, based on various prototyping we did, some of the visualization didn't work. For instance, one of our designs were actually, as you were sitting, you were accumulating, you know, lines, like line will go higher and higher, and then it became a really sharp, pointy visual design, and people didn't like that. They're like, that scares me. But, in a visual design on the app, we actually show them stars. Every time you move and you react to what we tell you to do, we give you a star. They love that. And we kind of timeframe it within hours of, you know, clock design. So, that really resonated. Anyway, so, what I'm trying to say is a lot of testing and validation. And after we show the result, 98% of people say they will use this feature. And our actual data from prototypes show that people reacted to that, and we were able to break down very long sedentary time for our users to very short period of sedentary time. So, that was the best behavioral change, you know, feature we had. And after our CEO and head of product saw that, they were like, 100%, we should not only build this for our, you know, product that we target towards more sedentary people, but we have to put it on all of our products. So, it became a must-have feature for all products. And when we launched it, it got a lot of traction and was one of those features that we sold to our corporate arm. But the point I'm trying to make is you have to to align everyone with data and actual, you know, information rather than say, this is a cool idea.

Yeah, that's a really good lesson. I love that story. And now I know why my watch keeps yelling at me to stand up all the time. So you guys were the reason behind that. Love it. So you've had all of these different experiences at these, you know, really great companies working on so many different types of products. What are the most valuable lessons that you've learned from leading product over the last decade?

Yeah, absolutely. I think one thing is really, to the point I was mentioning earlier, the product function is really— and building great product is teamwork. It's very much like a team sport. You need to have all the players doing their job well, and they need to all be strong at what they're doing in order for the product to be an outstanding product that has, for instance, millions of users like we had with Fitbit. So, you need to have not only strong product team with all the right structures and processes in place, but your engineering team, your data team, your marketing team, everyone needs to be strong, but also do their job well, and do it on time for everything to kind of fall as you expect. So, that's the biggest thing. That's why I spend so much of my time at this point in my career, not only just with my own team, but like, organizationally, to make sure that we have the right structure in place, we have the right parties in place, and everyone kind of like orchestrate, like work very, you know, coordinatedly with each other. So, that's one thing. The other piece is, like, really building great products that get adopted by millions of people requires a lot of iteration, a lot of things. It's not that easy. Like, that's why, like, not every company will get to that scale. And that's why the prototyping mentality, the test-and-learn, you know, mentality, all that is so critical. Like, you know, even a decade ago, we didn't have as much opportunities to do prototyping with you know, design tools. Now, with Figma and other tools, like, you can do a lot of prototyping and testing and get user feedback without doing any coding. So, I really encourage, and I think that's a key part of successful teams, they do a lot of that and get feedback and really make sure by the time they build something, they have so much confidence in that, that it will be a success. So, I think that is really key, building that mentality in the team. And I think one thing about product team themselves, and PMs, and product leader, one skill I feel like more and more became critical for me is communication. And the communication has multiple facets. One is, first of all, the art of storytelling. It's not just also you're going to have a big stage and tell a story about your product launch, but it's also like, how do you tell story in every setup? When you're telling your engineers why you have to do this feature versus something else, or why you should You know, go direction X versus Y. That art of storytelling that every PM should be expert in is so critical. The other piece is like timely communication. And one thing that I always emphasize with my team is order of operation. Who do you need to inform and in what order? And what do they need to know? The order of operation, I think, is so critical because if you just blast a, you know, big email to everyone, including your boss and CEO and your cross-functional team and say a product is delayed, You can imagine what that is, one kind of communication. But if you go to all the right parties, like, make sure you let your manager know first, and tell them why and explain to them, then, you know, your engineering cabinet, like, kind of go through that operation, order of operation and communicate effectively, can change what the message is, or what the message, how the message is received. So, it's really critical, that art of communication. And also, like, I think the organizational structure around the team is really critical to make sure that, you know, head of engineering, head of product, like, the rest of the The leadership have the right structure for the team. It's not just like expect the team to continue to deliver. It's how you have this right structure and how you evolve your structure as the company evolves. It's really important. You can't stay constant with your processes. They always have to evolve.

Definitely some great tips to listen to. And the one thing I really want to call out is that I love that you said we got to be testing and learning even without coding, because I do think that's really important. And I've had so many people over the years ask me like, Hey, well, we've got a complicated product, or we have hardware, or we have this. How could we possibly test and learn without, you know, building things? It's not as simple, but if even Fitbit's doing it, then these people can do it too. So, I really love that story. When you are thinking too, like, what's the difference between a good product leader and a really great product leader? What have you observed to be that, like, those defining key traits?

Yeah, absolutely. I really focus on kind of what in my mind is an outstanding product leader. First of all, really is obsessed with customer, really focused, like rather than being competitor obsessed, or CEO obsessed, or internal, you know, focus, really, really ingrain themselves and their team into the customer's voice. So kind of have a lot of touchpoints, bring that to the team and build a, build a customer obsessed team. There is nothing more valuable for the product team than voice of customer and really understanding what problem you're solving, because that then gives you opportunity to be creative and then solve them most effectively. So, that's one thing. As a product leader, particularly, I think it's important to be process-oriented because all the reasons, like we touched on process multiple times, is one component of making a successful product is having good processes in place. So, as an outstanding product leader can kind of come back and review the processes, diagnose issues, and then kind of fix them and improve them, you know, with the rest of the counterparts. The other piece is, like, data and analytics is another kind of really key component. I would say being data obsessed as well, and really looking at the performance. And that also is kind of tied to making sure they build a team and guide the team to be, you know, outcome-focused rather than output-focused. It's not just about shipping something or shipping a feature or doing whatever everyone else asks us. It's more about, like, okay, what does that thing— what is the outcome of that thing? Why do we do that? And is that the right thing to do versus something else? That's something that I think really makes the outstanding product leader and kind of ingraining that culture within the team. And power of influence. You know, we talked about, like, you know, in my career, I've been able to, multiple times, significantly sway and change the perspective of, you know, senior leadership and executives. And how did I do that? It was really by power of influence. But what gave me the power of influence is data research, you know, information to collect. So I think great product leaders really have that capability and can sway everyone else's, you know, mindset to the right direction using the right tools. And we talked about this communication, art of storytelling, effective and timely communication is really key. And also the strategic view, which I think honestly, any PM— I asked my team, everyone within our team should think strategically. That's like a key component of any great product leader or PM, it's not just do the thing they ask, but think about like, how does that tie to the larger business, which then with that, it comes that for PMs, it's essential to understand the overall business. It's not just a slice that they're in, you know, outstanding product people within each level, they understand as much of the business holistically versus just one slice of it. And that allows them to make the best product decisions that really serve the business and has the outcome impact that we all want.

Great things for people to really develop to become exceptional product leaders. Thank you so much, Yasi, for being on the podcast with us today. If people want to learn more about you or your work or follow anything that you write, where can they get in touch with you?

Yeah, absolutely. They can follow me on LinkedIn, Yasi Baiani, and on Twitter, @Yasaman.

Great. Well, thank you so much for being with us today. It's been awesome learning about all of your stories. I had a really good time hearing about Especially Fitbit Sleep and, and the women's part of Fitbit too. I thought that was really cool. For those of you listening, Product Thinking Podcast comes out every Wednesday, so make sure that you subscribe so you never miss another episode. And next week we're going to have another Dear Melissa where I'm answering all of your questions about product management. So please go to dearmelissa.com, let me know what questions you have, and we'll see you next time. Bye.