 So we're going to talk about building plugins for e-commerce users today. And as I went back through building my slides for this talk, I realized I probably should have called it building products, right? So to give you all background on what I do, I'm the head of product at Skyverge. We've built over 70 different software products for e-commerce stores. So not only have we built a lot of plugins, but we've built SaaS apps and we've built other products for e-commerce. So we've also worked with WooCommerce Shopify and Easy Digital Downloads. So not only have we built a lot of different software products, but we've also worked with a lot of different software platforms. So what I wanted to dig into a bit today is not only how we've built the things we've built, but what has made them successful and how we've determined what to build and what's been important in those products that's made them popular or good choices for merchants. So if you're doing some quick math, you'll realize that that means we've averaged more than one product each month for the length of time the company's been around. So we've launched a new product every single month. Now, that's not really accurate, right? Most of those products were built very early, and these days we don't launch very many products at all. But most of those products have been pretty successful. And so we've learned a lot about what to build and just as importantly what not to build to be successful for an e-commerce user. So as we go through this today, there's so much that I could offer here, but a lot of it's stuff I've learned from reading other things. So you'll see a lot of resources in my slides. If you go to slideshare.net slash beca rice, B-E-K-A-R-I-C-E, you'll find this set of slides there. So if you download the PDF, you'll see anything that's underlined like these skyverge and jilt links. Our resources where you might be interested in learning some more or reading some of the things that I've read that have been influential for me in kind of putting some of these concepts together. So with that in mind, to talk a little bit about what we do when we build a product for an e-commerce user and how that differs a little bit from WordPress. Like any good story, we'll start from the beginning. So before you build a product for someone who's in the e-commerce space, how do you validate that idea? What's going to take you towards building a version one of that product? And what's going to be important as you try to scope out what should I be building and how should this be different than, you know, something I'm not a built for publishers or a media site? How should I change my thinking around that? So having done this for a long time, I still ask myself this question, right? I've worked with e-commerce for six years. How do I build something that an e-commerce store is going to be? How do I address the needs of a merchant, of a store administrator, someone who's running a store? So the best advice I can give you is if you've not worked with e-commerce before, to identify the needs of an e-commerce user, work with e-commerce stores on a contract basis, do some client projects, do some custom development. If you're mostly in the product space already, you might not do a lot of client work, right? But it's a really important learning experience to learn about the needs of your e-commerce users. The thing is that when you're looking at the e-commerce store, they all have pretty unique workflows, right? They all have different wrinkles in the way they manage their store and the way they manage their order fulfillment, the way they manage their products, that you're going to need to get some basic understanding of before you could build something that's going to really address the needs of these users. So get into it, do some customization, go on Upwork, do some projects, go on Codable, take on some of these projects which may not be super profitable for you to start with, but it's going to teach you how to think about e-commerce and what some of the common workflows and common issues that merchants see in their day to day. So to help you out if you've not done these projects, I have 30 questions that I would put together that can help you uncover some of these unknown unknowns, some areas where you might lose some time if you've not done e-commerce before to kind of help you try to suss that out in the discovery period with a client. So I'm not going to focus a lot on client work in this presentation, we're going to focus more on products, but it's a good place to start and to learn about what a store needs to be successful and to help you identify areas of need for a product. So, once you've done some work with an e-commerce store, a lot of times people think, I want to build something for this kind of person, and that's how they go about thinking about what kind of product they want to build. I would say that we always focus on anything we build having a job. What job is this product going to do? What pain points is it going to solve? So if you come from a marketing background, you might look at things like I need to understand my personas, I need to have a few ideal customers in mind, and I need to know that Peter, who's 35 years old and has a degree in computer science, he's my customer, and I'm going to build something for Peter, or to frame it more like a merchant, I'm going to build something for stores that make $50,000 to $500,000 a year in annual revenue that are in the fitness niche, and they sell digital goods and membership subscriptions for fitness bloggers, and that's my target customer. And I would say that for building a product, who you're building it for is not where you should be starting. And while that might be helpful for building a marketing plan, it's not helpful for building a good product. So we focus a lot on what is this product going to do. And Snickers is actually a really good example of this, even though this was a marketing campaign they did, they didn't say, okay, who do we target with Snickers? You know, Peter, he's 35 years old, he has a college degree, he likes chocolate and nougat and tasty snacks that he can eat on the go. We want to know why does Peter hire a Snickers? Why does Peter use a Snickers? It's to satisfy his hunger. And it's quick, easy to eat, and something that he likes, and kind of can help him cave into a sweet tooth every once in a while, right? So understanding what people get from your product and what pain point it solves is where you want to start. The framework we use to do that is called jobs to be done. So rather than thinking about who uses your product and starting with a persona or user story, instead, start with the job your product does. Just someone hire my product. What job is it going to solve for them? Just like they would hire a person to do this, they're going to hire my product to do something as well, I need to figure out what that job is. This is not to say that personas are not useful, right, and that understanding your customer isn't something that's essential, it is. But a persona should be something that comes out of understanding your product's job. And that's where product then starts to connect to marketing. And marketing can use these personas to build a vertical and to understand where your customers are, but to build a good product you need to first come deeply into what job it's going to be doing. One of my favorite quotes on this is from the co-founder of Intercom, that products don't match people, they match a problem. So we need to very clearly identify the problem, the simplest and most elegant solution we can put together for that problem, and that becomes the basis of version one of any product that you build. From there, I would say that a lot of people get to that point, and then I think, great, I'm ready, I'm going to build it, right? And I would challenge you to put a little bit more time and emphasis on customer research before you build anything. So while you might have a clearly defined job for a product, and you might understand, okay, I know that it's going to do this and it's going to solve this need, challenge your assumptions with customer research. It's vital to understand your audience and to understand if your assumptions about the job are actually accurate. So customer interviews are my favorite way to do this. I spend a lot of my time just talking to customers, getting them on the phone, getting them on a video call, and understanding the way that they talk about their problem and what they've hired my product to do. So even if you are working with existing clients and if you take my advice to try and do some client work in e-commerce before you get into this space, talk to them about your potential product to understand how they view the pain point you think it's going to solve. And I feel like, yeah, it's not a big deal. I probably wouldn't pay for something. You need to really rethink your assumptions. A lot of people don't do this customer research before they build something, which is why they struggle to find product market fit. So whenever we look to build something new, we try to see if the product job is going to align with what our existing customers say. And nice. Let's see if I get away without that Wi-Fi. I have a framework here that I use to do these interviews. OK, I think it was events, right? Oh my god, this is microscopic. Sorry, y'all. We're waiting. OK, all right. Of all the things that happen in the middle of a presentation, there we go. That's our hiccup. Now we're done. So whenever I go into an interview with an existing customer, I use this framework, which I've linked here. That framework is actually geared toward merchants. But it's helpful for anyone to do a jobs-to-be-done interview to understand why someone hired your product and what are the pain points they're trying to get at so you can more effectively scope that product to their needs. From there, when I do a job interview for someone as the person who's in charge of product, the next thing I do is I build a B2B persona. So that's what I pass off to my marketing team. And that's where they start. But for me, as the person who's in charge of product, I have to start deeper. And I have to start with why. Now, one of the best questions I get is, that's cool, except I don't have any customers. And how do I figure out customer needs if I don't have customers? So if you don't have any existing clients in e-commerce, you don't have any customers you can talk to, you should still be doing customer research. And you can hack it, essentially. If you're just starting out, you need to find these people. If you can't find them to interview them and talk to them, you are not going to find them to market to them. You're not going to find them to sell anything to them. So part of the benefit of doing this customer research is you need to go where your customers are, and you need to learn how to find them and talk to them. So I would say that the first thing I do is read industry news, tutorials, guides, blog posts, anything you can that's going to relate to the job your product is going to solve. So in the e-commerce space, I run a site called sellwithwp.com that is devoted to just people doing e-commerce with WordPress. I've written a tremendous number of tutorials on that site. So if you were going to build a product, if I've written a blog post on how to do something, that should tell you that people have that problem. People have asked me that question. That's where you should be looking for inspiration for products. And read the comments. See how people describe their problem. See if they tell them, yeah, this worked for me. This was great. Thanks so much. Or this would be cool. But what I'm really looking for is this. And do your research in kind of a gorilla fashion. Dig in and read the comments. Read industry news. So you should look at the e-commerce blog, the Shopify blog. Bob WP also does a lot of e-commerce tutorials. Anything e-commerce related that's going to be related to the product you're looking to build. Read it and see how people describe their problems. Read through the comments. The next thing I would say is to set up surveys and interviews by trying to drive traffic to landing pages. So what I've seen be really successful with this in the past is I say, OK, I know what product I want to build, but to validate this, I need to really talk to people and I need to get some surveying and see how they describe their problem. So I can set up a landing page. I can do some Facebook ads or create some AdWords campaigns to drive traffic to that landing page and ask people to fill out a survey. Say, if you fill out the survey, you're going to be entered in a drawing to win $100 Amazon gift card. Make the survey just long enough or just detailed enough so you don't get total nonsense replies to it. But drive people there and give them a financial incentive. And if you spend a couple hundred dollars in customer research, that is money absolutely well spent and you will be much better off spending that couple hundred dollars first than spending development time that you then might have to come back and redo if you don't understand your product market fit. Now the best part about doing that is if you get these survey answers, say, OK, I need your email address so that you can tell me, if I can tell you if you win the Amazon gift card, you've started to build a customer list so that you can market your product when you're done. And if you get really great survey responses and someone who seems insightful and takes a survey seriously, circle back to them and say, hey, this was great. I'd really love to hear more about the problems that your business is having. How about if you talk to me for 20 or 25 minutes, I'll send you a $25 Amazon gift card and you'll still be entered in the drawing. So you can spend a small amount of money to validate your ideas with your customers and you're going to be much better off for it to have a product that more acutely addresses the needs of your customer when you actually start building. So I'd say the biggest mistake I see before people get into building is they don't spend enough time in that research phase in really deeply understanding the customer problems and the job they hire the product to do. That's going to help you decide what you're going to build and just as importantly, what you're not going to build. So when you are scoping a V1, a lot of people say, OK, if I want to build this plug-in, that exports data from an e-commerce site and he's had this feature and he needs to do this and he needs to do that and there's all these competitors in the space and they all do these things. So my product has to do all those things too. And that's what they think frames their version one. You don't need to do that. And I would challenge that assumption and say you should be a lot more judicious about what you do. So if you're trying to determine what's in scope and what's out of scope, when you start building a product, be as ruthless as you can possibly be. Take your scope down as far as you think it can go and then take it down some more. And most of the time you can deliver a product that's feature complete that's much smaller than you think it needs to be. So if we go back to that export example, what do we need to have a feature complete exporter? Well, it needs to take data from the e-commerce system and say, OK, how can I get this data out in a reliable way? It probably needs to have a format that's digestible by a lot of different programs like a drop shipper might be getting this data. I might be sending it to print shipping labels. So a CSV format with data pretty well formatted in a standard way is going to be what we need here. That is not a feature rich product, and that's OK. Your first version does not have to be feature rich, but it does need to be feature complete. So pick one essential job for your product. What is it going to do? At its heart, I'm going to export information from the e-commerce system. And that's your North Star. That is all you do in V1, and that's it. People will still pay for value if a product does an essential job really well and in a feature complete way. So for us, that problem is one that we solved. My team built an order and customer export plug-in from WooCommerce. And when we looked at building the initial version, we had all these things we wanted to do. It's like, well, really, you should do these things on an automated schedule, and we should get people flexible formats so they can change what's included in the export file. There's a lot of stuff that we should be doing here. But that's not what we did for V1. For V1, we made something that was basic. It had two different export formats. You could pick something that was in order for every row in the spreadsheet or a line in them in every row of the spreadsheet. And you had to manually start an export, but it got your date out, and it delivered value. So we found the most essential way we could deliver value, and that's what we shipped for our V1. Now today, that product has also become feature rich. It does automated exports on a schedule. It'll send a webhook with the export file or send it via email or upload it via FTP to another service as a custom format builder so people can choose which columns are in their CSV file and how they're formatted. It became a very feature rich product later, but people still paid for our V1 because it did something very well. It did one essential job, and it did that in a really complete and dependable way, which dependability is a huge thing that we'll dig into a little bit more in terms of building for e-commerce. So there's also another reason that you should cut scope. And so a lot of people say, that's great. I don't agree. I think I need these features to compete. People aren't gonna pay for my product until I've added more things to it. Cutting scope is gonna let you deliver more value to your customers over time. So you will do better by giving them less, right? Which is a concept that people often disagree with. There's a really great post on this called the time value of shipping that I'd recommend you read. And the concept is pretty simple. It's like money, right? More money or money I have now is worth more to me today than it will be tomorrow. And so that's true of value that you give to your customers with a product. If I can ship something sooner, it's like giving my customers compound interest. So if I build a feature and I say, okay, here's how I build this and here's how I address the needs of 100% of my customers. And it's gonna take me five weeks. But if I can ship a different version of that and say in two weeks, I can address the needs of 30% of my customers. And then five weeks later, I could get all of them. I should ship that component, even though not everybody is gonna be happy at first. Because the total value that my product delivers to my entire customer base is gonna be greater over time. So making those decisions to ship as soon as you can and to cut scope as much as you can is actually gonna give your customers more in the long run if you recognize that there is a time value to when you ship something to your customers. So take your V1 as small as you can, get to it as fast as you can and then you're gonna iterate on it and it's gonna help you find product market fit faster because you'll better understand the needs of your customers and you're giving them value as fast as you can. So that's all related to before you even build something. There's a lot of thought that goes into every product we build. So we've built, like I said, over 70 different products, right? We do not ever build anything new these days without going through these steps. We do that because we've messed it up pretty badly in the past. We built something that just, we didn't understand the clear need for it. So we do customer development on everything that we build and we take whatever we think is the V1 and then as soon as we've built a spec document for it, we try to cut everything out of the spec document that we can. Then finally, we'll go into the development process. And so when you're doing e-commerce development, you have to be aware of the fact that you're building for several different user roles on the site. So not only are you building for a merchant, but you're also building for that merchant's customers, right? So being aware of their customers and being aware of their needs, one of the first things I would say to you that's gonna help you is to think of the site no longer as a content management system, but as an application, right? You're not building a WordPress site, you're building an e-commerce application. And so the way you need to frame your thinking and your development practices is gonna be a little bit different than something you might have done. So if you've been working on media sites, for example, so you work with people who are publishers, who are blogging, a lot of the time, the way you're building things for them is gonna account for the fact that they're pushing data out, they're publishing content and things are leaving their site. An e-commerce site, you have to think of like an application, it's a data hub. It's got information coming in and out of it and so the way you build things is going to have to adjust and to account for that. So I would say that the first thing you need to be aware of is to rethink the role of caching on an e-commerce site. And caching can sometimes mask a sort of a host of ills, because I can cache some static output and then just keep serving that output and it doesn't matter how not performant I was to get to that output in the first place, right? You can't get away with that with e-commerce because you have so much dynamic content. I have user sessions constantly that are being updated so as someone browsers my site as they're adding things to the cart, right? That should be changing their experience with my site so I might have a cart widget that's gotta change. I might have when they visit the cart page that's gotta change, all right? So I can't just cache all the static output of my site now. Caching still plays an important role but we have to really understand its purpose in an e-commerce site and that it's gotta be different. Likewise, people logging into the site is gonna change the way that content is generated, especially with e-commerce sites with membership components where different people should see different things or wholesale components where people should see different prices, right? So if you're used to just installing a caching plugin and configuring it, what you're gonna be doing here is different. So if you're building a product, be aware of the fact that if you're caching certain pieces of output from your product, you might have to rethink the way you do that for e-commerce and maybe give it a key that's keyed off of that particular user or whether that user is logged in or not and be a little bit more intelligent about the way we do caching. I would say too that to be aware of the data you're generating and how it plays in a hosting environment with different caching. So an example of this is we had a host that was caching session cookies without realizing they were doing it which is a no-no on an e-commerce site because that's like basically your login information that's being cached and being served to other people in their browser and being leaked essentially. So be aware of how hosting environments could impact your product and then we essentially had to build our product defensively because of that and throw an error when we noticed that was happening to avoid people having like login information switched. Also be aware of the way you use data and so this is a big one for people who are used to working with publishing sites in WordPress and not e-commerce sites. They're not necessarily aware of the way that they're using data and the fact that an e-commerce site has a lot more data being joined across several different tables. So if we take orders for an example, let's compare that to let's say querying posts or a custom post type, right? So if you've built a media site for someone, they probably have data in the post table and they probably have meta in post meta, right? And so it's pretty easy for you to kind of put that data together and generate the output based on those two tables of information. But if you take an order, I'll use e-commerce as the example here, I have orders that they're in the post table. That's not ideal and that's probably gonna change, right? But that's where they are now and I have metadata for those orders also in the post meta table. I've also got order items and I've got an order item meta table and I've got the comments table which houses my order notes. I've got all this data across these several tables so that when you're querying stuff like these products are in this order, give me all the orders that contain this product, you have to be aware of the fact that that's joining information across several different tables in the database and it's not gonna be as performant as what you might be doing with just posts and post meta. So you're gonna have to be aware of the fact that you need to build your products differently and also consider where you store your own data that using custom tables or custom data infrastructure might be the better way to go for you in your e-commerce product which is sometimes not a popular thing to say in WordPress, right? Because we're all like, oh my God, WordPress gives you a data structure, you should use it. Well, I'm not doing what WordPress was designed to do. WordPress was designed to publish. It wasn't exactly designed for what I'm coercing it into. It can do it well, but I should be aware of its limitations and be aware of the way I produce data and the way I query data to make sure I'm doing it in a performant way. Another thing that can be great for publishing but not great for e-commerce is the way you handle events. And so my next two points here are kind of tied together. When you're building an e-commerce product, do not rely on WP Cron. And so that's used for scheduling events, right? If you are building for a publishing site, WP Cron works great. You schedule a blog post and it roughly posts and publishes around the time you expect it to assuming the site has enough traffic. On an e-commerce site, people use it for scheduled events and it doesn't work so well, okay? You're never gonna have 12,000 blog posts all scheduled for the future, right? Even the largest publishing sites are not gonna schedule 12,000 blog posts at a time. WP Cron starts to fall over and implode on itself between 10,000 to 15,000 events or so. On an e-commerce site, it's super feasible to have 10,000 to 15,000 things scheduled at once and even more, right? Think recurring billing, think polling for updates from an external system like a customer CRM or a fulfillment system. And what I see a lot of novice e-commerce developers do is that they stuff events into WP Cron because they're like, that's how I schedule things in WordPress. And when you do that, you're gonna cause issues at scale with your customers or your client's sites. So don't rely on WP Cron to schedule things for you. Look at doing a different form of either background processing for things that are gonna be executing sequentially. Or look into potentially using alternative CRON methods as well as event runners. So in WooCommerce, they've actually just merged a library called Action Scheduler into WooCommerce Core, which is what you should be using to schedule events instead of using WP Cron. There's a lot more you could go into from a technical perspective as to how we've done things in terms of scheduling background events and processing large sets of data. That I would say if you're really interested in that, take a look at our Skyverge WooCommerce plug-in framework on GitHub. Our plug-in framework is completely open source, but we do have a couple of classes in there that are in the utilities directory that kind of show you how we process large data sets and how we process things differently when we have scheduled events versus what WordPress Core may do. And then a final thing that I would say is usually unique for people if they're coming from a publishing background and not any commerce background is incoming data is something you're not usually used to handling. So in a publishing site, content's going out. So usually the site is pushing things out onto the interwebs, into the tubes. In an e-commerce site, you also have a lot of data coming in that you need to account for. So as a site owner, I am receiving IPNs for my payment gateways, notifications as to whether a payment was successful or not. I could be getting shipment tracking updates or information on shipments from my shipping companies like UPS or FedEx. I could be getting order status updates from another system like an ERP or a customer relationship management system, a CRM. So I could have data coming into my site that needs to be handled that as a developer, you need to make sure that what you're building acknowledges that fact and makes sure that those incoming requests aren't being cached. I've seen hosts do this where they cache the WC API endpoint and then incoming data is coming in being told that it's redundant or it's not getting the response it expects. So you kind of have to code defensively for these things and to be aware of the fact that if the site's gonna be taking in data, that needs to happen just as reliably as data going out and away from the site. So there's a lot of components to this that you should just be aware of and kind of rethink your development practices to account for this. I would also say that not enough people spend time on user experience. And so as a developer, we try to give people configuration options and we try to say, well, my code is clean and it's dependable and then that's what matters to people and it's not just what matters to people. Especially for an e-commerce user, you have to have an even simpler user experience. And while these people are usually technical users, they don't have time to come in and configure a bunch of different stuff. They don't wanna work on their website. They wanna work on their business so you need to respect that and account for that and if you give them a more streamlined experience, they're gonna be far more likely to use your products. So I would say that messaging is a big part of that, right? And being aware of the fact that not only are you designing a user experience for your customer, the merchant, but you are also designing experience for their customers. Your customer isn't the only customer in the equation. There's this sort of dual context where you are building for your customer and their customers at the same time it's not always present in other WordPress plugins. So use relevant messaging in both the things you show to your user as well as the things you show to their users, to their customers. So a good example of this is that when we've built payment gateways for WooCommerce, much of the time it's really helpful for if a payment is declined or something goes wrong to know the exact error code as to what happened. So I should know that if I get a request to authorize.net and I get an E00039 error, I know that that customer already exists and I shouldn't be trying to send that customer and save them in authorize.net, right? As a developer, that's super helpful for me. As a customer, if I see that on the front end of your site, I'm going, what in the world is going on right now? You should give me a better notice. So in our payment gateways, we have this feature where every error code we get, we show it to the merchant and the user because that's helpful for them and helpful to us and we put it in the order notes, but for the customer, we translate that into a human friendly message. We say, your CVV code was incorrect or we couldn't save your information here because you already have an account, right? So be aware of the messaging for your users and their customers and you have to meet the needs of both of them. And then also showing notices contextually is a big part of this. So we have this sort of problem in WordPress where you have this admin notification spaghetti that happens, right? I've seen a couple of people like, yep, yep. You log into someone's site for the first time and like all of this is like notices and then there's actual stuff, right? And I would say that it's an important part of the experience and I am not anti notices, but I would say that you find the best results when you take those notices and you make them contextual and timely and relevant. So when something happens in one of our plugins, we show notices only on the relevant pages, right? So I'll show a notice that's persistent on my plugin settings page and nowhere else. Or if it's like, hey, something bad happens, I'll say, good, you know, here's where you're gonna go to fix this in the admin. So be sure that you're messaging for both your users and their customers is contextual and relevant. And then finally, in terms of the way you design a user experience, be very opinionated about design. And I don't just mean visual design, I mean your product design. So everything that we build for an e-commerce user, every single setting, every UX component is justified. Our developers are not allowed to add a setting without a justification as to why that setting is absolutely necessary. So that's kind of that WordPress ethos of decisions, not options. What it means to us is we don't allow a ton of configuration. This is WordPress. People can change things and they have access to the code base to do it. So I would say make a decision as to what you think is best. Wrap a filter around it if you're not sure. And then over time you can add more settings as needed but it's really hard to take them away. So be very intentional and very opinionated about the user experiences that you create. And then the last part about building experiences is to love your developers. So they are your other customer, right? Love your developers, make things easy for them. Whenever we build something, we do customizations ourselves that we think other developers are gonna wanna do. So we maintain, for example, a snippet repository of all sorts of customization snippets that we've seen people do with our plugins. And then every time we make an update that's significant, we use all those snippets and test them and make sure we didn't break anything. If we build something new, we will also simultaneously write a customization for it just to make sure it works as expected. So the second article there is a good example of that. We updated our customer and order import plugin to allow you to use a different data store than the file storage system in WordPress. We wrote something that would offload export files to S3 just to make sure it worked, right? You have to be friendly to developers and really consider them when you're building as well. And then a small final note, since we have a couple of minutes left, is that you have to be committed to a product when you build it, if you're gonna build things for businesses. And so a lot of the time people say, build something, just scratch your own it, sure. If you like it as hobby, it could be a good product. And that's really a neat and wonderful idea, except if someone's going to build their business on your product and they need to rely on it to run their business, you gotta marry it. You gotta marry your product, right? You gotta be committed to it for the long term. I have products that we've had over six years. I don't always like them, right? Sometimes mostly I don't like the decisions I've made in them, right? But you have to be committed to that product for the long term if you want an e-commerce merchant to feel confident enough to build on top of your software, you need to say yes, I am in this and I'm here for this product and that might be you selling it or something at some point, but maintenance is a huge part of being successful for the e-commerce user. So to optimize for longevity, to optimize your long term success, be aware of product updates, but more importantly, to get to the point where you're feature rich, remember the things that got you to your V1. So always prioritize customer value and the smallest path to customer value, right? So scoping each feature and each change in your plugin should be done just as judiciously as your V1 was, right? Ship things smaller and remember the time value of shipping. I will say, and this is probably an unpopular opinion, that includes bugs. So when you're starting out, you probably have some bugs in your product and you're gonna try and fix all of them, which is great. But over time, to have a product with longevity, you've gotta prioritize bugs the same way you prioritize features and other new additions is that if a bug only affects a small amount of your users or fixing that bug won't deliver a lot of value, you need to prioritize something else over that bug. And that you need to be okay with that fact that you're never gonna be done, that your software will always have bugs, but that your job when you're building for someone else's business is to prioritize the value that you can give to them. And then the last part of maintaining a good product over the lifetime of that product is to get actionable and good customer feedback. So the final piece of advice I'd give you is to understand your customers deeply, understand their requests versus their needs. So as you do support and as you talk to your customers over time, they're gonna start to ask you things for your product. Oh, it'd be really great if you did this, right? So I have this order export plugin. It'd be really great if I could automate that export to send it to my drop shipper. Yeah, that's an ask, I could build that. But what you really need is a direct integration from your site to your drop shipper. You don't need an automated export, you have a deeper need there. Now I might build that other thing as an interim step, right? That might be the next iteration, but for me to have a successful product long-term, I need to understand that deeper need too, and that's what I should be building over time. So start to understand that what your customers ask you for over time, isn't always what they need, and that you need to develop that as a skill that you can recognize it. And talk to your customers constantly. So do interviews, talk to them in support, uncover where they have pain points for your products, what they're motivated for, what they're using it for, and use your support to inform your UX. If someone asks me how do I do this in my product, I should always look inward and say, could I have made this better? Could I have changed my product so that this was clearer to you? And the last word of caution for that is, don't skip interviews. So a lot of times people build a product and they listen to everyone in support, but they forget about the fact that they're happy people too. And this is a mistake I've made where I prioritize the needs of people saying, I don't like this, fix it. Over the people who are like, this is amazing, don't change a thing. So make sure that you have that well-rounded process that got you to your version one, time value of shipping, great customer development. You need to maintain that to have a product with longevity that's successful over the long term. So with that, I think we are just about time. Those are your three takeaways, identify the product's job, do great research on it, treat the site like an application, and not just the content management system. So make sure that that environment is gonna be performant and that you've built it in a way that considers that. And then engineer longevity. You can build longevity into your product by doing all the things that got you there. Small, tight feature releases and great customer development. So that said, there's my slide link again. And thanks to y'all for coming. You have perfect timing.