Small Features, Big Decisions: Unpacking the Myth of the Quick Add-On
Discover more from Focused Chaos
Small Features, Big Decisions: Unpacking the Myth of the Quick Add-On
Not all small features are easy to build. Some can have massive impact on your product, value proposition, strategy and more. (#36)
“That’s a small feature, let’s just squeeze it into the current release. Customers will love it, and it’s easy to do.”
Have you ever heard someone say that? Maybe as a product manager, you’ve said that.
Oh oh. 😰 💣
We often measure the scope of a feature based on its development time. What’s often ignored or dismissed is everything else required to get a feature to the dev team, including user research, design (both UI and UX), impact assessment, strategic fit and more.
Sometimes a small feature is just that, a small feature. And product managers are notorious over thinkers and analyzers, turning molehills into mountains, and over-complicating everything. Once in awhile there’s something small or iterative you need to add to the product and the best answer is, “just fucking do it.”
But sometimes that’s the wrong answer. More thought and effort are required, even to build something small.
Teams will often use “small” and “simple” synonymously. “That’s a simple thing to add,” or, “That’s a simple feature, everyone will understand it.” Are you sure?
“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.” - Steve Jobs
Building small or simple features is often quite difficult.
Launching “Small” Features at GoInstant
I joined GoInstant in October, 2011. The company was acquired ~1 year after by Salesforce. During my time at GoInstant, prior to the acquisition, we released a number of “small” features, and I want to share some of that experience here.
What was GoInstant?
GoInstant was co-browsing technology that enabled 2+ people to browse and interact through a browser, on any website, with no plugins or downloads. You could have 20 people jamming in Google together, or browsing YouTube. The tech was awesome.
More practically, we were building GoInstant for sales & customer support. Imagine doing a sales demo for someone where you could “hand over the reins” and let the prospect do things, while you guided them. If they got stuck, you could instantly keep things moving. It was a seamless experience.
As part of Salesforce, we rebuilt the technology as an SDK for mobile applications, so you could provide users with interactive customer support in a native mobile app. We also built out a platform tech stack to enable anyone to develop real-time interactivity into their software (particularly Salesforce apps.)
Two “small” features we built into GoInstant were called Presenter Mode and Session Lock.
Neither took long to develop, but the amount of thought and effort that went on behind the scenes was significant.
To illustrate the smallness of the features, here’s a screenshot of a GoInstant session:
The entire GoInstant UI is the address bar at the top and a small vertical bar on the side. Our goal was to be as invisible as possible and provide people with a frictionless experience.
Presenter Mode is in the top right-hand corner. It’s a button that you turn on or off. When turned on, only the session owner can interact with the web page. Guests can’t click or type (but they can move their mouse around.) Turn it off and everyone can fully interact together. Sometimes a presenter needs control without having people clicking and scrolling all over the place.
Session Lock is below the list of participants. It’s an icon of a lock (unlocked or locked) and a link for locking or unlocking the session. When a session is locked, no one can join it. The idea was to provide security and privacy for participants. When unlocked, others could join.
These are both “small” features. Easy to code. But we went through many iterations and discussions around the UI/UX. For example, guests can’t see the “Lock / Unlock” link, because it’s only something a session owner can do. But guests see the lock icon, because we felt it was important for them to know what was going on. So when a session owner locks a session with guests in it, others think she’s clicking into an empty space. That may be a weird experience for guests, and if it means the session owner has to interrupt her presentation in order to explain what she’s doing, GoInstant has created friction.
Side note: Most UIs with a lock type feature will make the icon clickable. It’s an action and a state. So if you see a locked icon and click it, you’re unlocking something and the lock changes state. I don’t remember why we decided not to take that approach (and use the link instead) but I think we were worried people wouldn’t recognize the icon as being actionable. It was also 2011-2012, common UI elements are always evolving.
Designing the UX for Presenter Mode was equally complicated. We tried a number of options and discussed how prominent the indicator should be. You can see how little real estate GoInstant was working with, we had to be extremely economical with everything we added, but we also obsessed over it being dead simple to use.
We believed people would understand the concept of Presenter Mode (based on customer interviews, feedback we’d received and terminology people were using with us) but we also had questions. For example: What if a guest is brought into a session, told it’s completely interactive and then starts clicking around…only to find nothing works? This sounds minor, but if you’re a salesperson, you don’t want to be stuck explaining how GoInstant works, you want to focus on selling your software.
Sidebar: How people talk about things matters
How people talk about and describe things matters. Is it post, submit, publish or create? Those words all mean basically the same thing, but there are subtle differences as well.
When we showed people GoInstant they struggled with the idea that it was full multiplayer all the time by default. Whoever we demoed to would always say, “OK, so I’m presenting to someone. And they can also interact?” The answer was “sort of” because you weren’t presenting your screen, you were both on the screen at the same time, interacting as if you were each “in control.” It’s different from single-player mode + screen share. But people kept coming back to “I’m presenting” in part because of the use cases we were going after. When you’re doing a sales demonstration, you’re presenting to someone. So using the term “Presenter Mode” felt very comfortable to everyone. It was a low cognitive load for people to understand.
When you interview and talk to users don’t just focus on “getting the answers you want.” Genuinely listen to how they describe things and the words they use. It’ll help you craft a better product experience.
Usability Testing
It’s easy to skip steps when building stufft, especially “small” features. But it’s risky.
Once you’ve deployed something into production, it’s out there. You can fix bugs and iterate after the fact, but the effort to do so is expensive compared to fixing issues or iterating beforehand. The most expensive things to change (in terms of time/effort, reputation, etc.) are things that are live in your product. That’s why I’m a big believer in prototyping first and conducting early usability tests.
This doesn’t have to be a super formal process. But every single time I’ve put a prototype (from paper to clickable to code) in front of someone and asked them for feedback I’ve learned something important. That’s a 100% success rate for learning.
Thinking about the Future
Each feature you build doesn’t live in isolation. It’s the combination of features that make a product (and hopefully make a product useful and valuable.)
Small features in isolation may be small, but if you step back and evaluate your overall purpose and strategy, those small features can become much more important and complicated.
GoInstant took up as little space as possible. Every small feature took up precious real estate. So we had to decide very carefully which features mattered (and which didn’t), and how to express those features in the product. We didn’t want to move things around very often.
Product management is equal parts designing & building for today, and planning & setting expectations for tomorrow.
The Dreaded “Appendage” Functionality
A lot of software has some form of admin or control panel, with preferences to customize or personalize things. This is particularly true in entreprise B2B software, but it’s prevalent in B2C/consumer applications too.
I often think of this as “appendage” functionality. It’s stuff that’s not related to how the core feature works, but plays a supporting role. For example, you build a small feature and then decide to also build an “on/off” switch.
Access levels is a classic “appendage” feature. Most software has some form of permissions, which I completely understand. But two things:
Are you sure you need access levels right away? Maybe you don’t for the MVP, and then you can learn over time what is really needed.
Every time you build something new, you have to decide where it goes and who has access to it, which is more code, more complexity, more time.
When building Presenter Mode we talked about appendage functionality a lot. For example: Should Presenter Mode be on automatically when you start a session or should session owners have to turn it on each time? The first instinct was to build a configuration option to let people decide how they want it to work. If you can’t decide or be opinionated enough (ideally with user input), you end up wanting to provide maximum flexibility. Ugh.
Every option you bake into your product requires more time and money. Plus you incur more risk of introducing bugs, and it’s difficult to take things away from people once you’ve given it to them. You end up with a string of small features, each of which has multiple configuration options and you now have bloated software. These days there are feature management tools like LaunchDarkly that make this sort of thing easier, but I still think it’s a pain in the ass to manage, scale, etc. and shouldn’t be the default (“everything has a configuration option!”)
You need to be extremely cognizant of “appendage functionality” and ideally avoid it as much as possible, especially early on when you’re designing the minimum viable version of a feature (or your product.) Instead of building configuration options, test a feature’s use and make decisions from there.
Measuring the Value of New Features
In a perfect world, everything you build, big or small, would have measurable impact and value creation. And while we don’t live in a perfect world, you have to try, otherwise you’re stuffing more features into your product with no idea whether or not you’re headed in the right direction.
1. Define ‘good’ usage: First you need to define good usage; i.e. how often do you think a new feature will be used in order to create value? Is the feature something people will use daily? Multiple times a day? Once a week?
If you’re building something that gets very infrequent usage, you should challenge yourself on whether it’s worthwhile or not, especially “small” features.
2. Define impact: You need to define the impact you expect a new feature will have. Will it increase conversion through a funnel? Will it increase customer satisfaction or reduce churn? Will it encourage virality? You need to answer the question, “Why should this feature exist?”
My suggestion, even for small features—write out a Product Requirements Document. Part of the job is to define impact and how you’ll measure it. (You can read more about PRDs, including some examples, about halfway through this post.)
3. Instrument new features so you can monitor usage: Make sure you quantitatively track usage. That way you can answer questions about frequency of use but also how a feature is used. For example, with Presenter Mode, it’s interesting to see how often the feature is used per user, per client and per session. It’s also interesting to see how long it’s used for. Are session owners staying in Presenter Mode the whole time, or are they leveraging GoInstant’s interactivity? Are session owners clicking the button a lot because they’re not sure if it’s working or how it works?
4. Talk to users / customers: Quantitative data is great, but so is qualitative data.
Quantitative data tells you what is happening. Qualitative data tells you why.
You need both to see a complete picture, even for small features.
Talk to customers about their use or lack thereof. Ask them if the feature is helping them (with whatever job they’re trying to do.) Ask “why?” a lot so you can dig in deeply without leading the witness. These types of interviews aren’t too dissimilar from higher level problem interviews, but you’re more focused on a specific feature or use case.
Building Small Features is More Complicated Than You May Realize
“That’s a quick addition, we should just do it.”
“That will only take a few hours of dev time, let’s just sneak it into the current release.”
“The boss thinks we need to add this little widget. It’s supposed to drive more sales.”
Cool, cool, cool, cool, cool, cool, cool, cool…
Except:
You’re probably wrong. And now you’re disrupting a sprint in order to do something you think will be a quick win; and,
Small features are rarely that small.
Crafting a product well is very hard. It’s not a bunch of “small” features tossed together like a quickly made salad. While every feature you build isn’t your magnum opus, you should do things with purpose.
Purpose requires thought and structure. You have to be careful about getting caught in analysis paralysis—sometimes a small feature is really just a small feature—but it’s worth taking a step back, looking at things strategically, and making sure you understand the goals and impact you’re aiming for before you build.
Building stuff is usually the easy part. Building the right stuff on the other hand…
Small Features, Big Decisions: Unpacking the Myth of the Quick Add-On
An incredible and insightful read - thank you!!
Great article, Ben. This one hit home for me on several levels :)
I’ve been building something as a solo developer for a while now, and to your point: the bigger the project gets, the more complicated each and every small feature becomes to plan, implement, and maintain.