Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell 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 Linode 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 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 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 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 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 hold 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 or of that server rather. They have eight data centers. Their plan 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 get 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 Tealisteners. That code is Developer Tea 20 and the link is linode.com slash Developer Tea. 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 Tealistener. Go and check out the show notes at spec.fm and you can find the special code Developer Tea 20 as well as a special link. Linode.com slash Developer Tea. Thank you so much for Linode for sponsoring today's episode of Developer Tea. 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. 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 stage programs, in 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 brought to you that shows you three or four different taxonomies. Let's say tags and categories and maybe 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. It's 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 ten items at a time. So you get a lot of the same benefit out of simply displaying those five to ten items in a clear enough way that those users can see the things that they need to see within the five to ten 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 the system with thousands of items then obviously this particular feature may be 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 user's 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 user's behavior. 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 in 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. 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. 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 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, as developers, we would prefer that everybody launch with an API so that as early as possible, I can start integrating with your thing. 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 prioritize an API, which kind of flips this particular point on its head for today's episode. But these are the kind of questions that you have to ask yourself, you know, who is this going to? Who is going to be the primary business case user for my particular application? Now, maybe you aren't doing B2B, maybe you're doing business to consumer applications. Who is the primary user of your consumer application? Who is the primary consumer? Maybe that is also a developer. A great example of this is if this than that. If this than that did not have a customized HTTP verb interface until way later than their launch. And the reason for this is because they wanted to target non-developers who were just now getting into the space who didn't really understand code. And instead, they wanted to easily connect all of their different devices and services. Now, they have introduced this channel because enough developers presumably have started using if this than that. And so they introduced the Maker channel. This allows you to post to a arbitrary endpoint when a particular action occurs. Now, I say all that not to teach you about if this than that, but instead to show you an example of a platform that could have easily implemented this particular kind of API-esque feature. But instead, they chose to focus on their core features for their core users. So it is very possible and perhaps likely that you don't need an API in the early stages of your application. Now, I would recommend that you do put it on your roadmap that if you plan to make your application available to the general public and if you plan to accomplish reaching a development audience at all that you include the opportunity for Developer To integrate with your platform at a very simple level. Even if it is a read-only API, I think APIs are incredibly important, but I don't think that you necessarily have to launch your product with an API in place unless that product is specifically for developers. Thank you for listening to today's episode. I hope you have enjoyed this episode of Developer Tea. Thank you to today's sponsor, Linode.com. You can get a cloud server launched on Linode in under a minute. They have a ton of features that you should check out at Linode.com. But of course, perhaps the most important thing for Developer Tea listeners is that they are providing you with $20 of credit just by using the special link that you can find in the show notes at speck.fm. You can also use the special code that they have provided for Developer Tea listeners at Developer Tea 20 Developer Tea and then the numbers 2 and 0 Developer Tea 20. Go and check it out Linode.com $20 of credit just for Developer Tea listeners. Thank you again to Linode for sponsoring today's episode of Developer Tea. And until next time, enjoy your tea.