What was the last feature that you built that was useless? Maybe a bit of a strong word. What was the last feature that you built that wasn't as useful as maybe you had hoped, or seemed like you had wasted some time building it, and it didn't really have the impact that you or maybe the other people in your team expected it to. And how can we avoid this scenario? At least, what are some ways that we might try to avoid this? That's what we're talking about in today's episode. My name is Jonathan Cutrell. You're listening to Developer Tea and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. And this isn't an easy question to answer. We all have wasted time on features that we had hoped would be useful, but turn out not to be. And this happens not only at the feature level, but at the entire product level. And it would be a pipe dream to believe that we can control for every single variable. Very smart people who build products have come before us and they have kind of taught us that there are many variables that are totally unpredictable. How the market will do, what other competitors might do, and especially human behavior. Human behavior is very hard to predict. And even though we have some kinds of heuristics that we can use and some frameworks for understanding human behavior at the end of the day, a lot of what we do as humans is unpredictable. And this is true at an individual level, but it's also true at kind of a cultural level. What kinds of movements entire cultures will follow is really hard to predict. And so even when you're talking about the small culture of people who might be interested in your application or interested in your particular feature sets, those people are unpredictable. And they move in unpredictable ways both individually and as groups. However, with all of this information in mind and these huge caveats that we start this episode out with, we can avoid wasting time on features that we haven't justified. And justifiability is exactly what we're going to talk about right after we talk about today's sponsor, Flywheel. Local by Flywheel is a simple, free and beautifully designed local development application that's optimized for WordPress. It's adored by over 200,000 web developers and designers. And it's a fuss-free way to improve your workflow and spin up a local WordPress site quickly and easily. If you've been developing for the web for very long, then you've almost certainly used WordPress at some point or come into contact with it. People love local because it's completely free to use and it's incredibly simple. You can launch a new WordPress site in a manner of minutes. And Flywheel is constantly improving local. With local, you get things like local SSL support. This allows you to test your sites locally. You can see why they picked this name without any hassle. You can easily access SSH, WPCLI. This is all modern WordPress development, not just scripting, but all of the tools that you as a mature developer would use to build a WordPress site. You'll even have shareable demo URLs allowing you to show your site to clients, collaborators, or friends, and you can have customizable environments for developers. This helps you configure the way your local site runs. Revolutionize your WordPress workflow and download local by Flywheel for free today on Mac, Windows, or Linux. Head over to localbyflywheel.com. It's localbyflywheel.com. Thanks again to Flywheel for sponsoring today's episode of Developer Tea. Now what do we mean when we say, Justifyability? How do we justify the work that we do? When we think about justification, what we're really talking about is equalizing the reasons that we do something with the investment necessary to do that thing. That is the justice portion of justification. And justice meaning, or simply equalizing one side to the other. The amount that we are investing in the thing is justified by the reasons that we're doing that investment in the first place. I'm going to give you a very simple framework that you can use for figuring out what types of work are justifiable. And this is based on the concept of user stories. And most developers are probably at this point familiar with this concept, but for those of you who are not familiar with it, I encourage you go and do a little bit of research on this. Google user stories, you might find some resources that point you to the agile methodology, but user stories are useful outside of software development. They're useful as a thinking model. And the thinking model is very simple. It follows some variation of a statement, and the statement sounds like this. As a, and then you'll have a blank, you fill in the blank with a role, as a role, I want to, and then you fill in the blank with an action as a role, I want to action so that or because, and then another blank, this blank is whatever value this particular role gets out of that action. So as a user, I want to do something so that I benefit in this particular way. That is the format of this user story. And the roles that you define, the roles that you use for user stories, if you can predetermine the roles that matter to what you're trying to do with your software. And then here's the focus that you want to have. You want to have the roles and then have the motivations, skip over the actions initially. So you're going to have roles and motivations. Motivations might be very simple like increasing revenue for my company as a CEO, the role being the CEO and the motivation being increasing revenue, or they may be much more complex or nuanced. Most motivations can be traced to lower level motivations like for example, as a system administrator, I want the system to be more reliable so that I don't have calls coming to my phone at 2 a.m. every night. And the reason I don't want calls coming to my phone every night at 2 a.m. is because I want to sleep and I want to sleep because I want to be healthy and I want to be healthy because ultimately I want to survive. Now you don't have to trace every single user story back to the core motivation, the survival instinct motivation. But it's useful to keep that in mind. If you ever want to kind of trace whether or not a motivation is valid, find that lower level motivation. Even if you go one layer or two layers deep, you can use something like the five whys. Why do, why does a particular role have that motivation and you'll uncover the lower level motivations and that helps validate those lower level motivations. What you might find is that you assume that a motivation exists but you can't really justify the motivation itself. So what you'll end up with is a list of roles and a list of motivations for each of those roles. And then you can determine the actions that might fulfill the motivations or might serve the motivations. So as a customer, I want the interface that I'm using to be fast so that I'm not wasting my time waiting for the interface to catch up to me. These are the kinds of stories that can help justify the time that you spend on even the smallest types of features. One key factor here is that this isn't a silver bullet. User stories can be wrong. They can be wrong about the motivation and perhaps more importantly, wrong about the actions needed to fulfill that motivation. This is where team collaboration and having a really strong product backbone on your team – someone who's a product owner or someone who's doing user research, usability research. These are how you validate whether or not a role, a motivation and an action are all properly aligned. I hope this episode was useful to you. If it was, I encourage you to subscribe in whatever podcasting app you're currently using but also share this episode with someone you think will find it valuable as well. You sharing this directly with another person is the easiest way to help Developer Tea reach new audiences and ultimately keep on doing what we're doing here. Today's episode wouldn't be possible without our sponsor, Flywheel. If you're a WordPress developer and you haven't found a good local development solution, encourage you go and check out local by Flywheel. That's localbyflywheel.com. Every episode of Developer Tea including this one can be found at spec.fm. Spec is the network built specifically for designers and developers who are looking to level up in their careers and that includes you head over to spec.fm to find other shows that are built specifically for you. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.