The math of A/B testing is the easy part. The hard part is knowing what to test, and that is exactly where this data scientist got stuck. When the e-commerce team says they have no experiment backlog, that is not a data problem, it is a discovery problem, and it deserves a direct answer: stop looking for statistical significance and start looking at user behavior.
The instinct to hire a UI/UX researcher and product owners is sound, but it is also a deferral. Outsourcing the hypothesis generation does not build the capability your team needs; it just moves the bottleneck. What this situation actually demands is a shift in how you frame your own role. Instead of waiting for someone to hand you a test, become the person who turns observations into testable questions. Pull the search logs, session recordings, and funnel drop-off reports. Look at where customers hesitate, where they abandon, and where they repeatedly ask for help. Those friction points are your backlog. Competitor trends can inform direction, but they cannot tell you what is broken in your own journey. The answers are already in your data, you just have to be willing to mine them for questions, not conclusions.
This is a familiar trap for analysts who are technically strong but operationally isolated. It mirrors the challenge of choosing a causal model when the true effect is invisible, a problem we explored in Choosing the Right Causal Model When Truth Is Unseen. In both cases, the difficulty is not the method; it is the absence of a clear target. And just as aspiring analysts often get lost in course catalogs rather than building projects, as noted in Turn Daily AI Courses Into a Clear Path Toward Data Science, the fix is to move from theory to practice. Start small. Pick one page with a high exit rate and run a qualitative review. Write down five reasons someone might leave. Turn each reason into a hypothesis. That is your first test.
The practical takeaway is direct: your job is not to run experiments; it is to create the conditions where experiments become obvious. If the e-commerce team cannot propose tests, propose a weekly session where you review one user journey together and ask, "What would we change if we had to change something today?" That constraint forces decisions. It also trains the team to think experimentally, which is more valuable than any single test you will run. The moment you stop waiting for a backlog and start generating one from existing data, you stop being the person who runs tests and become the person who decides what matters. That is the role every data scientist should want.