Shift Left to Ship Products Faster

So here at StateChange, we often talk about the importance of shipping, and we often try to help people ship remarkable projects. These tools or apps are only as useful as they are when they actually hit their customers. And often that's where the hard parts are. So as part of our mental model, Oliver has these four parts of beginner's mind, being curious, shifting left, and just something. I want to introduce us just a little bit more to this idea of shifting left. Shifting left means taking things that ordinarily would be at the right-hand side of the timeline and moving them back over to the left to do things early. There's an expression I associate with Mark Twain that says, if you have to swallow frog, do it first thing in the morning. And so we ask, what is the hard part of the project? And that's used for shipping that you need to do a little bit sooner. Because if you are deploying like a web app or a mobile app, Ask your question, can you deploy it early in the process? So if I were just to sort of, you know, quickly bring up here a WeWeb project, even before I'm worried too much about like how much stuff I'm going to be bringing into it, I would try hitting that publish button and particularly the custom domain. If I can, if I were building something more like a core React app, I would pop over to, you know, netlify.com or whatever it is I want to use for actually hosting that app. And I would try to get it in., and I would add it using their GitHub integration, which is pretty darn good. Um, and I would add a new site and I can import an existing project, which would probably be in GitHub or something. And then, you know, deploy it with GitHub and go find the project in question and go ship it across. By, uh, by shipping it to whatever production is going to look like, I get to take care of some of those distribution issues early and discover them because often that's going to be where things are tricky, especially especially when we're dealing with these no-code, low-code systems where they have put a lot more focus on the editor than they have necessarily on the question distribution. Now, if I'm building a mobile app, it's actually kind of an even bigger deal because if I'm using, say, flutterflow.com, which is a wonderful tool for making a nice sophisticated web application using mostly no-code, low-code, I'm going to find that there is a big difference. Between running something in like a little local simulator here and running it directly on the device and running it actually out on the App Store. So one thing I would try to do relatively early in the process is take this, not just run it, you know, in the browser, which are easy to do, but ask getting it onto the device. I've made a video about this and actually the FlutterFlow tooling has gotten even better since I made the video about that. But more importantly, get it onto the App Store. This is where things like TestFlight become really handy and FlutterFlow is going to give us this little gear here., and we can associate it, uh, with like where it says mobile deployment here. Like, how do we get this up to the App Store? Making sure you have like your, you know, Apple developer account up to date, making sure you've got your, uh, keys that you need when getting from the App Store, putting those early into the application then puts us in a position where we can be testing how it goes back and forth, uh, to the App Store and how the app is actually going to behave when it's on somebody's phone. And that makes a tremendous difference, uh, to be able to test that early without having a whole lot a lot of friction. I can't tell you how many people I've run into who have put all of their time and energy into making it run on the little simulator and then discover once they are actually putting it at the App Store, they have some sort of problem, or it's on delay, or whatever. They're going to miss their deadlines. If you've done this part early, it becomes painless. In fact, it's easier to do it early because when you do it early, you're not trying to mix it in with all the rest of the code stuff that you've been doing along the way, or all the, the cool remarkable things your app is eventually going to do. Instead, you get to deploy those additional features into your app and then just you keep on iteratively pushing, pushing, pushing out to the phone, which gives you this sort of warm and fuzzy feeling of being able to see what your app is actually like. And that also sets you up for being able to get better information about what your real requirements are, because once people see it on the phone, you'll get that better feedback and sets you up to maybe be able to instrument your app better as well to find out how it's behaving in production. You're going to find that the information you have access to once once it's actually shipped out to, you know, your website or shipped out to the device, or it's just sort of out in the world, it's just gonna be a little bit different. You find yourself wanting to have more of that information. This is where like using tools like Bugsnag or Sentry, or, you know, for the backend like NCscale or what have you, become really helpful. And you want to bring them into your process early. You'll discover that if you have in fact shifted left. Now there are some other ways to be shifting left as well that are worth giving some consideration to. One is what I call the Amazon strategy. Amazon is famous for saying that before they begin a project, they write the press release they're going to put out at the end of the project. This idea of creating marketing copy and documentation is so important, especially for efforts that are going to have some degree of sales to them. And frankly, almost all of these efforts do. Even if you're building like an internal tool, you're selling it to your colleagues. Maybe you're selling it to your superiors. If you're creating something that's going to be for external customers, well, then you've got an actual sales process to work with. By creating copy that's related to, you know, the, both the marketing and the explanation of the product in question early, uh, you get more buy-in earlier in the process. Often I find people who want to do a build and then they ship it, and that is not the perfect way of doing it. But because if you do that, uh, people will not give you feedback until you've already done the majority of your development. If instead you have gathered that feedback early, Things are better. I'm not saying do one before the other. The idea is to shift it left on the timeline, not all the way to the beginning. You're going to find there's always an iterative aspect as you move along these things. So my encouragement is be writing early, be creating the copy early, be making the demo early, be shipping these things early, making that an early part of your development process is going to allow the rest of the cycle and the actual shipping of the app to be just another step. As opposed to the, you know, big giant frog that you're trying to swallow, uh, at very much at the end of the night. And all of this is going to put you in a better position to gather feedback, right? We talked about deployment requirements a few minutes ago. Now it's just like, if you have the app, you can show it, you can be getting feedback on it. You can figure out where you're right about it. You can figure out where you're wrong about it. And the earlier you learn those things, the faster you get to turn that learning wheel. And that really is going to be where, you know, using no-code, low-code tools, it allows us to, you know, do things we couldn't do before. We can learn so much faster when we decide we're going to commit to shipping and we shift left.