Building an automation product in the B2B space is hard. It’s hard for obvious technical reasons, of course; no one expects it to be easy to make computers do something that previously was done by humans. But it’s also hard for product reasons.
When it comes to automation, there’s always an underlying question of how much control you let the end user have. How much do you require the end user to do? How much do you encourage them to do, while not requiring it? How much do you allow them to do, while discouraging it? And how much do you just totally disallow, taking entirely into the control of the product alone?
These are challenging questions for products that have automation as their core. This blog post explains some of those challenges and outlines how we think about these things at Pistachio.
A Permissive Model
To some, the answer to these questions feels obvious: Require users to do as little as possible but allow them to do as much as possible. In other words, give users the choice of how much automation they really want.
This permissive model has its tradeoffs though. I strongly believe that the North Star of all great product development is to provide value to customers that exceeds the costs, and the customer in this case is the business that pays for your product, not the person or people that use it. Allowing users to choose how much, or how little, automation they want gives enormous power to the users to decide the value your product offers.
That’s risky. End users often aren’t in a great position to make those decisions. They have to respond to limited data with little visibility, and as a consequence they often choose to do too much themselves. This is a well-known problem.
But even if end users make perfect decisions, those decisions occur at a single moment in time. Maybe your product really wasn’t great at some particular task, and as a result your users decided to do that thing manually instead. But now it’s a year later, and it doesn’t matter that your system is so much better. Your existing customers aren’t using that part of your product at all, so they’ll never know.
Allowing users to decide their preferred level of automation also costs development time. Every feature you add has to come with a toggle, and you constantly need to think about the interplay between the different settings a user might select. That means less time is spent refining the automation.
As a final point, allowing users to turn off, control, and modify the behavior of your automation doesn’t give the “fully automated” vibes you might be aiming for. Some people would have been happy to let your product “do its thing” until they saw all of the settings and options. Those settings give the impression that your product is less hands-off than expected.
Your Users Want Automation
If your product vision relies on your ability to automate some particular activity, I think the riskiest thing you can do is half-commit to that vision by allowing your users to opt out. The aim of an automation product is to solve a customer’s problems for them, and you'll only achieve that by getting real-world feedback into how that is going. If a customer turns off the automation at the first sign of trouble, you won’t have the same opportunity to improve.
To some product managers, this approach can feel very hostile. If all of your users are asking for manual control, why won’t you give it to them? But I see this differently. Giving users manual control over an automation product is a way of telling them that you won’t solve the problem, so they need to do it themselves. It’s the easy way out. Your customers bought into a vision of automation, and it is your job to make that work for them.
That is the approach we have taken at Pistachio. If a customer is having problems, or something isn’t working quite as well as they’d like it to, we take that feedback very seriously. But we don’t just let them take over, because that would mean we have failed. Our goal is to automate security awareness for our customers, and each problem we encounter is an opportunity to improve towards that goal.
Of course, taking this approach doesn’t make the problem go away, as we still have to define the boundary of our automation in terms of what it can and cannot do. But this does give us a framework for thinking about the feedback and feature requests we receive, and that has been helpful.
