A product finds a thing, a situation, a problem. The queue is full! There’s a lot of high severity vulnerabilities! The message handler stopped handling messages! Now the product developers have a choice to make: should they do something, or tell someone? Unfortunately not everyone wants the same decision at this point.
One type of customer wants clever software to do their job for them and then gets mad if it doesn’t make the same decisions they would have. This customer probably doesn’t have a lot of staff, and is looking for the product to augment their team.
The opposing customer type wants transparent software that tells them what is happening and what that means, and they get mad if it tries to do something clever without telling them about it. This customer has staff responsible for doing things, and they generally don’t want product making their decisions. Instead, they’re looking for software to automate the tedious and scale the impractical.
Of course, any two point scale describing people is composed of two unrealistic stereotypes, and the real customers your product must satisfy are working in the middle of that spectrum. This produces an uncomfortable pinch for the product manager: when should you tell and when should you just do instead? There are some common options for handling the problem.
Always Only Tell
One extreme approach is to simply log your results and dashboard their status. If the customer wants to do something about it, they can build monitors and automation, whether in your product or in someone else’s. This approach has some benefits: you’ve answered the question in an internally consistent way, so you spend less time on philosophical arguments. It’s also beneficial to leave monitoring and automation to an expert crew; even if it’s part of your product, it could be driven by a feature team that’s focused on monitoring and automation. There are drawbacks to this approach as well, because it depends on the customer or field engineer knowing how to solve every problem, deciding which problems need to be solved, and then acting to solve them in some way. Wouldn’t it be better if you could share those solutions when they’re common across many customers?
Always Only Do
The other extreme is to fully understand your context and desired state, and automate the actions needed to maintain that desired state. This can be pretty easy for a product that is focused on a single use case and works in a constrained environment. For instance, it would be pretty frustrating if you as a user had to manage the resource utilization and network behavior of the Bear text editor. Between the operating system and the app’s own decisions, there are very few system behavior decisions exposed to the user. This is a harder feat to achieve for enterprise products driving visibility and control. Pros: taking decisions on behalf of the user greatly reduces the user experience complexity presented to the user, as well as removing the need for fuzzy boundaries with content packs or app models. It also gets you great internal clarity: you either handle the whole problem from stem to stern or you don’t touch the problem. Con: you are on the hook for completely modeling all possible outcomes, and it’s going to be a customer support contact if you fail.
Let the Customer Decide
And then down the middle… give the customer their own control. If your product has the ability to take actions, then you can expose those action-taking decisions to the customer.
Ask Every Time
The simple and annoying way to do this is to ask the user to intervene. The canonical example here is the operating system security warning: Are you sure that you want to let this process do this thing? Pro: your firm is technically absolved of liability for bad outcomes. Con: you’re potentially hated and mocked for your inability to make any call on your own. You might also spray the user with more decisions than they’re willing to engage with.
Give Them Options
The next position is to describe the situation and give the user yes/no options for responding to the situation. That position can range wildly from easy to describe and hard to do (list the processes that are relaunched if they die and pin the versions of every library) to hard to describe and easy to do (call my emergency contact when I fall, but don’t false positive because that’s annoying or false negative because that’s dangerous). Of course, that means a lot of options… and when your settings page needs a search tool of its own, you might have gone off the deep end of optionality.
What About Content Packs?
The most flexible route of all of course is to only present an option when it’s relevant to that user, and base the relevance decision on a previous installation action. Simply move beyond the single product: build a platform and apps for specific functions, and then each of those apps can make this decision on their own. At its simplest, these apps might just be bundles of questions and answers and actions, content that fits neatly with the “Always Only Tell” model. At its most complex, each module or app has the ability to make its own decisions about this question and it’s up to the product team to enforce some level of consistency or forge boldly ahead.
Conclusions
The kind of product you’re making eventually decides what paths are available: the more that it’s an expert analysis workbench or a highly complex toolkit, the less relevant an “Always Only Do” option becomes. That path works best for single purpose, single focus, and single user products. I am unable to think of an example that makes most of its decisions automatically and provides a team experience… the closest I can get is products that perform automation like Zapier or PagerDuty, which again have enterprise levels of complexity and a de facto focus on telling rather than acting. Another possible exception is the elastic scaling services in Infrastructure as a Service (IaaS) vendors: complex, multi-user enterprise products that do instead of tell. Even there, the products don’t automatically maintain their own needs though, and I continue to think that enterprise products don’t have a lot of room for automatic self-management.
Monkeynoodle.Org 