Rediscovering Drupal, from the product side

It’s been a while since I last opened Drupal. This time I’m coming at it as a Product Owner, and that changes everything. I no longer ask how we build a feature, but what it costs, who will use it, and what might break when we touch it.

Learning to speak the same language

At first, Drupal feels like a tool where everything is possible and nothing is obvious. Content types, views, taxonomies, permissions: that’s a lot of concepts. My first instinct was to understand everything before asking anything. Bad idea. What helped was understanding how the tech team reasons, so I could phrase my needs in the right terms. A well-framed request saves a lot of back-and-forth.

Running the site without getting lost

Day-to-day administration is mostly about discipline. Modules, security updates, editor permissions: nothing spectacular, but if you let it slide, it costs you quickly. From the product side, I’ve learned to treat admin as part of the product, not as a separate technical chore.

Custom development and version upgrades

I’ve already lived through version upgrades as a tech project manager. We managed the schedule, estimated tickets and handled surprises. Now I look at the same topic from the other side: I’m the one deciding what we build and what we leave out.

Every custom development is a debt: it has to be maintained, tested at each major upgrade and explained to the next person who joins. Before approving one, I need to answer three questions: what business problem it solves, whether a standard solution would be enough, and what it will cost in three years.

For version upgrades, my role is no longer to set the date but to arbitrate: which features we keep, which we drop, and how much risk we accept. I also have to defend testing and fixing time in the roadmap, otherwise it always gets cut.

What I keep in mind: limit custom work to truly specific needs, and document every deviation from the standard along with the reason behind it. In three years, someone will need to understand why things are done the way they are, and that document is often the only trace of that reasoning.

Day to day: content requests

A large part of my work is content creation or modification requests. They look simple, yet they quickly reveal the gap between what the tool allows and what teams expect. What makes the difference is minimal framing: who is asking, what type of content, which template, by when. It sounds obvious, but it’s often what’s missing.

What it taught me

Moving to the product side with Drupal made me realise that technology isn’t the main subject. The real subject is clear needs, a site that can be maintained over time, and awareness of what each choice costs. That goes well beyond Drupal.