← Back to blog
What it actually means to be embedded with your users

What it actually means to be embedded with your users

15 April 2026 productpm-craft

“Embedded with the team” is PM jargon for a lot of things. Usually it means a few discovery calls and a shared Slack channel.

This is different.

For the past year I’ve been sitting inside a 24x7 managed SOC and incident response operation. Not observing. Operating. Watching where analysts get stuck. Which tools they switch between. What the 3am alert looks like when the customer is escalating. What information is missing when a case needs to be handed off.

It changes how you write requirements.

The gap between stated needs and observed behaviour

In a standard discovery interview, an analyst will tell you they need better alerting. Better context. Fewer false positives. All true. All also what every analyst at every SOC will say.

What you only see by being there: the analyst who has three browser tabs open because the context they need doesn’t exist in one place. The copy-paste between systems. The personal notepad that’s actually the case file. The ticket that gets closed in two systems because neither syncs to the other.

Those are product gaps. But they don’t come up in interviews because they’re ambient. Too normal to name.

The requirement you don’t know you need

The most useful thing I’ve shipped came from watching an analyst close the same case twice. Once in PagerDuty. Once in Salesforce. Two systems, no sync, because the integration didn’t exist.

That’s not something they put on a roadmap. It’s too operational. Too unglamorous. But it was absorbing analyst time on every single case.

The fix was boring. The outcome wasn’t.

What this changes about prioritisation

When you’re in the room, you stop prioritising by stated pain level and start prioritising by actual friction cost. The analyst who complains loudest might not be the one losing the most time. The quiet workflow that everyone does automatically, every day, is often where the real leverage is.

It also makes you more honest about what you’re not building. When you see directly what happens when a feature isn’t there, the tradeoffs feel different. You stop rationalising deprioritisation with “we’ll get to it.”

The limit

This only works if you stay honest about whose workflow you’re in.

I’m a PM working in a managed SOC. My users are enterprise security teams running their own SOC workflows. There’s significant overlap. The jobs-to-be-done are the same. But there are differences in scale, tooling, team structure, and context that I have to be careful not to flatten.

Being embedded is an input. It’s not a substitute for talking to the actual customer.

found this useful