In today's episode, we talk about why "launch dates" can be detrimental to progress. Today's episode is sponsored by Flywheel Local. Stop debugging local environments and spend more time designing, developing, and launchingWordPress sites with Local by Flywheel. Head over to local.getflywheel.com to download Local for free today!
In today's episode, we talk about why "launch dates" can be detrimental to progress.
Today's episode is sponsored by Flywheel Local.
Stop debugging local environments and spend more time designing, developing, and launching WordPress sites with Local by Flywheel. Head over to local.getflywheel.com to download Local for free today!
What was the last time you were late on a project? Whether you were working on a team or if you're working as a freelancer or maybe just you're doing an everyday task and it takes longer than you expect. Of course, this is something we've talked about many times on the show. The idea that humans are not really good at estimating. We're really quite bad at it, actually, especially in large chunks. So we're going to talk about a slightly different concept that's related to estimation today. And that is the concept of a launch. My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on this show is to help you become a better developer. What does it mean to be a better developer? Well, hopefully the signs of you becoming a better developer is that you are happier in your job. That's kind of the big one, right? You're happier in the work that you're doing because you feel like your talents and your efforts and your time are all matching up to create something with those efforts that is worthwhile. That is meeting a goal that is, you know, you actually feel good about the work that you're doing. You feel like you've accomplished something. That is a big indicator that you're becoming a better developer. Another thing that's an indicator. I'd love for people to send me emails and let me know that they got a new job or perhaps they got a raise. Those are indicators that are showing that, you know, you're becoming a better developer. And luckily, I've had the chance to hear some of those kinds of stories. Now, I'm not going to take credit for the work that all of you are doing. But what I will do is say that engaging in these kinds of conversations, engaging in this kind of thought, picking up this podcast and picking up other podcasts like it that challenge you to become better, not just, you know, sit in the same place. That you are and not just in one dimension, but in every aspect that you can imagine becoming better. And really, that's that's the goal of this show. So hopefully you feel challenged. Hopefully you feel, you know, empowered by what we have to say on developer T. Again, the reason for these conversations is to help you to think for yourself and to have conversations like this with the people around you, with the teams that you're working with, with your clients, even with your family. You know, there's there are many things that we talk about on the show that are applicable, not only in your work life, but also in your family life. So we're going to talk about all that kind of stuff as we go forward with this show. Today's episode is specifically talking about setting up this date, this launch that's well into the future and getting really, you know, energized by the concept of this date that's looming well out into the future. You know, it's. There's some day that is set on a calendar and you're saying, OK, we're going to launch this project on this date. And we've already talked about how this is this episode is related to estimation. But I want you to take a moment and think back to the times that you had a project that had a definitive launch date and you can identify, you know, which of those projects that you you actually met the launch date. And which of them you didn't. My guess is and I don't have any specific data. I can't pull you through your podcast listening application or anything like that. But my guess is that if I were to ask everyone who's listening to the show how many times they actually got everything done that they planned to get done before that launch date and how happy they were on the launch date that most people's expectations would not match up with reality. Right. Most people's expectations. Of what was going to happen on launch day. They wouldn't line up with reality. And why is this? Oh, there's a couple of reasons. We're going to talk about them today. And really, these are reasons that I believe we should all work to eradicate the idea of a launch date from digital work. I'm going to talk about this right after we talk about today's sponsor, Flywheel. I use local by Flywheel every day. Local is a completely. Free local WordPress development application. This thing is built with design in mind from the ground up. It includes a bunch of extra features and a beautiful interface. It improves the workflow of designers and developers, something that most other local development applications don't really provide. On top of that, the live links feature allows you to create shareable URLs to show off your local sites to clients. It's built on top of fantastic proven technology, by the way. This isn't bootstrapping on top of your computer. It's not a big bloated application. Instead, it's using things like, for example, Docker under the hood to create truly containerized sites for you to use. And by the way, some of the benefits of doing this containerization is you can set up multiple versions of PHP for all of the different sites that you're actually spinning up locally. And you can do it all through a beautiful interface. It's not like you have to. You know, set up some PHP version manager. You just create it in the container that is managed by local. So go and check it out. You can find it at local.getflywheel.com. And by the way, they are working on a pro version. This is a premium version with even more great features. Go and check it out. It is local.getflywheel.com. Thank you again to Flywheel for sponsoring today's episode of Developer Tea. So we're talking about why you shouldn't set up a launch date. You shouldn't set. A date on the calendar that you're considering the launch day. Now, I have to be honest with you. There is going to be a day where the state of the application as it relates to the general public, it becomes available, right? This is the launch day that we all perceive. This day that's at the end of the project is very different from this day, though, because this day needs to happen a lot sooner. And that's really kind of the big message. That. I want to get across in today's episode. If you set up a launch day that is distant into the future, then you're missing out on a lot of, first of all, the native, uh, uh, benefits of creating something in the digital state, in the digital space, more specifically creating something in the digital space that is based on network availability based on network delivery. This is especially true. For example, for web applications, web applications can have a new version. Uh, any given minute, I can launch a new version of web application today. And, uh, you would get that, that version today, uh, because whenever you use a web app application through a browser, you're actually going directly to that application. And the new code is always available. It's, uh, you're only using a client to consume that application. So the concept here is very simple, but it's also often missed. It's often misunderstood. And it's often not taken. At the same time, you may have taken the evolution platform and replaced it with another evolution platform, bringing youension evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution! that overreaching problem, the idea that you're going to be able to adequately set that launch day correctly, right? Secondly, you're going to end up trying to put so many features into this application before that launch day. And a lot of those features either don't really even need to be built, or they aren't nearly as valuable as getting some user information, some user data, some user feedback, right? And so the idea that I want to present to you is instead of having this launch day that's way off into the future, I want you to find the earliest possible launch day for the least amount of features that make your product viable. This is a concept that we're all probably familiar with by now, the concept of the MVP. But the problem is the value of an MVP is basically totally unrecognized. Totally an illusion until that value is delivered to the users. In other words, it doesn't matter whether or not you have an MVP if you don't actually launch the MVP. Because the point of an MVP is to create a version that is minimally viable. That means the market is going to respond to that version, and you can start generating value from that version of whatever it is that you're building. And what this allows you to do is take that feedback from the customers, and you can start generating value from that version of whatever it is that you're building. And change the things that you had originally thought you would need. So this launch day that's way out at the end of the calendar, that prevents you from getting that feedback. And what you end up doing is creating an echo chamber. And in this echo chamber, the only thing that you have are the opinions of the people who are building the product, right? This is my opinion as the developer, and my client's opinion, and maybe a stakeholder's opinion. Typically, this is, this is how things go. You may have a designer or, you know, whatever team is actually building the product, rather than the opinions of the people that matter the most, which is the users, right? So if you're going to build a product for users, then it makes sense to get that product to the users as soon as possible, without undermining the goal of the project altogether, right? And this is where a lot of developers get this wrong. What we try to do is move that launch date so far away from the project, and then we try to get that product to the users as soon as possible. And so we try to get that product to the users as soon as possible, without undermining the goal of the project altogether, and then we try to get that product to the users as soon as possible, without undermining the goal of the project altogether, and cut that feature list so small, and this is kind of going in the opposite direction, too far, right? We're responding to this idea of the launch day never being a thing. Instead, we go all the way the other direction, and we have a product that really nobody wants to use. And the problem here is, we're calling that the MVP. We're calling that the minimum viable product, when in fact, it isn't viable at all, right? So we need to spend some very intentional energy on building that product, and we need to spend some very intentional energy on building that product, trying to understand what that MVP actually is. There are going to be differing opinions on this. For some people, they think that the MVP is that thing that they can launch at the end of the project, that very far away launch date. And for others, like for example, developers like me, we have a tendency to believe that we can launch a single unique feature, and that really is the MVP. Usually, both of those are wrong. But the problem is, we try to understand what that MVP is, and we try to understand what that MVP is, because we're going to create a justification internally for what an MVP is. So what I propose to solve this problem, because it's hard to know what an MVP is, because it's hard to know what an MVP is, without having customers tell you what that MVP is, what I propose to solve this problem is to create some kind of test group. Find customers that you want to use, whatever the thing is that you're creating, and allow them to help you determine what is the MVP. Allow them to use whatever the thing is that you're creating, to help you determine when something is good enough to be used on a regular basis or if it still needs some work to be minimally viable. What you'll often find is that the last third or so of a project really could have been done after the project had been launched. In other words, you could have learned and changed. You could have adapted that project to respond to the changing business environment. So the takeaways that I want you to write down in your notebook or talk about with your friends, talk about with your colleagues, talk about with your clients, is this concept. Removing the words launch from your vocabulary because really what that creates is this false sense of celebration, this false sense of pressure, and this false sense of value on that particular day. Instead of using that word launch, let's use a different word. Perhaps deploy will work for your particular situation. Maybe deliver will work or maybe release will work. But instead of using a language that makes it feel like you're going off into space and you have to prepare a whole lot for that trip, instead make it a language that says, hey, we're updating, we're iterating, we're creating something that can be changed quite easily. So that's takeaway number one. Change your language away from something that makes this impending, big, really important, marked off day on the calendar. Change that language. Change your language. Change your language. Change your language. And then the second thing is find a way to create some kind of alpha testing group. If you can find customers that are actually invested or interested in a particular product, that's a really good way of creating an alpha group. If you have a product that, for example, is a paid product and it's worth it to the stakeholders to provide a free license to that paid product for this test group, then that may be a good way to create a group. Those individuals. But here's what I don't want you to do. And this is the final point, kind of a pro tip for creating a test group. You cannot wear the hat of a beta tester. You as the creator of a given product, you cannot wear the hat of the beta tester. Even if the product is for developers, most of the time you're going to have a different perception simply because of how close to the product you are. What you need to have is someone who represents the product. And that's what I'm going to do. I'm going to create a group. I'm going to a significant market segment. They represent a significant presence of the target market. Even if you are building something for developers, I highly encourage you, if at all possible, to avoid being a part of that test group. Don't allow the client or the stakeholders to be a part of that test group either. And this is super important because what it does is it keeps the opinions from bleeding over. It's very difficult to wear those hats and to be able to see what's going on. So if you're a beta tester, you're going to have to truly separate your differing motivations on either side. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Local and Flywheel for sponsoring today's episode. Remember, Local is the application made by Flywheel, and you can get started with Local today for free. It's totally free, by the way. I use this application every single day. It's a beautifully designed application. In fact, I've met some of the folks at Flywheel, and they are truly dedicated to creating a good product here. So go and check it out, local.getflywheel.com. Thank you so much for listening. I hope that today's episode has been challenging and encouraging. And until next time, enjoy your tea.