Don't build useless features

Counterpoint: build useless features.<p>Sometimes your CEO doesn&#x27;t completely trust the development team. Sometimes the client wants to make sure the vendor really values them. Sometimes the head of sales decides to take a punt on something that has a small chance of a big impact.<p>As a development team, the best thing you can do in each of these cases is to build the useless feature. Build it properly, but build it with a minimum of effort, and be ready to retire it and delete the code when it turns out to be useless.<p>Earn the CEO&#x27;s trust. Reassure the client. Throw the dice. There are payoffs to work other than value for the end user.

Here is a recipe for a useless feature:<p>- You have a group chat and collaboration product that supports multi-way audio and video calls between individuals, as well as channel calls (calls visible to a channel that channel members can join).<p>- Somehow this is not enough, so you invent a new word for group calls: &quot;huddle&quot;. Unfortunately, you then also implement it.<p>- &quot;Huddle&quot; has different UI. Starting a huddle, joining and leaving are different, but it&#x27;s exactly like group call.<p>- &quot;Huddle&quot; doesn&#x27;t honor &quot;call&quot; preferences like &quot;start with microphone muted&quot;.<p>- This is not bungled up enough, so then you change the &quot;Start a call&quot; button on a channel to bring up a pop up menu whose first element is &quot;Start a huddle&quot;. Starting a call is the second item, whose menu label is ... the product name rather than &quot;Start a call&quot;.<p>- So now users expected to start a group call are accidentally starting huddles, which some team members don&#x27;t notice because they are looking for a call notification.

YAGNI is such a great principle. I can&#x27;t emphasize this enough.<p>I once inherited a messed-up codebase. The project started to solve the company&#x27;s internal problem for the sales department, but they also wanted it as a complete SaaS. So the former team implemented features like complex user management, request slotting, billing, etc.<p>It turned out that it required a lot of development time and money, and if they continued, they would fail to provide essential features to the original customer, the sales department. So they decided to stop implementing features for SaaS but didn&#x27;t remove them (because we&#x27;ll need them later! Of course..).<p>Then I joined the team and helped develop and fix bugs. It was a complete nightmare. Every time I fixed something, somewhere I didn&#x27;t know even it existed broke, and it somehow affected essential features. No test (because why waste dev time), so I found it in the staging or sometimes in the production (the good thing was, almost no one used it, so it didn&#x27;t matter).<p>Most members and the product owner agreed it was better to remove all unused features, but no one didn&#x27;t want to spend their time cleaning such a mess. So we continued to develop with all unnecessary features, paying attention not to break something implemented long ago, and no one knows why. I left the team and don&#x27;t know how it goes now.

There&#x27;s nothing more disheartening than spending a great deal of time and effort building something that absolutely no one uses or even wants.

On the other hand, when I worked at Data I&#x2F;O I proposed building a VT52 terminal emulator that ran on an IBM PC. With an RS-232 cable, it could then talk to any device that expected a terminal (like Data I&#x2F;O&#x27;s devices), and transfer files back and forth.<p>They told me it would be a waste of time, as there were commercial products that did it that were 100-200K.<p>I built it anyway as a rogue product. It was only 5K of assembler. It started getting passed around at work, and then the salesmen picked it up and made copies to give their customers. It made the sale easier because the customer didn&#x27;t have to go buy one of the commercial ones. And it being ridiculously tiny just made it a no-brainer.<p>Data I&#x2F;O finally made it an official product.

I would recommend against selling ahead of the Dev team. Sales is not research, and if you have effective sales people you will find that they can and will unintentionally sell vapor that cannot be delivered. Customers don’t generally buy features and specs, they buy hopes and feelings. It’s not the sales team’s fault, but it’s easy to successfully sell hopes and feelings and then still not know what the dev team is supposed to be building.

&gt;Don’t launch a product until you’ve put a prototype in front of a few customers and gotten feedback. Make sure that they say that they’ll find value in it – key questions include things like “how would you use this feature?”<p>I (and several others) found that it doesn&#x27;t always work. There&#x27;s a gap between &quot;I&#x27;d hypothetically use it&quot; and &quot;I will actually use it&quot;. It&#x27;s often the case that, when asked if they&#x27;d use a certain feature, potential customers often say &quot;yes&quot; but when the time comes around to actually using the feature&#x2F;product, no one suddenly cares. I&#x27;ve seen several articles describing this interesting phenomenon, but I can&#x27;t find the links.

This is one of my biggest frustrations.<p>Specifically building something half way that everyone is sure is important but when I talk to the customer the use case really is more expansive &#x2F; only useful if this is a much larger thing.<p>The whole thing is leading up to “Why can we do X here too?”<p>Like yeah I agree but unifying all that is 5x more work and not what anyone asked … they said no when I asked.<p>Result is nobody uses it, the question endlessly comes up.

Few problem with this approach:<p>- first customers of iterative release is a very small sample size and not always indicative for a larger market<p>- by building minimal versions, or selling products before they are build, you are always behind in development, causing lots of stress and presure on the dev team and increases the risk of releasing products that are unstable

My dad always said it succinctly: software no one uses is a piece of shit. Build things that someone can immediately use.

Sometimes you don&#x27;t know for sure but a feature will help you find out.<p>That said, it should be recognized that there is a &#x27;cost&#x27; to a feature aside from dev. - they can get in the way of other features.

I&#x27;m getting really tired of people spamming their uninteresting blogs on HN.

The CEO (at a small or medium sized company) should push back on these “demand” features. Sales will always ask for the moon, but they should sell what <i>is</i> not what the customer thinks they want. Have them send that info to marketing,

You often don’t know if the feature you are building is worth building or not. You might have a strong feeling either way but you don’t really <i>know</i>. You will only know after the feature has been exposed to customers. So adding a feature is a business risk. However taking risks is what running a business is all about. You make the best guess possible and try it out in the market place. And then you learn from feedback.

Ahh.. like &quot;App Uninstaller&quot; in raycast. Makes totally 0 sense

Poster child for useless features: MS Word &amp; Excel. Someone, sometime, asked for each feature, and they dutifully put it in.<p>I saw a tech writer&#x27;s post where ALL the toolbars of Word were expanded. It took up almost the entire vertical space. His point was &quot;you need really good tech writers to explain all this.&quot;<p>No, they needed some PMs to say No. There&#x27;s an overall cost to the collection of all the features, and it&#x27;s much more than the sum of each one. Maybe &quot;The Tragedy of the Commons&quot; explains it?