After spending ten years at Uber, transitioning from operations to data science and finally to product management, I've learned that my most valuable PM skill isn't perfect decision-making, it's knowing when to ship an imperfect product.
As a data scientist at Uber, I enjoyed the process of building a deep understanding of the products I worked on: analyzing data, presenting insights and making recommendations. While rewarding, I rarely occupied the decision-maker's seat. Seeking greater ownership over final choices, I transitioned into product management.
Becoming a PM came with a lot more visibility and accountability. Suddenly, I wasn't just informing decisions, I was now accountable for their outcomes. This shift hit hardest in my career when leading the relaunch of a previously suspended product.
Given the pressure to “get it right this time”, my instinct was to front-load planning. I spent weeks gathering context, analyzing historical data, and building a detailed roadmap that I believed would thread the needle between competing objectives.
This is a common pattern: when facing high-pressure decisions, conventional PMs often respond by extending research and planning phases, seeking the "perfect" solution before showing anything to stakeholders.
While I was confident in my product strategy, the root of the issue was how I approached execution.
By polishing a "perfect" plan before involving senior stakeholders, I created two critical problems:
First, I lost buy-in. Leadership wasn't part of the journey and had no investment in our approach. When I finally presented the strategy, they had questions I hadn't considered, and I'd already spent months of team resources. Without their buy-in, execution stalled.
Second, I delayed real user feedback. By postponing launch until everything was "ready", I raised expectations while eliminating chances to test core assumptions. We spent months building features based on historical data when a two-week experiment could have shown what users actually needed.
The lesson was clear: the more I tried to de-risk through planning, the riskier the project became. Each week spent perfecting the plan made stakeholder alignment harder and user validation more distant.
What I should have done was ship thin slices early: release minimal viable products that tested core hypotheses and generated real user feedback.
By getting something tangible in front of users and stakeholders quickly, PMs can:
Create feedback loops to build learnings from users quickly
Limit the potential downsides if a feature underperforms and course correct
Build stakeholder confidence by showing visible progress
This approach is not an excuse to lower standards or cut corners. Rather, it's about finding the fastest path to excellence through learning cycles rather than planning cycles.
Effective product leaders repeatedly ask "why" until reaching the kernel of their hypothesis. If the belief is "users will do X when offered Y", design the simplest possible experiment to test that specific assumption. This focuses effort and accelerates learning.
Think of product development like baseball: getting a hit just 1 out of 3 times gets you into the hall of fame. Yet many PMs expect perfection on their first swing. Shipping thin slices lets you take more at-bats, improve your swing, and learn from each attempt. The faster you fail, the faster you learn.
The most counterintuitive truth in product management is that embracing imperfection actually leads to better products. The quickest path to excellence isn't avoiding failures, it's accelerating the rate at which you learn from them.
Instead of trying to solve every problem at once with a comprehensive solution, break down large challenges into smaller components. Tackle these bite-sized problems sequentially, learning from each iteration. This approach transforms overwhelming projects into manageable experiments that compound in value.
When you ship thin slices early and build the infrastructure to measure, control, and iterate quickly, you:
Collect real-world feedback that no amount of planning can substitute for
Build organizational muscle memory for rapid learning
Create space for high-risk, high-reward ideas that might be killed in a "perfect first time" culture
Free up resources to pursue more opportunities rather than polishing a single feature
In today's fast-paced product landscape, the companies that win aren't the ones that make perfect decisions—they're the ones that can test, learn, and adapt faster than everyone else.
Developing post-launch support is easier said than done. Building an experimentation platform, feature gates and real-time monitoring systems requires significant engineering investment and buy-in that competes with core product development. Companies often struggle to justify investing in experimentation infrastructure, viewing it as a cost center despite its impact on decision quality.
This is why I joined Statsig. We build these tools exclusively, creating the infrastructure for confident experimentation without the in-house development burden.
Even in my short time here, I've seen customers transform their approach to product development. They've gone from lengthy planning cycles to rapid experimentation, using our platform to validate ideas quickly and build a true data-informed culture.
Our team at Statsig has managed hundreds of products across many industries, learning these lessons the hard way—through failed launches, misalignments, and 3 AM production fixes.
We've distilled these experiences into "The Pursuit of Imperfection: A Playbook for Outcome-Obsessed PMs". It's a practical guide to what works when implementing these principles in different team structures and company stages.
If these challenges resonate with you, our free guide offers additional frameworks and tactical approaches for shifting both culture and infrastructure toward experimentation. We hope it helps you avoid some of the pitfalls we've navigated.