So, now you’ve built this low-code platform and overly optimistic expectation is that all your users who previously had requests are going to be tripping over each other to implement their features. Well, not so much…
We’ve had a mixed response coming from our users around embracing the low-code mentality. In some cases it’s very discouraging as you’ve spent so much time and effort to enable them, and yet they don’t want to use it. In other cases it’s thrilling when other users come to you who previously weren’t your customer and quickly bring business value that was previously outside of their grasp. That said, there are a couple things that you can do to help those more hesitant users along the journey of self-enablement.
Should They Come?
I would be negligent however if I didn’t first encourage you to ask the question “should they come”? It’s very appealing to be popular and enabling users from all areas of the business with your shiny new tool. However, be aware of your charter and purposes for your platform. Also, realize that every feature will cost something from your team. It might be as non-intrusive as occasional code reviews, or as costly as new licenses as more users onboard. It might be as simple as a new field, or turn into a complicated “legacy” system that your team will have to manage for perpetuity as the original creator leaves their role or your company. The question gets even more complicated in terms of compliance and privacy regulation. How do you ensure that the data being stored in your system is kept appropriately confidential and only share with the desired users? How do you ensure that your contributors are not collecting excessive personal details of user (even internal users) and you’re not in breach of privacy regulation?
In my opinion this is where the low-code ecosystem really hasn't matured yet. We've been so focused on the question of velocity, that we've largely forgotten the question or architecture and security.
More on that later. However, for now I would encourage you to take a step back and ensure that you have clarity around who and what use-cases should appropriately live in your low-code platform. Better yet, document them into a strategy and generate templates for the on-boarding of new features so that you have a robust service catalog. After all, you’re now likely running your own Platform-as-a-Service, and that comes with a shared responsibility.
Enabling Citizen Development
Let’s assume that some of your users are hesitant, after all, it’s a bit scary to start creating features that up until recently were only in the scope of the engineering staff. Or, lets assume that some of your users don’t want to be responsible for delivery, just the collecting of requirements. What now? I wish I knew…
We’ve taken a multi-pronged approach, one of managerial expectation that contributing functionality is now part of the job requirements; and also of nurturing the more hesitant. In general I’m a bit fan of tutorials. There’s no shame in making no assumptions documentation that takes a user from nothing to an example minimum viable product (MVP). It doesn’t cause the engineering arm to appear less sophisticated or knowledgeable, and it will help your users. This, combined with training will hopefully remove the hesitation of many users and help them to realize that they too have been enriched by this new tool that you’ve provided.