Your company makes a great product! Really and truly, the core of what has been built is fantastic. Your product has a unique market position, and you’re gaining traction. Everything is awesome. And then, well, things start becoming a little less awesome.
Requests start to come in on small tweaks to the product that are for “internal eyes only,” so you go off and set up a way to have just those features on for some people. Then, a big client asks for something that is pretty unique for their team, and you head off to build another set of controls to allow a feature to only be shown to some other people. This process repeats a number of times throughout the evolution of your product. You’re feeling pretty good about your direction and your ability to deliver value to your clients. Then it happens. Disaster.
The Administrator of the system pulled a single incorrect lever of the plethora of custom controls and enabled a feature for the wrong person. This may mean you leaked internal information, gave someone control of a feature that wasn’t meant for them, or worst of all, shared confidential client information with one of their competitors. Maybe you had to take a financial hit because an override feature was given to someone who didn’t know how to use it, or you take the brunt of significant reputational loss for your product and your company. The administrator may get in trouble for this slip-up, but it’s not their fault. As the product manager, it’s yours!
In enterprise software in particular, there is a desire to be able to customize the software to meet a number of slightly different client requirements. There is an inherent challenge here for product managers. The ability to configure the system to certain workflows adds complexity to the overall product, and leaves the door open to bad user experience and the mistakes mentioned above. Additionally, every configuration you add to the product increases the maintenance and testing of your product exponentially. Your testing needs to cover each new branch of workflow that a configuration creates. This can be extremely costly, particularly in the long term. It is important to recognize, as the product manager, that you are not going to be able to get rid of all configurations, but you can try to limit them.
There are a few approaches that help in the process:
- Have Good Personas: When designing workflow, and subsequent configurations, have an understanding about who will need to use them. Is this for your core Cient persona, your internal Ops persona, or your Executive persona? Is there a way to design it for all three personas, as opposed to just one? Having the definitions of the different users of your system will help ensure that creating a new configuration is something you need to do for your product, not just one customer.
- Help the Admins: Administrators are an often a forgotten set of users of your product. This can be really detrimental as they are part of the engine of your product, without them, your product does not go. Wherever your Admins come from, internal teams or client teams, make sure that you have established relationships and get their input and feedback early on in your development lifecycle. Additionally, Admins are a great resource for general feedback on your product overall. They see workflows and use cases in ways that other users won’t.
- Chunk the Controls: Configurations tend to have other configurations that are very similar. Make the life of your administrators easier by grouping together controls that have similar meanings or defining characteristics.
- Test Pilot: Many of the features that go into the system are controlled by configuration because they are being rolled out for one or two clients as a test. If these go well, and you decide to make the feature part of the core functionality, get rid of the the control. Your Product’s Admin interface should have great UI/UX just like the rest of your product.
- Make them Obvious: When you do make the decision to add a new configuration, make sure the control is self explanatory. It should make sense to those who are administering the system, not those who are building it.
- Make them Consistent: Configurations should all work the same way. You are either turning on features and giving access, or turning off features and removing access, the product needs to do this consistently.
While many of these sound simple, being disciplined about their implementation is the real challenge. It’s hard to tie specific ROI back to improving the administration of your product, but doing so is an investment that pays off with a simpler product, fewer mistakes and smoother operations as your product experiences more and more scale. Producing a system that adds selective complexity for specific users through a series of equally complex controls is a recipe for disaster. A great product manager will meet client needs while keeping each process within the product simple, even administration.