Infrastructure as a Product (part 1)

I've been spending a lot of time thinking about what it means to to have infra service approached as products. When I say infra, I'm talking about things like CI/CD, schedulers, validation suites, and monitoring/alerting.

I get that that isn't a new concept, but there's a few things that I've been struggling with. I want to talk about one of them.

The User

When dealing with customers, they are usually low information (as far as your infra goes), and don't have the technical expertise nor background to assist you. They use the thing you give them the best they can. In infra, your customers are engineers too. They not only use the things you give them, they're capable of understanding them to a high level. Even abusing them when there is a lack of proper controls.

This is both a blessing and a curse. Your customers can talk on the same level as you, but they have the same problem you do. They are good at solving things. This don't have the context that you do yet are bringing solutions. The problem being is that they tend to solve their problem in your software, not your problems (which should include theirs).

You want to harness their help, but you don't want to reject them outright either. The best I've found so far is try try and direct that energy into helping them accomplish your broader goal, which if you've planned right, solves their goal as well. The redirection of effort can be useful. However, I want to avoid the discussion in the first place.

Overall, I've not convinced this is the best approach to the matter. I feel like there is something upstream of the discussion that could be done to prevent needing to manage their effort put in by the customer with the problem. I'm still looking for a way to prevent this from happening, outside of having perfect planning.