"We should really talk to users more" is one of the most common things said in product teams, and one of the least often acted on — usually because it sounds like it requires a research team, a recruiting budget, and weeks of lead time the sprint doesn't have.
It doesn't have to. Here are five methods that have consistently fit inside a normal two-week sprint, with no dedicated researcher.
Once a sprint, read through the last 20 support tickets related to the area you're working on — not to find bugs, but to notice the language people use to describe their problem. It's often strikingly different from the language used internally, and that gap is usually where confusion lives.
Ask three people who don't work on the product — colleagues from another team, friends, anyone — to try completing one task while sharing their screen, with no guidance beyond the task itself. Watch where they hesitate. Twenty minutes, three people, and you'll usually see the same snag twice.
After someone contacts support or completes onboarding, a short automated email asking one specific question — not a satisfaction survey — gets surprisingly thoughtful replies, especially from people who just had the experience fresh in mind.
If you have session recording tools, watch five sessions from people who didn't complete the flow you're designing. Not five random sessions — specifically the ones that dropped off. The patterns repeat faster than you'd expect.
Support and sales teams have more user contact than anyone else in the company, and are rarely asked what they've noticed. A 15-minute conversation with someone on support, once a sprint, often surfaces issues design and engineering haven't seen at all.
None of these replace a dedicated research practice — but they're enormously better than the alternative, which is usually nothing.