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 at 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. That is the concept of a launch. My name is Jonathan Cutrell. 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 are 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 meaning a goal that is, 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 in their job. Those are indicators that are showing that you're becoming a better developer. 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. 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 sit in the same place that you are and not just in one dimension, but in every aspect that you can imagine becoming better. Really, that's the goal of this show. Hopefully you feel challenged. Hopefully you feel empowered by what we have to say on Developer Tea. 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 client, even with your family. There are many things that we talk about on this show that are applicable, not only in your work life, but also in your family life. 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 energized by the concept of this date that's looming well out into the future. There's some day that is set on a calendar and you're saying, okay, we're going to launch this project on this date. We've already talked about how 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. You can identify which of those projects that 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 this 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. Most people's expectations of what was going to happen on launch day, they wouldn't line up with reality. And why is this? Well, 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. Flywheel 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 in 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, 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 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. 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. 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 date that is distant into the future, then you're missing out on a lot of, first of all, the native benefits of creating something in the digital space. They're 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 any given minute. I can launch a new version of web application today. And you would get that version today, because whenever you use a web application through a browser, you're actually going directly to that application. And the new code is always available. 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 advantage of. And that is that you can always deploy new changes to your digital product, especially if it is in that networked environment. Something on the internet, for example. So here's why that's important. Here's why it matters so much. If you create this distant launch day, first of all, you're very likely to fall victim to 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? 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 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. This is my opinion as the developer and my clients opinion and maybe a stakeholders opinion. Typically, this is how things go. You may have a designer or whatever team is actually building the product, rather than the opinions of the people that matter the most, which is the users. 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. And this is where a lot of developers get this wrong. What we try to do is move that launch date so far forward and cut that feature list so small and this is kind of going in the opposite direction too far. We're responding to this idea of the launch date 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. So we need to spend some very intentional energy 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. Only both of those are wrong. But the problem is we try 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 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 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 language that says, hey, we're updating, we're iterating, we're creating something that can be changed quite easily. So that's take away number one, change your language away from something that makes this impending big, really important mark off day on the calendar, change that language, change that mindset. 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 attract 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 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 important to wear those hats and 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.