In today's episode of Developer Tea, I talk about features your application doesn't need (at least for now). This episode is focused mostly towards early application development, but we discuss a few things that are completely relevant to later stage applications as well. Today's episode is sponsored by Linode! Head over to Linode.com/developertea or use the code DeveloperTea20 at checkout for a $20 credit towards your cloud hosting account!
In today's episode of Developer Tea, I talk about features your application doesn't need (at least for now). This episode is focused mostly towards early application development, but we discuss a few things that are completely relevant to later stage applications as well.
Today's episode is sponsored by Linode! Head over to Linode.com/developertea or use the code DeveloperTea20 at checkout for a $20 credit towards your cloud hosting account! Thanks again to Linode for your support of Developer Tea.
Hey everyone, and welcome to Developer Tea. My name is Jonathan Cottrell, and in today's episode, we're going to be talking about features that you don't need. There are so many startups, so many applications, and so many of you who are building these things that are in their early stages. And there are a lot of features that they come across the idea board. And there are many that you very well, you could need them. They could be fundamentally important to your business and to the success of whatever project it is that you are working on. But there are also quite a few that are totally invalid. They're totally unnecessary. You shouldn't spend your time or your energy on them. And quite honestly, you certainly shouldn't spend money on them. And we're going to talk about a few of those today. Today's episode is sponsored by Linode. On Linode, you can instantly deploy and manage your solid state drive server in the Linode cloud. You can get a server running in just a few seconds with your choice of Linux distribution, resources, and node location. We will talk much more about Linode later on in today's episode. But first, I want to jump into today's topic, features you don't need, at least for now. You see, designers and developers alike, they tend to assume the need for features, features that aren't necessarily urgent in the early stage of development, or even in the early stages, multiple stages of development. Multiple iterations can go by without you needing some of these features. And today we're going to talk about three of those. Let's jump straight into the first feature. The first feature is granular permissions and access control. Now, I've talked about this in the past, but the reality is a lot of companies, they try to mirror, their corporate structure. They try to mirror their corporate ladder structure, the way that each of the management levels, all the way from the CEO down to the part-time employees, or the lowest level brand new hires. And they try to mirror that in their software. And this can cause a lot of complexity and a lot of problems that really can be avoided pretty easily. The truth is, if we try to model our corporate, corporate structure in our software, then we end up with multiple levels that effectively need to be able to do the same types of things. And it can be difficult to try to separate these two concepts out because our brains are already wired to think in the way that the corporate structure of the particular agency or the particular client that you're building for is already built. So it's difficult to create some application, some software structure, some database structure, that models a different reality than what you see in front of you. But instead of thinking of job titles, and instead of thinking of corporate ladder and corporate structure, start thinking about the permissions that are necessary for each different level of person in that organization. So for example, you may have a manager and you may have a co-manager, and then you may have a shift manager, and then you have individual managers, of that particular shift in different areas. Let's say if you're modeling a restaurant corporate structure, you may have different areas of that restaurant and different people who are in charge of those areas. And then you may have a cashier and a table busser. If you were to look at all of the different actions that each of these different people perform, there are very few actions that a area manager in a restaurant would perform, that are above the head of the table busser or above the head of the cashier. In fact, you may be able to reduce that structure from three or four different roles to one or two different roles. Maybe there is somebody who has access to the cashier after hours and someone who doesn't. The problem is a lot of organizations make the mistake of trying to separate out these different permissions based on the granular job titles that these different people have. Instead of thinking about the actions that the different people take in the organization. So that's kind of the first tip, the first takeaway, and also the first feature you don't need. You don't need to mirror your organizational structure in your application. Instead, focus on the actions or the class of actions, the multiple actions that different classes of people in your organization take, and create roles, based on those actions. Don't create vanity roles, but create roles that are based on permissions to perform different actions. Now with that, we're going to take a quick sponsor break and talk about Linode. We said before that Linode allows you to instantly deploy and manage your SSD server in the Linode cloud. You can get a server running in seconds with your choice of Linux distribution and the node location of that distribution. At the end of the day, of that server rather. They have eight data centers. Their plans start at just $10 a month. That's just like two or three coffees, depending on where you live. Hourly billing, they have a monthly cap on all of their plans. And that includes add-on services. The monthly cap applies to add-on services. So you get backups, node balancers, and long view. They have virtual machines for full control. You can spin up a Docker container. You can have an encrypted disk. You can even create a VPN on the Linode network. You can run a private Git server even. They have native SSD storage. They have a 40 gigabit network. That is massively fast. They have Intel E5 processors, and they have a seven-day money-back guarantee. Now, the best part is Linode has provided a very special link and a promo code to Developer T listeners. That code is DEVELOPERT20. And the link is linode.com slash DEVELOPERT. Both of those, of course, will be in the show notes. But that gets you $20 of credit on Linode that is worth two months of service. And that's just because you are a Developer T listener. So go and check out the show notes at spec.fm. And you can find the special code DEVELOPERT20 as well as a special link, linode.com slash DEVELOPERT. Thank you so much for Linode. For sponsoring today's episode of Developer T. So today we are talking about features you do not need, or at least don't need them now, in the early stages of your startup. Now, maybe you are working at a company that is well beyond these stages. And of course, these don't necessarily apply to you, but they are still worthwhile to think about because there are features that you don't need. There are still some things that you could implement that you don't necessarily need to implement. Now, when I say need, really what I mean is there's not a compelling business reason to implement these features right now. There may be a compelling reason in the future. And there may have even been a compelling reason at a different company, but they may not necessarily apply to you, especially if you are in the early stages of a startup. There are so many different features that we could implement in early stages, such as early stage programs, and early stage applications that we don't necessarily need to implement until later stages. And the first one that we talked about was granular permissions control and the mirroring of your corporate structure in your application. This is totally unnecessary. Instead, you should be looking at the actual actions and the permissions to perform those actions that different people in your organization should be able to be granted. Instead of trying to absolutely conform to your corporate structure, you look at those different actions that those people should be able to be granted and then create classes of actions, collections of actions that people typically fall in. This greatly reduces the complexity of your access control logic in whatever application you are creating. If you have complex access control logic, then you have to implement it in a much deeper way into your application. So the fewer roles that you can create in your application, the much faster you will be able to develop beyond those kind of access control logic pieces. The second feature that you don't need, especially in your early stage application, is combination filtering and smart search. In other words, let's say that you have a filter that your designer has, that shows you three or four different taxonomies, and let's say tags and categories, and maybe, you know, let's say you're selling tractors. You have tractor wheel sizes is another taxonomy. If you are creating this startup from the ground up and you're adding one tractor at a time, let's say you have five tractors when you launch the application, and you're going to have 20, by the end of the year, well, it's very, very unlikely that you will have many users who can get a lot of value out of filtering those tractors because most of those users will be able to comprehend five to 10 items at a time. So you get a lot of the same benefit out of simply displaying those five to 10 items in a clear enough way that those users can see the things that they need to see within the five to 10 items, and perhaps you have a second page of items that allows them to see in a second view the total catalog of all items that your application represents. The need to search and filter data becomes more and more pressing the more data you have in the system. Now, if you launch this system with thousands of items, then obviously this particular feature may be going to be a little bit more expensive, more important to you than it is for the next person. But I would encourage you to ask your users how they intend to find the different elements of content on your particular application. Whether it's an iPhone application or a web application, it doesn't really matter. The way that those users are trying to surface different pieces of content in your application may not be the ways that you expect them to surface those pieces of content. It's important that you do not make costly assumptions about your users' behavior. I'm going to say that again because this is the one quote that I want you to take away from today's episode. It is incredibly important that you do not make costly assumptions about your users' behavior. And what does this mean? Well, basically it means that you shouldn't try to implement features that are unnecessarily complex until you know that those features are going to provide a strategic, measurable, and unmistakable value to your user base. You shouldn't do this blindly. The things that you should do experimentally should be ways of looking into the future. In other words, you should try small versions of these features instead of trying combination filters, try allowing a single filter. Instead of trying complex search, try allowing simple search. By limiting the number of features that you have and the complexity of features that you introduce in the early stages of your application, you provide the users the opportunity to give you feedback for the features that they really want. And this is fundamental to creating a system that is valuable for your users. Most of the time, you are not going to have an idea that is so fundamentally important, but also fundamentally complicated, that it is incredibly valuable and is absolutely necessary for the success of your application. In other words, you can find these really valuable interactions, you can find these really valuable features by performing some level of testing on much simpler versions of those features. So instead of bringing these these these pl features. So instead of making really expensive assumptions about your user base, ask them what they want and measure their interactions in your application to derive assumptions about what they may want based on their behavior in your application. Smart filtering and combination filtering and really complicated search queries, those are things that can be very expensive. As a developer, those things can take a lot of your time. So make sure that you filter all of those decisions through the data that you have, through the research that you have, and also realize that the amount of data that you have or the amount of information, the amount of content that you have in your application may completely cut out some of these features until well into the future when you do have more content. Now the final idea item on the list, the final feature that you don't necessarily need when you first launch, and I would say this is probably the hardest one to say that you don't need as a developer, is an API. Now we as developers, we would prefer that everybody launch with an API so that as early as possible I can start integrating with your thing, right? I want to integrate my code with your platform as soon as possible so I can start testing it out. Maybe I want to play with your platform over the weekend and I want to try out a few things in my code base. And the reality is this doesn't provide a business level objective, a business level strategic advantage as quickly as another feature might, unless your platform is primarily targeted towards developers. At that point, I highly recommend that you priority your platform with an API. Now the final idea item on the list, the final feature that you don't necessarily need as a developer, is an API. And the reality is this doesn't provide a business level objective, a business level strategic advantage as quickly as another feature might, unless your platform is primarily targeted towards developers. At that point, I highly recommend that you priority your platform with an API. Now the final idea item on the list, the final feature that you don't necessarily need as a developer, is an API. And the reality is this doesn't provide a business level objective, a business level strategic advantage as quickly as another feature might, unless your platform is primarily targeted towards developers. At that point, I highly recommend that you priority your platform with an API. Now the final idea item on the list, the final feature that you don't necessarily need as a developer, is an API. And the reality is this doesn't provide a business level objective, a business level strategic advantage as quickly as another feature might, unless your platform is primarily targeted towards developers. At that point, I highly recommend that you priority your platform with an API. Now the final idea item on the list, the final feature that you don't necessarily need as a developer, is an API. And the reality is this doesn't provide a business level strategic advantage as quickly as another feature might, unless your platform is primarily targeted towards developers. At that point, I highly recommend that you priority your platform with an API. Now the final idea item on the list, the final feature that you don't necessarily need as a developer, is an API. And the reality is this doesn't provide a business level strategic advantage as quickly as another feature might, unless your platform is primarily targeted towards developers. At that point, I highly recommend that you priority your platform with an API. Now the final idea item on the list, the final feature that you don't necessarily need as a developer, is an API. And the reality is this doesn't provide a business level strategic advantage as quickly as another feature might, unless your platform is primarily targeted towards developers. At that point, I highly recommend that you priority your platform with an API. Now the final idea item on the list, the final feature that you don't necessarily need as a developer, is an API. And the reality is this doesn't provide a business level strategic advantage as quickly as another feature might, unless your platform is primarily targeted towards developers. At that point, I highly recommend that you priority your platform with an API.