 Hello, and welcome to today's webinar on building and managing system products. My name is Nitsh Chakranathan, and I'm a Senior Product Manager at AWS. Before we dive into today's topic on system product and what it is, I wanted to kind of give a background about my experience as a product manager and how my career transition happened from an engineer to a product manager. So my progression has been pretty straightforward from engineering to a PM, but it has been a slow one, and mainly because I was not clear exactly what I wanted to be doing early on in my career, and I think gained more experience. It was, you know, it became apparent that product manager is the right fit for me. So I started out as a software engineer in the probe in 2004. And, you know, I was usually writing CC++ code as for drivers on the network systems for telco companies. And then I felt that, like, you know, I needed to gain more expertise in the side of systems engineering. So I came from a master's in electrical engineering from the University of Kentucky. And right out of college, I joined Intel Labs as a system researcher, focusing on next-generation platforms and, you know, like mostly research on power management architecture and system design. One of the things I realized, I spent over five years in Intel Labs, and the thing I realized during that time is that the R&D cycle, it's pretty long. Like, one of the inventions from, you know, early on in my career, 2009, made it into laptops in 2013. And I felt that that was a too long of a time to make an impact. And so I wanted to be closer to the product. So I moved, I became a product architect for laptop and desktop team for a while. And I kind of gained different perspectives on, like, all the other elements that go along with building a product. And I felt that, like, you know, I only, at that time, I became aware of product manager as a role. And I started transitioning towards product manager, like, about five years after I became a product architect. And when I left Intel, I was the lead product manager for the smart home team. A couple of products that you see below the Intel speech kit, and the deep lens was part of the effort. And I joined AWS in 2019 as a product manager. And I'm currently the Snow Service team. And the Snow Service product, as you see down below, are regularized edge computing boxes where you can run cloud workloads at the disconnected and the regular edge. So our team is always hiring and looking for talent. If this is a domain that you are interested in, you know, always feel free to reach out to me on LinkedIn and would love to talk to you. Now, one of the things I wanted to point out is, like, when I started, we didn't have, you know, the same amount of resources on what is product management and what you need to be doing and skills that you need to acquire. But now with facilities such as product school, you have a lot more information at disposal and that made use of that, you know, like, that's of an interest to you. All right, today, we're going to be talking about system products, what they are, how do you plan for it, and, you know, how do you get approval and things that you need to focus on during the development phase, sustaining and, like, you know, after you launch the product, what are the steps that you need to do to sustain it and finally we'll bring it out together with some key learnings. Okay, let's start with the primer, right? What's a system product for the sake of this particular conversation and then there's taking from there. For sake of this particular webinar, a system product is anything that has an electronic component in it. For instance, a smart lock, a smart coffee maker, a smart car, anything that has a word smart in it has an electronic component of some sort. So it is an assistant product. So for instance, like, if you take a smart lock, it's got like, you know, embedded systems in it, it has to have Bluetooth and like a security mechanism to ensure your application communicates to it securely and you can unlock it, right? So all of that requires coordination between hardware, software, firmware, and application. And so that makes it a complex system product to manage. So what's unique about a system product, right? I don't always agree with Dwight, but in this case he's right. With respect to a system product, because pivoting to something else from its original design is very hard, you have to be successful with that first attempt, right? So for instance, like Slack started out as a gaming platform and it became an enterprise messaging platform, you cannot do that with a system product more often than not, right? A coffee maker will always stay a coffee maker and no matter what smartness you add to it, you know, you cannot change it to something else. So you have to be very clear as a PM that like the product that you're building is meeting the customer's needs and it is being operated in its primary form of use. All right. Other things to consider, usually anything that has hardware in it, you know, it's a long development cycle. We are talking that, you know, one year is an aggressive timeline usually takes longer than one year because you have, you know, the hardware team has to go scope out what the architecture is, go through multiple iterations and things like that. So there is another key difference when compared to a software product is that like, you know, software product is built in an iterative manner and you have mechanisms to like, you know, release it periodically, alpha, beta, and you can test out with MVP with the customers and iterate. So you are showing progress along the way that you are continuous, continually, you know, heading towards the goal. With respect to hardware product, right, you are a system product in this case, you don't actually deliver anything to the customer until it is finally ready. So it might mean up to a year or a year and a half of no deliverables to the customer. And so that makes it a little harder from a PM point of view that you have to keep communicating with both management level as well as with the rest of the teams and where you are progressing, what the blockers are, what your current goal post is. So the communication is key from a PM point of view. And another thing is that like, you know, system teams are usually multidisciplinary. And it is by nature, you know, usually a larger team because you have to consider multiple software hardware and former teams. And then you have to consider mechanical, industrial design, packaging, legal, accounting, and then like, you know, thermal teams are to be involved. And finally, like user experience, which ties in a lot of those things together. So from a management point of view, because you have multiple stakeholders, all of the streams needs to be managed, and any blockers needs to be mitigated. This brings to the point to the left that via any system product development is going to require a large upfront capital expense. You have to put in millions of dollars to your ODM. First of all, the ODMs have agreed to build it. And you have to have the timeline that matches with their plans. And then you also have to pay money to make sure that they have the assembly line free. And you have to pay for the labor and packaging, testing, compliance, all of that requirement. So you have to show the value proposition that like building this product is going to provide much larger, you know, monetary gain to the organization than otherwise, which is why like system products are almost always a core competency for a particular company. If a company is not used to building system products, you know, like getting and venturing into a system product, you know, area is always challenging. As you may have surmised, right, iterative development on the system level is going to be hard. For instance, let's take a car. So when a car, you know, goes out on the parking lot, it needs to have the minimum set of capabilities from a system point of view. There are value added services, like, you know, or you can change the audio firmware, like, you know, for instance, the camera firmware and stuff like that. But the core foundational specifications of the car needs to be there the first time it rolls out. But you do have the, you know, ability to iterate over generations. For instance, we consider the first iPod. It had those, you know, like being that you had, it had no display, and it was, you know, it was quite bulky. And over a period of years, you know, they added, they are, you know, Apple added an LCD screen, a touch screen, it had the ability to zoom in, they added Bluetooth. And finally, when it ended up in iPod touch, it was almost similar to, you know, like a smartphone and capability. So you can always iterate and improve your product over like many generations. But each one of those generations, like, you know, you have certain constraints that you have to adhere to. So finally, so we, all those constraints, you know, considering all of those constraints that I mentioned, why are we building the system products then? Right? It's because if you look at the physical manifestation of all the, you know, products that are around us, almost all of them are evolving into some kind of a smarter device. Your refrigerators are becoming smarter, your microwave oven is smarter now, like, you know, so are like washing machines and all the ones which are physically, just physical mechanical things are now becoming electronic components. The reason for doing that is that, you know, you're, you're bringing in more value, and they are all networked and it simplifies customers experience of managing them and, you know, building, you know, building those brand loyalty. For instance, if you're building, you know, like a computer platform, customers keep that for like about four to five years, and it started to push towards six years. During those six years, you have the customer's mindset, you can sell additional services on top, and they have more familiar with your ecosystem. And as you start adding more services, you know, your wall, your, your solution becomes a walled garden and customer continues to look for that same kind of, you know, platform again and again, like, for instance, between the Windows ecosystem, the Apple ecosystem and the Android ecosystem, you can see that people who are more familiar with a certain ecosystem continue to look out for the same kind of products. Right. So that builds a lasting brand loyalty and also it builds a more customer's data once it is in a specific, you know, like a walled garden, they don't want to move on. So I think having that platform keeps the customer engaged for a long period of time. So then now you can start focusing on how do I bring in more value so that like customers stay in that and you can extract most mileage out of the customers, you know, like mind share. All right. So we have, we have talked about some of the uniqueness of the system product side. Now we are going to be talking about like how, how do you plan for these products? What are, so that like, you know, you can have the right set of metrics that you can convince the leadership that investing on it is the right idea. A system product at high level has like, you know, three layers, right? You have the services and you have the system software, which includes the OS kernels, drivers, the firmware, the buyers, the EC that's on a platform and then the hardware itself. Right. So each of them have different levels of iterations possible. Like hardware has the lowest level of iteration and it starts very early. So you have to, you know, set the specifications to maybe you start with the very high level specifications and then you quickly narrow down to the key elements that you need. For instance, whether you need Wi-Fi, Bluetooth, other radios and, you know, like things like that needs to be settled so early on so that you can set the appropriate system software. Right. And system software, you do have the ability to iterate a little bit more. You, for instance, you might have started out with Ubuntu 18 as your initial launching OS, but by the time it gets towards the launch, you can potentially say like, I'm going to move to 20 because it's got the latest security features. It supports Python 3, for instance and stuff like that. On the services layer, you have a lot more degrees of freedom. You can iterate a lot more, you know, you can launch a product and as long as there is a mechanism to update your firmware and system software and services, you can always push over the air updates. So thinking about this in different, you know, different layers and where you can iterate more and where you cannot helps you plan for it depending on which planning cycle you are. Early on, I focus more on hardware and setting the right specs and then system software next and then the services the last. All right. The product planning for a system product is very similar to that of a software system as well. I think there are just a few things to take into account is that because it's a, you know, a physical product, you will have to put something in front of the customer that is a representative of your final product and then get feedback from there. And you have very smaller number of iterations here because your hardware team needs to finalize all the mechanical and industrial and thermal needs. So you don't have the luxury of continuously gathering feedback. Like for instance, like, you know, continuous discovery, which Teres Atores is talking about, you don't have that capability with respect to a system product. For a competitive lens, here it's more a strategic element, right? You're always, almost always customer centric, but you also keep an eye on the competitive lens and help saw, you know, set some of the baselines easily. For instance, if you have a product and there is a, you know, like a comparative product in the market, you don't need to validate every single element. You can kind of like know what customers are familiar with and set those baseline specifications, which might include the CPU, the memory, you know, like the form factor size and things like that. And then you can focus on the core, you know, like areas that are important to you. And that differentiates your product as well. So, you know, spending more time on things that are differentiating to your product is more valuable to you than trying to focus on things that are not differentiated. And the one other piece, which is very critical to a system product compared to a software one is the customer commitment, right? Because you're asking for upfront capital, your leadership needs to see that where does this product run in the market. So you have to go talk to your customers, identify your segments, where are your key customers personas and see whether you can actually like get customers to pay for them, essentially with the MOUs or whether it's purchase orders from large retail places like Costco or Target. So having those kind of, you know, like purchase orders, agreements of some kind, almost always justifies the need to invest money upfront, right? I touched upon the user testing a little in the previous slide. So essentially, our life has gotten much easier with the 3D printing capability. So in the past, you almost always had a form or a cardboard mockup of your particular product. And the interaction with it was not exactly like, you know, matching. And so what you can do now is you can print out 3D print your form factor in multiple different shapes, different screen sizes, for instance, and get an accurate feedback from customers, look and feel the weight. Does it match with the customer's estimation? And you can, you know, you can estimate that into your final specification. I think the key point, as I mentioned before, is that you do not have too many iterations at this. So you can do potentially like one or two or three cycles, maybe. But you don't, you cannot do this throughout the life of your product. You have to do this early on in the planning phase, so that like, you know, your specifications are set, your dimensions are set, so that the mechanical team, the industrial design team, and the user experience team, all of them know what they are expecting and start working on the actual implementation of it. And the competitive lens is also another thing we talked about. Like, for instance, if you are a PM for the first-generation iPhone, you don't actually go and like validate all the basic requirements, right? You can look at your competitive product, in this case an N95 series. They have a color display, they have a front facing camera, and then they had LED for like brighter pictures and a central button to manage your calls. They potentially had touch, but it was more resistive touch than capacitor touch. But I think that is the key point is that you can, you know, the basic call quality requirements that was expected, the battery life, you know, the durability of the product. So you can try to, you know, like collect all of those metrics and add your system spec very easily. And that frees up the time for you to go focus on the value added piece, in this case, for an iPhone, essentially the app ecosystem and the usability of the product. Right. So once you have, you know, time is a precious resource for PMs as for everybody else. So focusing on the right elements with respect to your system product is going to be the key. Don't waste time, you know, trying to reinvent the wheel on things that you can easily collect from the marketplace. Focus on the things where the marketplace is not giving you that feedback. So this is a very critical piece for system product and it's becoming more and more apparent to me by looking at, you know, our current list of offerings everywhere is that you need to add value added services onto your product. Think of your product as a platform and which stays with the customer for a long period of time. And like if you can add value added services on top of your product, you have the ability to increase your overall net margin for the product as a whole. And it also helps de-risk your hardware development cost. For instance, like consider this coffee maker, right? A Curie coffee maker usually sits on your kitchen. It does its job of like, you know, brewing coffee for you every day. But and now if you add a service of a smart auto delivery of like, you know, different flavored coffee cups to you, you're first, you're adding more value to the customer. No customer is like, you know, has a better experience using your product. But and on from your point of view, you are actually bringing in more revenue to your overall business line. And because your service product always has, you know, better margins than a system product, your overall net margin improves. Another case, since the case point is that, you know, Apple, for instance, they have like multiple ecosystem of physical products, Mac, you know, the Mac for iPhones and the smartwatches. And their services line, which includes the iTunes and like, you know, the app ecosystem brings in about 20% of the revenue that 20% with high margins actually helps them subsidize their, you know, hardware manufacturing and helps them maintain the high bar with respect to the, you know, physical device manufacturing. So almost always think about any value-added services that you can bring to the customer onto your platform. But now you're completed the product planning, and you've got enough fuel from your leadership. And, you know, from a PM point of view, this is a critical phase where you have to actually put them all together and make sure that it works as per your plan. From a product development point of view, you have to manage multiple streams because system products, as I mentioned, is a multidisciplinary effort. And it's a long period of time to manage that. And so from, I remember one point when I was managing a system product, there were like 20 different work streams. Like imagine in a software side, you have the OS, you have the driver team, and then you have the SDK, and you have the applications layer and services teams that you have to interact with. And you have the hardware team, the firmware, buyers, EC. So you can imagine like 2025 streams that you have to, you know, continuously keep track. The key element that you have to focus on is that like, you know, you start with a developer platform, dev board of some kind. And then you use the EVT, which is the eval kit where all the hardware software firmware comes together, do some initial testing. And then the DVT comes in, which is a developer platform, which has all the developer extensions to it. And then finally, the PVT is a representation of your final product. And this is where you integrate all your base software hardware and firmware are making working together. And, you know, if any issues are uncovered at this stage, you have to go back and go fix them. Because after this point, any change to your hardware or system is actually going to be very expensive. So PVT exit is going to be a key milestone for you to track. And you will have, you know, other stuff like mechanical thermals, compliance, packaging. So that is, you can imagine like 15, 20 streams easily. And from when I was managing, you know, like system products like this, usually you run like a weekly or a bi-weekly cadence meeting with different stakeholders and identify potential blockers and, you know, identify different mitigation steps. And you also need to communicate to leadership where you are progressing along your path. And that's going to be the key because your team needs that visibility on where you're going and how we are doing. And so does your leadership. And because you don't have any, you know, like customer-facing deliverable for at least a year, you have to do this proactively. All right. So I wanted to touch upon compliance because it's a little bit, you know, it goes under the radar, but it has an impact on your schedule and your planning. You cannot ship a device into a country without getting compliance advocates from that. If it's a system product, all electronic components needs to be fully tested. And the reason for doing that is that like, you know, our devices are fundamentally noisy with respect to magnetic radiation. And we are ready, you know, all the devices are radiating energy and they have to be within a specification so that like you don't cause physical harm to somebody who has a, let's say for instance, a heart maker and like too much interference, you know, interferes with that device. Sorry, pacemaker. So essentially like, you know, USA has the FCC. Without getting FCC's compliance, you will not be able to ship a product to USA, a production plant. Same thing for Canada, CE from for European Union, and that's a different ballgame altogether. Japan requires that like you have to do the testing in their country, using their lab, right? And those are just the compliance for electromagnetic interference. But then there is the safety standards, which is the UL to make sure that you're not using unsafe chemicals on your product. And ROHA has to ensure that you're not using products that are fundamentally damaging to the environment. So almost always, you will be using a third party for this third party who specializes in compliance and they take your product run through compliance. And the big issue is that if they do identify a potential issue, you have to go back and like, you know, come back with steps to mitigate it. Like in case like, if you ever wondered what this big cylindrical blob that is attached to your wire, those are called ferrite chokes. And their primary purpose is to reduce high frequency noise on the cables. So think of your cables as giant antennas that's radiating all electromagnetic signals. So you add these ferrite chokes to attenuate those signals so that like your system is compliant. Any system that you are sending a, you know, a system that has a charger, a battery, your compliance complications have increased significantly. So you need to plan for it from the beginning. This is not something that you can add on to your product later on. Compliance needs to be far most if you're actually like launching a product anywhere. Another element is the packaging side. You know, usually we don't talk about it, but all of us experience this on a, you know, like a regular basis. And this has an impact on customers experience, because this is the first thing they get to encounter. And it also is a passionate effort of mine is like, you know, to be need to reduce single use plastic in our packaging, because it grinds my gears. For instance, on the right hand side, like the Lego pieces, there are like a zillion single use plastic bags where you put like another small plastic parts in there. And immediately after you open the packaging, you discard all of those plastic and they end up in a landfill. On the other hand, like, you know, look at the iPad, the seven generation iPad, which are recently bought, they had, I counted like one single use plastic that was around the charger, everything else was cardboard or recyclable parts. And no matter how nice of a finish it is, you're still going to throw away the packaging. So I would say like us PMs, we have to raise the bar on ecologically sound and sensitive, you know, like product packaging for us. Of course, anytime you go into like, you know, non plastic related packaging mechanisms, it almost always adds cost, right? But then, you know, there are there are other avenues for recuperating that than, you know, using single use plastics that are potentially damaging to the environment. Okay. So finally, you know, you have done with the development, it's been a year and a half since you started it, you got the approval, you have provided all the updates to the leadership, your product is ready to go to the market, right? So what we think, what everyone thinks we do versus what we really do will be totally different. Because at the time of launch, you know, you have to make sure that like the customers are able to order the devices on the day of the launch. And your key customers have prior access with respect to private previews or betas, so that you get, you know, early feedback on how your product is doing and anything that you can fix, you can focus on fixing them. So not just with on the day of the launch, you will have to coordinate with the event coordinators, the product marketing, the sales team, so that like all your funnel is primed. So it's a lot of activity from a PM point of view. The main one is that like you have to tell your manufacturers how many devices that you need at the day of the launch and where they are going to be stored so that like if anybody is ordering, you know, on the day of the launch, they look at your announcement, you have to make sure that they can get a device. Because you want to, you want to get early adopters devices and then they can use that to spread word of the mouth, good media coverage and all of that. And you have to plan this months in advance. You start with the launch date, work backwards, and identify how much lead time it is to manufacture a part and then like, you know, work with the ODMs, give them the appropriate amount of manufacturing guidance and, you know, like essentially making sure that the entire process is tracked. As you can imagine, you have to do all of this while you are planning a product development with multiple things that you are tracking, things can fall through the crack. So almost always, you know, planning for product launch ahead of time is going to make sure that you have a successful launch. While the product launch and development phase is almost, you know, it feels rewarding on the day of the launch, it almost feels like you have a big accomplishment from your point of view as well as the team's point of view. The sustaining of a product and scaling it with customers is a lot harder and it is also like, you know, it goes on for years. As a PM, our job is to kind of look into our crystal ball and estimate how much, how the product is going to be doing in the market. You have a certain estimates on how many customers are going to be buying at the day of the launch, one month in, three months in, you know, like 12 months in, and you have to give those numbers to your manufacturing partners and also be a logistics team because they have to store these devices and they have to ship them to the customer. And so if you are wrong in either direction, there is implications. Like for instance, like let's say you project like 50,000 units on the day of the launch and all of a sudden there is 100,000 customers who want to buy it, you can only fill 50,000 orders and then the remaining 50,000 customers where they will have to wait till new parts can be manufactured, which is a good problem to have. But except for the current circumstances where like the lead time to procure silicon components is like up to two years these days, like there are entire automobile factories who are not running because there are no silicon parts, right? So meaning your 50,000 customers who are, who placed order on the launch day, they might actually have to wait up to a year, depending on which product that you are building. So this has made life as a product manager very hard. So if you are wrong in one side, you will completely lose customer like mind share because they will not wait for a year or maybe even two years for that this. And the flip side to that is that if you are overly optimistic and customer demand is not there, you have this volume of inventory that is sitting in your warehouse and depreciating on a daily basis and that hits your bottom line. So we as a PM, we have to walk this narrow line and we also almost always have this 20 to 30% scope of going up or down. So that like, you know, if it goes above that window or below that window, you can adjust the materials, right? So for instance, like, I think the perfect example will be like Amazon launched Kindle in 2007. And the original Kindle sold off and I think it's 2004. The original Kindle sold off in five hours, right? And then the customer had to wait for like at least like, you know, six weeks before they can get the other one. On the other hand, when Amazon launched the Firephone in 2014, they had like projected like, you know, thousands, hundreds of thousands of devices and like customers were not coming in. And they're, you know, the optimistic look, sorry, the pessimistic look was even, you know, much lower than that, they had to write up 140 million, 170 million dollars of inventory in six months after launch. So you have to be walking the tightrope of between like being, you know, adjusting between like optimistic and pessimistic and continuously adjusting your sickness. And there's another thing is that like after, let's say like after a year of your product launch, your adoption will hit a steady state and like after a while, like it starts dropping. So you have to keep giving signals to your ODM so that like your device volumes are appropriate. Okay, so this is another piece where like any time you are planning for devices, they need to be stored somewhere and they need to be, you know, shipped to the customer. That's one side. That's the forward side. You have to look at the end to end what happens from the time the customer places the order to the time when the customer receives the, you know, product and vice versa. Also, like what happens if the customer is not happy for whatever reason, the system is broken, they ship it back to you, you have to store it and you have to repair it or restock it, recycle it. So there is, you know, the forward and the reverse logistics is something that you have to plan at enough time. This is not something you, you know, you can jump up on it after you launch a product. This has to be planned from, you know, the first early definitions of your system architecture. You will know how much, what will be the, you know, like space that your product will be taking. So you will know how much warehouse space you will need for the time of launch and your peak and, you know, potentially like look for labor costs and account for all of this in your pricing model. So this is going to, you know, essentially like it depends on industry on the, on the computer industry usually take 20% of your inventory. It's pretty, I mean, it's, it's still very high. You can assume like up to 20% of your inventory can be returned from the customers are repaired or recycled or broken for that matter. Right. And you have to assume if it's cars are like, you know, industries that is well established, it's less than 2%. For some, you know, it depends on which industry it is, but almost always accounting for forward and reverse logistics into your, you know, pricing model and your P&L is going to be the key. So this is the last file that I have is that like, you know, as your product is in the hands of the customers, they are going to be key, they're going to be like, you know, interacting with it, you are going to be getting feedback, both positive and negative. And as a PM, our job is to continuously create them. Right. You can imagine where, you know, Steve is coming from here because like they spend millions, I mean, billions of dollars almost with thousands of people working on this product. And customers are holding this device in a very specific way and the call that innovation, I mean, there's anti-nation increases and the call drops. And it's, you know, it is a very specific problem, only if you hold it in one particular way. So now what do you do to tell your customers is like, just don't hold it like that, right? Like, because is it a blocker for the customer or is it a nice to have? But I mean, to Apple's credit, they have taken that feedback and they continuously fixed it. So iPhone 5 didn't have the same problem. They made different antenna choices. So I think that's the, you know, like an evolving job from a, you know, product manager point of view for managing your product, collect feedback, curate them, continuously identify which are blockers, which are not blockers. Things that are, there may be things that you may be able to fix in software. There are things you may not be able to fix in software. There's our system dependent. You focus on itrating on next generation. But overall, like maintaining and curating this list is a foundational job for a PM. All right. So finally, let's just bring it all together with some key learnings that we have learned during this particular webinar. System products require months of upfront planning and alignment from leadership, right? You need to make sure that your leadership is fully aware of why you are building it and what's your potential benefit and like how many services that you're going to be adding to your platform and things like that. And what's your, you know, net margin, profit opportunity, everything. And you also have to spend months ahead of time with respect to user testing, you know, like who your key target customers are, competitive environment, all of them. And PMs have to think critically forward and backwards about your product, meaning what happens from the time the customer places the order to the time when it is received by the customer and what happens if they are not happy, they're returning it back. You have to have logistics manage everything. So the number three, I think we, it's very clear is that like you are, once the specs are finalized, any deviation in plan is expensive, mainly on the system side, right? Anything that involves the hardware, OS firmware, changing them is much harder. And the services side, you know, you have a lot more freedom to kind of purchase them out. So making sure that you are building the right thing and setting the specifications early on is going to be the key. And finally, we didn't have a chance to discuss a lot, but focus on the things that you control tightly, you know, and you're, you're keeping the eye on it. But for example, as PMs, we manage the product usability, you can absolutely almost always control that to a tighter extent than to a system specification for that matter. Like product packaging is another one, right? There are things that we have more control and focus on that and focus on how you can use that to improve the customer's experience on your product. With that, I conclude today's webinar. It was always great talking to you. And if you have any questions, almost, you know, feel free to reach out on LinkedIn. Thank you.