Several weeks ago, I interviewed Régis Philibert, Lead Developer at The New Dynamic, for a case study about how tND is using CloudCannon. It was an illuminating interview — for me, at least — but I found myself wanting to share something I’ve noticed about CloudCannon’s process of working closely with our users. (And in the case of tND, I should probably say power users: Régis and tND’s clients are really putting our CMS through its paces, and along with our other agency customers, they’ve really helped validate and extend our technical roadmap.)

I’ve watched this process play out through a series of shared Slack channels, which is one of the ways we communicate with our agency and enterprise customers. Speaking as a marketer (and one who loves both learning new technical terms and watching others ), it’s been fascinating to watch these conversations flourish, and to watch our CMS develop alongside them.

Typically we see a broad range of questions and answers — some simple, some more advanced. Some questions help us refine our documentation, perhaps when there’s a concept or chain of instructions we haven’t clarified enough. Some questions are easy enough to answer: given a representative sample set of inputs, our team can respond quickly with configuration instructions.

But the requests coming through our #thenewdynamic-cloudcannon channel — and the responses — were on a different level. To be honest, we’d probably hoped for something like this from Régis. His tutorials and articles on Hugo, as well as his helpful presence in the Hugo Discourse, show a deep understanding of everything the static site generator is doing under the hood.

The best user questions often turn into new features Direct link to this section

What I quickly became aware of, though, is that the kinds of questions Régis asks us are those that become feature additions our team is excited to work on. CloudCannon’s flat-ish structure, where our product developers work in support, directly interacting with our users, has two main benefits. The first, of course, is that customer questions are answered by the team that built the tool itself. Their support responses are about as expert-level as it’s possible to get. Secondly, our inbound discussions are directly influenced by what our customers want. In this way, our product devs actively champion the causes that matter to our customers.

Partly because CloudCannon works as well as it already does — a Git-based CMS that's flexible for developers, with excellent client editing — Régis and tND founder Bud Parr are confident that we’ll be a good solution for many of their customers. But, perhaps naively, I hadn’t anticipated just how much their conversations in support channels would influence what we could offer our current and future users.

Sharing direction (and excitement) Direct link to this section

We cherish these kinds of customer interactions because it’s clear that our work will have immediate value for our users. (There would be nothing worse than building something incredible and no one turning up to use it! Better to move along with someone who shares your direction.)

Application Engineer Ross Phillips, who frequently answers support questions from our agency partners, agrees. He’s a big fan of our users asking questions and pushing for new features. Beyond this, being able to design and build a feature with users in mind makes the engineering team more confident that it’s a viable solution: “We often have ideas on how to improve something, but hearing feedback from someone like Régis, or another agency dev with dozens of actively maintained sites, makes us more confident that our solution will work for more of our customers.”

For example, some of the larger recent features CloudCannon has added — input configuration for customizing data input fields, schema files that provide initial content for new files, and DAM support — have come about as a direct result of user feedback from tND and other agencies. And uptake on these features is excellent as well: “I can’t think of a feature we’ve built using this process that hasn’t been wildly successful, meaning that the users who asked for it are making use of it and are happy with it. And if they offer a suggestion that will improve a feature for everyone, that’s even better.”

It really struck me. This is the way you do it. Offer a really useful service, get the best feedback possible from your users, and iterate — this by itself is common enough practice. It’s agile development at its core. But actually enjoying the problems that people bring to you, and canvasing for user opinions on your proposed solution, allowing you to build with foresight and without ego? Balancing individual feedback with a solution that will work for the most people possible? That’s where the magic is.