AI can do the busywork. That doesn't mean you should let it

I asked AI to turn my user research into a feature list. It gave me six features. I ended up with forty-three.

That gap has been sitting with me, because it challenges a narrative I keep hearing:

let the AI do the grunt work so you can focus on the “real” work.

Summarising documents. Drafting follow-up emails. Grouping tickets. Pulling together feature lists. All the things that take time, but don’t always have value attributed to them.

In some cases, we’ve got this backwards.

Sometimes the grunt work is the real work.

From a product management perspective, a lot of what we call “grunt work” is actually how we learn. When you summarise notes, you internalise what matters. When you group tickets, you understand the scale of the problem, feature relationships, and customer experiences. When you write things out, you clarify your own thinking. It’s not just output; it’s how you build context. And without that context, the “real work” – strategy, prioritisation, decision-making – gets shaky very quickly.

A recent example made this very clear for me. I’d just finished a set of user interviews for a new product, speaking to different people from different departments with different needs. I captured everything in my notes, a mix of “must have/phase 1/required”, “should have/phase 2”, and “nice to have/phase 3”. Those notes were messy, slightly inconsistent, and very human. This type of unstructured data is exactly what AI is supposed to be good at working with.

The next step was to turn that into a structured feature list for an MVP. I mentioned to another colleague I was going to be doing this and they said “AI should be great at that. It will save you so much time”. So I gave AI a go.

The result told me I needed six features.

I already knew that was wrong. I’d spoken to enough users to know there was far more complexity there but I couldn’t immediately articulate what was missing. I tried nudging Copilot, asking for more detail, clarifying the structure. It didn’t help. The output just shifted labels rather than substance.

So, I went back and did the work myself, albeit using the excel template AI created based on my instructions (that did save me time). I read through the notes, pulled out the features properly, broke them down into their individual requirements. By the end, I didn’t have six features – I had forty-three.

But the number isn’t the interesting part.

What mattered was what happened while doing the work. As I worked through the notes, I reconnected with each persona. I remembered what people actually cared about, not just “we need search”, but how that search needed to behave and what it needed to prioritise. I spotted contradictions and gaps. I thought through expected behaviours. I started to see where things might break.

By the time I finished, I wasn’t just holding a feature list. I had a much deeper understanding of the product, the users, and the trade-offs we were going to have to make.

That doesn’t come from a summary. That comes from doing the work.

This is the bit I think we’re underestimating. Grunt work isn’t just low-effort busywork. It’s often where understanding is built, where judgement is developed, and where edge cases are discovered. It forces you into the details, and the details are where products either succeed or fail.

There’s also a bigger question here about what we mean by efficiency. We often define it as doing something faster, but in product – and most complex work – that’s not quite right. A better definition might be speed to value.

If you produce something quickly but it’s based on a weaker understanding or results in lower quality, you haven’t actually been more efficient. You’ve just deferred the cost.

We’ve had versions of this trade-off forever: fast, cheap, good – pick two. What worries me is that AI can make it feel like we’re getting all three, at least at first. But if it’s quietly reducing the depth of understanding behind the work, that quality trade-off shows up later; in missed requirements, unclear tickets, bad assumptions, and ultimately a weaker product.

To be clear, I’m not anti-AI. I used it in this example, just not for the part I initially thought. I also use the dictation feature of AI to help me write this article. For the feature list, AI gave me a starting point and a template. But the thinking, the synthesis, the judgement still had to come from doing the work.

So maybe the question isn’t “what grunt work can AI take off my plate?”

It’s “which of these tasks are actually how I build understanding and shouldn’t be outsourced?”

Because sometimes the most important work doesn’t feel important while you’re doing it.

It just feels like… grunt work.