The story of the physicist-turned-data-scientist who feels stuck in a slow-moving research environment is one we hear far too often. It is not a story about a lack of skill or ambition, but about a mismatch between the pace of discovery and the pace of impact. When your work cycle stretches across years, the feedback loop is so long that you rarely see the immediate consequence of your efforts. That frustration is not a sign of weakness; it is a signal that you value learning and iteration, which are exactly the instincts that product-focused teams need.
The real challenge here is not whether you can learn A/B testing or product experimentation. You can. The challenge is how you frame your existing expertise as a foundation for that learning, rather than as a substitute for it. A physics PhD is not just a credential; it is evidence that you know how to formulate hypotheses, design rigorous analyses, and interpret noisy data. Those are the core competencies of experimentation. What you lack is not the thinking, but the specific tooling and vocabulary of the web product world. That gap is smaller than it feels, and it is closing faster than you think.
So how do you convince someone to give you a shot? You stop trying to convince them you already have the experience. Instead, you show them how your research process maps directly onto their experimentation cycle. You talk about the time you had to isolate a signal from a messy dataset, or when you had to decide whether an observed effect was real or just noise. Those moments are the heart of A/B testing. The difference is that your tests ran on a longer timescale and with more controlled conditions. That is not a disadvantage; it is a different kind of rigor, and it is valuable in a world where many product decisions are made on flimsy evidence.
The practical move is to build a small project that demonstrates your ability to run an experiment end-to-end, even if it is on public data or a personal project. Write a blog post about how you would design a test for a feature you use daily. Share the code, the analysis, and the decision you would make. That portfolio piece will speak louder than any bullet point on your resume. It shows you can move from question to action quickly, which is exactly what a fast-paced team needs. Stop waiting for permission to learn on someone else's timeline. Start showing what you can do with the tools you have, and the opportunities will follow.