Vox

Leitura de 20 min

Features You Don’t Need (At Least For Now)

Summary

In this episode of Developer Tea, host Jonathan Cottrell addresses a common pitfall in software development: implementing features that aren’t necessary, especially in the early stages of a startup or application. He argues that developers and designers often assume the need for certain features that add complexity without providing immediate business value, slowing down development and potentially misaligning with user needs.

The episode focuses on three specific features that are frequently over-engineered. First, granular permissions and access control systems that attempt to mirror corporate hierarchy. Cottrell explains that instead of modeling job titles and organizational ladders, developers should focus on the actual actions users need to perform. By creating roles based on permission classes rather than vanity titles, applications can maintain simpler, more maintainable access control logic.

Second, Cottrell discusses combination filtering and complex search features. He suggests that for applications with limited initial content (like a startup with only 5-20 items), users can typically comprehend the available items without sophisticated filtering. The key insight is to avoid making costly assumptions about user behavior and instead implement simpler versions of features, gathering user feedback before investing in complex implementations.

Finally, the episode examines whether early-stage applications need to launch with a full API. While developers naturally want APIs for integration, Cottrell argues that unless the platform specifically targets developers as its primary audience, an API may not provide immediate business value. He cites If This Then That as an example of a platform that successfully delayed API development to focus on core features for its initial user base.

Throughout the discussion, Cottrell emphasizes the importance of validating feature necessity through user research and behavioral data rather than assumptions. The overarching message is to prioritize features that provide clear, measurable value to users while avoiding unnecessary complexity that can slow development and increase maintenance costs.

Recommendations

Tools

  • Linode — A cloud hosting service that allows instant deployment and management of SSD servers with various Linux distributions, data center locations, and features like Docker containers, VPNs, and Git servers. Mentioned as the episode’s sponsor with a special offer for listeners.
  • If This Then That (IFTTT) — An automation platform mentioned as an example of a service that delayed implementing a full API until later in its development, focusing instead on core features for non-developer users before introducing the maker channel for developers.

Topic Timeline

  • 00:00:00 — Introduction to unnecessary features in early-stage development — Jonathan Cottrell introduces the episode’s theme: features that startups and early-stage applications often implement but don’t actually need. He explains that while some features are fundamentally important, many are unnecessary and waste time, energy, and money. The episode will focus on identifying and avoiding these non-essential features during initial development phases.
  • 00:01:43 — First unnecessary feature: Granular permissions mirroring corporate structure — Cottrell discusses the first feature to avoid: complex permission systems that try to mirror corporate hierarchy. He explains that attempting to model job titles and management levels in software creates unnecessary complexity. Instead, developers should focus on the actual actions users need to perform and create permission classes based on those actions, not organizational charts.
  • 00:05:04 — Sponsor break: Linode cloud hosting service — The episode takes a sponsor break to discuss Linode, a cloud hosting service. Cottrell details Linode’s features including SSD servers, multiple data centers, hourly billing with monthly caps, and various add-on services. He shares a special offer for Developer Tea listeners: $20 credit using code DEVELOPERT20 or visiting linode.com/DEVELOPERT.
  • 00:09:07 — Second unnecessary feature: Complex combination filtering and search — Cottrell presents the second feature to avoid: sophisticated filtering and search systems in early-stage applications. He argues that when you have limited content (5-20 items), users don’t need complex filtering. The key takeaway is to avoid making costly assumptions about user behavior and instead implement simpler features, then gather feedback before investing in complex implementations.
  • 00:14:15 — Third unnecessary feature: Launching with a full API — The final feature discussed is launching with a complete API. Cottrell acknowledges that developers naturally want APIs for integration, but argues they often don’t provide immediate business value unless the platform specifically targets developers. He uses If This Then That as an example of a platform that successfully delayed API development to focus on core features for initial users.
  • 00:17:34 — Conclusion and sponsor acknowledgment — Cottrell concludes the episode by summarizing the three unnecessary features and reiterating the importance of focusing on core functionality. He thanks sponsor Linode again, reminding listeners about the $20 credit offer for Developer Tea listeners, and encourages them to check out the show notes for details.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2016-01-15T08:00:00Z
  • Duration: 00:18:32

References

Podcast Info

Transcript

[00:00:00] 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.

[00:00:12] There are so many startups, so many applications, and so many of you who are building these things that are in their early stages.

[00:00:20] 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.

[00:00:30] They could be fundamentally important to your business and to the success of whatever project it is that you are working on.

[00:00:37] But there are also quite a few that are totally invalid. They’re totally unnecessary.

[00:00:43] You shouldn’t spend your time or your energy on them and quite honestly you certainly shouldn’t spend money on them.

[00:00:49] And we’re going to talk about…

[00:00:50] We’re going to talk about a few of those today.

[00:00:52] Today’s episode is sponsored by Linode.

[00:00:55] On Linode you can instantly deploy and manage your solid state drive server in the Linode cloud.

[00:01:02] You can get a server running in just a few seconds with your choice of Linux distribution, resources, and node location.

[00:01:10] We will talk much more about Linode later on in today’s episode.

[00:01:13] But first I want to jump into today’s topic.

[00:01:16] Features you don’t need, at least for now.

[00:01:20] 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.

[00:01:30] Or even in the early stages, multiple stages of development.

[00:01:34] Multiple iterations can go by without you needing some of these features.

[00:01:38] And today we’re going to talk about three of those.

[00:01:40] Let’s jump straight into the first feature.

[00:01:43] The first feature is granular permissions and access control.

[00:01:47] Now I’ve talked about this in the past.

[00:01:50] But the reality is a lot of companies, they try to mirror their corporate structure.

[00:01:58] They try to mirror their corporate ladder structure.

[00:02:01] The way that each of the management levels, all the way from the CEO down to the part-time employees.

[00:02:08] Or the lowest level, brand new hires.

[00:02:11] And they try to mirror that in their software.

[00:02:14] And this can cause a lot of complexity and a lot of problems that really can be avoided.

[00:02:20] The truth is, if we try to model our corporate structure in our software,

[00:02:27] then we end up with multiple levels that effectively need to be able to do the same types of things.

[00:02:34] And it can be difficult to try to separate these two concepts out because

[00:02:38] our brains are already wired to think in the way that the corporate structure of the particular agency

[00:02:44] or the particular client that you’re building for is already built.

[00:02:49] So it’s difficult.

[00:02:50] It’s difficult to create some application, some software structure, some database structure

[00:02:55] that models a different reality than what you see in front of you.

[00:02:59] But instead of thinking of job titles and instead of thinking of corporate ladder and corporate structure,

[00:03:05] start thinking about the permissions that are necessary for each different level of person in that organization.

[00:03:14] So for example, you may have a manager and you may have a co-manager.

[00:03:19] And then you may have a boss.

[00:03:20] And then you may have a manager.

[00:03:20] And then you may have a co-manager.

[00:03:20] And then you may have a manager.

[00:03:20] may have a shift manager, and then you have individual managers of that particular shift

[00:03:27] in different areas. Let’s say if you’re modeling a restaurant corporate structure, you may have

[00:03:33] different areas of that restaurant and different people who are in charge of those areas. And then

[00:03:38] you may have a cashier and a table busser. If you were to look at all of the different actions that

[00:03:45] each of these different people perform, there are very few actions that a area manager in a

[00:03:52] restaurant would perform that are above the head of the table busser or above the head of the

[00:03:59] cashier. In fact, you may be able to reduce that structure from three or four different roles

[00:04:04] to one or two different roles. Maybe there is somebody who has access to the cashier after

[00:04:10] hours and someone who doesn’t. The problem is a lot of organizations

[00:04:15] make a shift manager and a table busser, but they don’t have the ability to do that.

[00:04:15] They make the mistake of trying to separate out these different permissions based on the granular

[00:04:22] job titles that these different people hold instead of thinking about the actions that the

[00:04:27] different people take in the organization. So that’s kind of the first tip, the first takeaway,

[00:04:34] and also the first feature you don’t need. You don’t need to mirror your organizational

[00:04:39] structure in your application. Instead, focus on the actions or the class of

[00:04:45] actions that you’re doing. And if you’re doing that, then you’re going to have to

[00:04:45] think about the multiple actions that different classes of people in your organization take

[00:04:51] and create roles based on those actions. Don’t create vanity roles, but create roles that are

[00:04:58] based on permissions to perform different actions. Now, with that, we’re going to take a quick

[00:05:04] sponsor break and talk about Linode. We said before that Linode allows you to instantly deploy

[00:05:10] and manage your SSD server in the Linode cloud. You can get a server that’s going to be able to

[00:05:15] running in seconds with your choice of Linux distribution and the node location of that

[00:05:22] server. They have eight data centers. Their plans start at just $10 a month. That’s just like two or

[00:05:31] three coffees, depending on where you live. Hourly billing, they have a monthly cap on all of their

[00:05:36] plans, and that includes add-on services. The monthly cap applies to add-on services, so you

[00:05:42] get backups, node balancers, and long view. You can also get a monthly cap on all of your services,

[00:05:45] and that includes add-on services. The monthly cap applies to add-on services, so you get backups,

[00:05:45] They have virtual machines. For full control, you can spin up a Docker container. You can have

[00:05:51] an encrypted disk. You can even create a VPN on the Linode network. You can run a private

[00:05:58] Git server, even. They have native SSD storage. They have a 40 gigabit network. That is massively

[00:06:05] fast. They have Intel E5 processors, and they have a seven-day money-back guarantee. Now,

[00:06:13] the best part is Linode has provided…

[00:06:15] …a very special link and a promo code to DeveloperT listeners. That code is DEVELOPERT20,

[00:06:23] and the link is linode.com slash DEVELOPERT. Both of those, of course, will be in the show notes,

[00:06:29] but that gets you $20 of credit on Linode. That is worth two months of service, and that’s just

[00:06:37] because you are a DeveloperT listener. So go and check out the show notes at spec.fm,

[00:06:42] and you can find the special code,

[00:06:45] DEVELOPERT20, as well as a special link, linode.com slash DEVELOPERT. Thank you so much

[00:06:51] for Linode for sponsoring today’s episode of DeveloperT. So today, we are talking about

[00:06:57] features you do not need, or at least don’t need them now, in the early stages of your startup.

[00:07:04] Now, maybe you are working at a company that is well beyond these stages, and of course,

[00:07:09] these don’t necessarily apply to you, but they are still worthwhile to think about because

[00:07:15] features that you don’t need, there are still some things that you could implement that you

[00:07:20] don’t necessarily need to implement. Now, when I say need, really what I mean is there’s not

[00:07:26] a compelling business reason to implement these features right now. There may be a compelling

[00:07:34] reason in the future, and there may have even been a compelling reason at a different company,

[00:07:40] but they may not necessarily apply to you, especially if you are in the

[00:07:45] early stages of a startup. There are so many different features that we could implement

[00:07:50] in early stage programs, in early stage applications that we don’t necessarily

[00:07:56] need to implement until later stages. And the first one that we talked about was granular

[00:08:01] permissions control and the mirroring of your corporate structure in your application. This

[00:08:08] is totally unnecessary. Instead, you should be looking at the actual actions and the

[00:08:15] conditions to perform those actions that different people in your organization should be able to be

[00:08:21] granted. Instead of trying to absolutely conform to your corporate structure, you look at those

[00:08:27] different actions that those people should be able to be granted, and then create classes of

[00:08:32] actions, collections of actions that people typically fall in. This greatly reduces the

[00:08:40] complexity of your access control logic in whatever application you’re working in.

[00:08:45] If you have complex access control logic, then you have to implement it in a much deeper way

[00:08:53] into your application. So the fewer roles that you can create in your application, the much faster

[00:08:59] you will be able to develop beyond those kind of access control logic pieces. The second feature

[00:09:07] that you don’t need, especially in your early stage application, is combination filtering and

[00:09:15] search. In other words, let’s say that you have a filter that your designer has brought to you

[00:09:22] that shows you three or four different taxonomies. Let’s say tags and categories,

[00:09:30] and maybe, you know, let’s say you’re selling tractors. You have tractor wheel sizes is another

[00:09:37] taxonomy. If you are creating this startup from the ground up, and you’re adding one tractor at a time,

[00:09:45] let’s say you have five tractors when you launch the application, and you’re going to have 20 by

[00:09:51] the end of the year. Well, it’s very, very unlikely that you will have many users who can get a lot of

[00:09:58] value out of filtering those tractors, because most of those users will be able to comprehend

[00:10:06] five to 10 items at a time. So you get a lot of the same benefit out of simply displaying those

[00:10:15] five to 10 items in a clear enough way that those users can see the things that they need to see

[00:10:22] within the five to 10 items. And perhaps you have a second page of items that allows them to see

[00:10:28] in a second view, the total catalog of all items that your application represents. The need to

[00:10:37] search and filter data becomes more and more pressing, the more data you have in the system.

[00:10:44] Now, if you launch a system, you’re going to have a lot of data that you’re going to need to filter.

[00:10:45] If you launch the system with thousands of items, then obviously this particular feature

[00:10:50] may be more important to you than it is for the next person. But I would encourage you

[00:10:55] to ask your users how they intend to find the different elements of content on your particular

[00:11:04] application. Whether it’s an iPhone application or a web application, it doesn’t really matter.

[00:11:09] The way that those users are trying to surface different pieces of content in your application

[00:11:15] may not be the ways that you expect them to surface those pieces of content. It’s important

[00:11:21] that you do not make costly assumptions about your user’s behavior. I’m going to say that again

[00:11:28] because this is the one quote that I want you to take away from today’s episode. It is incredibly

[00:11:34] important that you do not make costly assumptions about your user’s behavior. And what does this

[00:11:41] mean? Well, basically it means that you shouldn’t try to implement the same thing over and over again.

[00:11:45] You shouldn’t try to implement features that are unnecessarily complex until you know that those

[00:11:50] features are going to provide a strategic, measurable, and unmistakable value to your

[00:11:59] user base. You shouldn’t do this blindly. The things that you should do experimentally should

[00:12:05] be ways of looking into the future. In other words, you should try small versions of these

[00:12:11] features instead of trying combination filters.

[00:12:15] Try allowing a single filter. Instead of trying complex search, try allowing simple search. By

[00:12:22] limiting the number of features that you have and the complexity of features that you introduce in

[00:12:27] the early stages of your application, you provide the users the opportunity to give you feedback

[00:12:34] for the features that they really want. And this is fundamental to creating a system that is

[00:12:40] valuable for your users. Most of the time, you are not going to have an idea,

[00:12:45] that is so fundamentally important, but also fundamentally complicated, that it is

[00:12:52] incredibly valuable and is absolutely necessary for the success of your application. In other words,

[00:13:00] you can find these really valuable interactions, you can find these really valuable features

[00:13:07] by performing some level of testing on much simpler versions of those features.

[00:13:13] So instead of making

[00:13:15] really expensive assumptions about your user base, ask them what they want and measure their

[00:13:23] interactions in your application to derive assumptions about what they may want based on

[00:13:30] their behavior in your application. Smart filtering and combination filtering and

[00:13:36] really complicated search queries, those are things that can be very expensive. As a developer,

[00:13:43] those things can,

[00:13:45] take a lot of your time. So make sure that you filter all of those decisions through the data

[00:13:51] that you have, through the research that you have, and also realize that the amount of data

[00:13:57] that you have or the amount of information, the amount of content that you have in your

[00:14:02] application may completely cut out some of these features until well into, well into the future

[00:14:09] when you do have more content. Now, the final item on the list, the final feature that you

[00:14:15] don’t necessarily need when you first launch, and I would say this is probably the hardest one to say

[00:14:21] that you don’t need as a developer, is an API. Now, we as developers, we would prefer that everybody

[00:14:29] launch with an API so that as early as possible, I can start integrating with your thing, right?

[00:14:37] I want to integrate my code with your platform as soon as possible so I can start testing it out.

[00:14:44] Maybe I want to,

[00:14:45] play with your platform over the weekend, and I want to try out a few things in my code base.

[00:14:51] And the reality is, this doesn’t provide a business level objective, a business level

[00:14:58] strategic advantage as quickly as another feature might, unless your platform is primarily

[00:15:06] targeted towards developers. At that point, I highly recommend that you prioritize an API,

[00:15:13] which kind of flips,

[00:15:15] this particular point on its head for today’s episode. But these are the kind of questions

[00:15:20] that you have to ask yourself. You know, who is this going to? Who is going to be the primary

[00:15:26] business case user for my particular application? Now, maybe you aren’t doing B2B, maybe you’re

[00:15:32] doing business to consumer applications. Who is the primary user of your consumer application?

[00:15:38] Who is the primary consumer? Maybe that is also a developer. A great example of this is

[00:15:44] If This Then That.

[00:15:45] If This Then That did not have a customized HTTP verb interface until way later than their launch.

[00:15:55] And the reason for this is because they wanted to target non-developers who were just now getting

[00:16:00] into the space, who didn’t really understand code. And instead, they wanted to easily connect

[00:16:06] all of their different devices and services. Now they have introduced this channel because

[00:16:13] enough developers, presumably,

[00:16:15] have started using If This Then That. And so they introduced the maker channel. This allows you to

[00:16:20] post to a arbitrary endpoint when a particular action occurs. Now, I say all that not to teach

[00:16:28] you about If This Then That, but instead to show you an example of a platform that could have

[00:16:33] easily implemented this particular kind of API-esque feature. But instead, they chose to

[00:16:40] focus on their core features for their core users.

[00:16:45] So it is very possible and perhaps likely that you don’t need an API in the early stages of your

[00:16:52] application. Now, I would recommend that you do put it on your roadmap. That if you plan to make

[00:16:59] your application available to the general public, and if you plan to accomplish reaching a

[00:17:07] development audience at all, that you include the opportunity for developers to integrate with your

[00:17:14] platform.

[00:17:15] At a very simple level, even if it is a read-only API, I think APIs are incredibly important. But I

[00:17:21] don’t think that you necessarily have to launch your product with an API in place unless that

[00:17:27] product is specifically for developers. Thank you for listening to today’s episode. I hope you have

[00:17:34] enjoyed this episode of Developer Tea. Thank you to today’s sponsor, Linode.com. You can get a cloud

[00:17:41] server launched on Linode in under a minute.

[00:17:45] They have a ton of features that you should check out at Linode.com. But of course, perhaps the most

[00:17:51] important thing for Developer Tea listeners is that they are providing you with $20 of credit

[00:17:55] just by using the special link that you can find in the show notes at spec.fm. You can also use

[00:18:02] the special code that they have provided for Developer Tea listeners. That’s Developer Tea

[00:18:07] 20. Developer Tea and then the numbers two and zero. Developer Tea 20. Go check it out. Linode.com.

[00:18:15] $20 of credit just for Developer Tea listeners. Thank you again to Linode for sponsoring

[00:18:20] today’s episode of Developer Tea. And until next time, enjoy your tea.

Visão de gráfico