Published on | Prototyping: From UX to Front End — Medium Patrick V. Barrett Photo by Ben White on Unsplash

As a Product Manager, one of the most expensive decisions you have to make is determining what your dev team works on. There’s a team of highly-skilled, highly-compensated people waiting for you to tell them what to build. Depending on your location, team’s size and skill level you could be looking at a spend of $15,000 a day or more. Knowing the cost of an idle team can get PMs in a “feed the beast” mindset. If you’re not keeping your dev team busy you’re wasting money. Not wanting to have your developers twiddling their thumbs you might be tempted to have them work on features that aren’t 100% dev-ready.

Maybe it’s a feature that’s ill-defined. You haven’t spent enough time thinking about how it behaves in all the different real-world scenarios your users will put it through. You might be tempted to short-circuit your discovery process and customer validation. You may have the team get started on a feature that just “feels like the right thing to build” even though it hasn’t been properly vetted.

Don’t. Don’t do that.

Having a dev team sit idle is one of the most expensive mistakes you can make, but an idle dev team is nowhere near as expensive as actually building a feature. Building a feature will easily cost several times what your dev team does. Each feature you build creates a huge wake that affects your entire organization and colors how users experience your product. The features you build today will also severely limit what you can build tomorrow. Before you get your dev team started on an ill-defined or hastily-vetted feature consider the true cost you’re committing your company to spend. Even for clearly beneficial, well-defined features, you should be keeping these costs in mind.

What follows are some of the costs I think about when building a UI feature. Admittedly it’s an incomplete list and it’s definitely skewed by my background in product design. The definitive list of feature costs probably nears infinite items.

9 Costs of Building a Feature.

1. Opportunity cost: Aside from salaries this is probably the cost we’re most keenly aware of. What’s the value to your business of Thing Y you’re not building because you’re occupied building Thing X? What would have been the cost to Apple if instead of developing the iPhone the mid-2000s they worked on a high-end desktop gaming computer? It is almost incalculable. It’s hard to imagine a high-end gaming rig making up for the sales of 1 billion iPhones. Without the iPhone’s iOS would Apple have created and sold 300 million iPads? With no iPhone or iPad, there would be no App Store revenue. The Apple ecosystem would not nearly be as strong, so there would be fewer reasons to buy a Mac. The success of the iPhone and all it spawned represents a perfect example of the value a well-utilized and high-executing product team can provide. It also illustrates what you are potentially squandering when you point your team at the wrong problem.

2. User expectations: When your user sees a new feature in your product they have certain expectations. At a baseline, they’ll expect it will be well-thought-out, functional, and relatively bug-free. It should just work. They’ll also expect continuous iteration and improvement. They’ll have some expectation that their feedback will be heard. They’ll expect that the feature will be tweaked and its functionality expanded to suit their particular use case. User-driven iteration is key to building products your users will love, but it’s also a tax on your future productivity.

3. Future features, redesigns, and re-platforming: Your new feature is now part of your codebase. From this day forward everything you build needs to play nice with it. Ideally, you’ve built your product so each feature is sufficiently uncoupled from its neighbors; making changes to one has no effect on the others. Or maybe you don’t live in that ideal world. Now with every release, you run the risk of introducing regressions that will affect this feature. Even for those truly independent features a re-platform, refactor, or redesign means that’s one more thing to migrate from the old to the new. Ensuring your new feature continues to perform as you evolve is another productivity tax on every release.

4. Keeping up with external partner changes: There’s a good chance you’ve worked on a product that relied on 3rd party data or APIs. In my previous two roles, my companies focused on social and relied heavily on APIs from Twitter, Facebook, Instagram and other social networks. There was always this dread of waking up to discover a social network had made a breaking change to their APIs. Sometimes you get a sufficient heads up, sometimes you don’t. Sometimes they don’t tell you at all. I distinctly remember the fire drills caused by Instagram allowing non-square images, Facebook changing video formats, and Twitter switching image card aspect ratios. Simple things like changing from “favorite/stars” to “like/hearts” can have a significant impact on the product and be surprisingly time-consuming to fix. If your feature relies in any way on 3rd parties then at some point in the future you’re going to need to tweak that feature if you want it to continue to function. There is also a good chance you’ll have to pause on current feature development to make these unexpected changes, causing timelines to slip.

5. Training: There’s no UI feature so small that it won’t require at least some training for your prospect and customer-facing teams. Training could be a quick heads up Slack message or it could be an hour-long, hands-on group session. No one in sales likes to be surprised in the middle of a demo with an unexpected change in the UI. No one in support enjoys getting caught without an answer for the user asking what this new vaguely-labeled button does. When you release a feature you need to spend time creating and disseminating training materials. Even if it’s as simple as reading and understanding a launch email your Sales and Support teams will also have to bear the cost of being trained.

6. Support costs: The most well-designed feature still isn’t going to be completely intuitive to your entire user base, nor is it going to function as designed in every environment. Whatever you built is going to confuse some of your users enough that they’re going to reach out for help to your support team. Confuse enough user with your features and you might have to hire more support people.

7. PM SME time: Congratulations, that feature you just released, you’re now the world’s foremost authority on it. You are the subject matter expert (SME). With this distinction comes some new demands on your time. Answering RFPs, getting pulled into prospect and customer calls, webinars, blog posts, urgent late-night messages from colleagues who didn’t read the training materials you prepared. Adding a feature to your product means adding a feature to your SME support portfolio. That means you now have less time to do some other valuable thing like properly define and vet your future features.

8. UI opportunity cost: When adding a feature to your product it’s easy to just place it in the most obvious open place on the screen. Maybe you need to add a CTA for your knowledge base. The top right of your screen is wide open, so why not put the button there? Why not, because now no future feature can go there. Those pixels are gone. You spent them. Did you spend them wisely? That’s really hard to tell. How can you predict all future UI needs of your product?

For one product I worked on, that was part of a much larger app, we made the decision to place page settings in a slide-in left-side panel triggered by a hamburger menu. It seemed like the perfect place for functionality a user would only use sporadically. However, a few months later, an app-wide global navigation issue came up whose perfect solution was also a slide-in left-side panel triggered by a hamburger menu. Since our sub-product had already spent those pixels we now had to either rethink page settings or global nav. Pixels are some of the scarcest resources you have. The cost of squandering them is high.

9. Cognitive load: You’re probably familiar with Hick’s Law even if you don’t know it by name. It says the time it takes for a user to make a choice increases logarithmically with the number of choices. The more things in a UI the longer it takes to parse. The longer it takes to parse the more difficult it will appear to use. No one wants a product that’s perceived to be difficult to use. Keep Hick’s Law in mind when adding features. Every feature you add to your UI actively works against your product’s usability, actively works against its perceived ease of use.

So What Can You Do Differently?

Only build the right things.
Kill all the wrong things.
Fix everything else.

Only build the right things: Start by adhering to a process you trust will result in building high-value and enduring features. You’re making your company bear the high cost of building a feature, you owe it to them to build the right thing. Listen to your users. Get feedback on the current product, but also do more freeform generative research. Do financial analysis early on. Waste as little cycle time as possible on features that aren’t economically viable. Where applicable have a prototype be the core of your definition and requirement documentation. Vet that prototype with users. Iterate based on their feedback. PM time is cheap compared to feature cost. Take enough time to ensure the features you build for your company and customers are worth the cost.

Kill all the wrong things: View your product as an upstart competitor would. How would your customers react to a new competitor’s product that was an exact copy of yours, but without any unessential features cluttering things up? They’d say it looked cleaner. They’d find it much friendlier, easier to use. That should scare the hell out of you. Analyze your product usage. Find your low-usage features. If they are truly valuable figure out how to drive their adoption. If they aren’t valuable then kill them. They’re costing you a fortune, limiting what you can build, and making your product hard to use.

Fix everything else: Just because they aren’t working on features doesn’t mean the dev team is wasting its time. You have a backlog full of non-urgent bugs that have never quite been high-priority enough to edge out feature work. Keep this backlog properly prioritized so your dev team can opportunistically knock them out. Your product contains some amount of technical debt that’s slowing your team down. Rather than have your team build a feature that will be a tax on their future productivity why not pay off some technical debt and ease future development?

If you don’t have a feature that’s been thoroughly vetted by your process, you have no technical debt, and you have no bugs then go ahead and give your development team the day off. It’s a way better use of their time than building the wrong thing.

9 Reasons You Shouldn’t Build a Feature was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

9 Reasons You Shouldn’t Build a Feature

Cool stuff, every week

More Articles