What Amazon Taught Me About Product-Led Operations
The counterintuitive lesson that transformed how I think about building at scale
When I joined Amazon in 2012, I thought I understood the difference between product and operations. Product teams built features. Operations teams executed processes. Simple.
I was wrong.
A decade at Amazon, I learned that this distinction is not just false; it’s actively harmful. The companies that win at scale don’t separate product from operations. They treat Operations AS Product.
This insight shaped everything I’ve done since. Here’s what I learned.
The Amazon Paradox
Amazon is famous for operational excellence. The fulfillment centers. The delivery network. The relentless efficiency.
But here’s what most people miss: Amazon’s operational excellence isn’t the result of better processes. It’s the result of better product thinking applied to operations.
Jeff Bezos didn’t build a logistics company that happened to have a website. He built a product company that realized the logistics network itself was the product.
This sounds like semantics. It’s not. The distinction changes everything about how you make decisions.
When you think of operations as “execution,” you optimize for efficiency. You ask: How do we do this faster and cheaper?
When you think of operations as product, you optimize for customer value. You ask: What experience are we actually delivering, and how do we make it better?
The second question leads to fundamentally different outcomes.
Principle 1: Customer Backwards, Not Capability Forward
At Amazon, we had a forcing mechanism called “Working Backwards.” Before building anything, you wrote the press release announcing it. Not the technical spec. Not the project plan. The press release.
This sounds like a writing exercise. It’s actually a thinking exercise.
When took over the Same-Day Delivery product, the team was focused on operational metrics: delivery density, route optimization, driver utilization, selection count. All important. All wrong as starting points.
The Working Backwards question was different: What does the customer actually want to feel when they choose Same-Day?
The answer wasn’t “delivery in 24 hours.” It was certainty. Customers wanted to know— with complete confidence — that their package would arrive when promised. The speed was secondary to the reliability.
This reframing changed our entire roadmap. Instead of optimizing for faster average delivery times, we optimized for tighter delivery windows and higher on-time rates. We hit 99.5% on-time performance across 13 countries.
The operational metrics improved too. But they improved because we were solving the right problem, not because we were solving the wrong problem more efficiently.
Principle 2: The Product IS the Process
Here’s a question that changed how I think about building: Where does your product end and your operations begin?
At Amazon, the answer is: there is no line.
When a seller lists a product on Amazon Marketplace, they’re using a product. When that listing goes through our catalog system, that’s also a product. When a customer searches for it, finds it, buys it, and receives it—every single touchpoint is a product decision.
During my time with the Marketplace team, we launched four new marketplaces generating $1B+ in annual revenue. The key insight wasn’t about market selection or pricing. It was about treating the seller onboarding process as a product.
Most marketplace companies treat seller onboarding as operations: paperwork, verification, compliance. A necessary evil before sellers can start selling.
We treated it as a product experience. We asked: What if onboarding was so good that sellers told other sellers about it?
We built a catalog platform that automated the painful parts of listing products. We created tools that let sellers see exactly where they were in the process and what they needed to do next. We designed the experience to feel like using a consumer app, not filing taxes.
The result: 15,000+ new SMB accounts from targeted outreach, while raising seller fees 4% (because sellers were willing to pay for a better experience).
The product was the process. The process was the product.
Principle 3: Measure What Customers Feel, Not What You Do
Amazon is obsessive about metrics. But the metrics that matter most aren’t operational metrics—they’re experience metrics.
Here’s an example. In logistics, everyone measures “on-time delivery rate.” It’s a standard operational metric. But at Amazon, we also measured something called “delivery quality score”—which included factors like package condition, whether the driver followed delivery instructions, and whether the customer had to contact support after delivery.
On-time delivery rate tells you what you did. Delivery quality score tells you what customers felt.
When I was scaling Same-Day Delivery, we found that our on-time rate and delivery quality score sometimes moved in opposite directions. We could hit our on-time targets by rushing drivers, but rushing drivers led to packages left in the rain, missed delivery instructions, and more customer contacts.
The operational metric said we were winning. The experience metric said we were losing.
We restructured incentives around the experience metric. On-time performance improved to 99.5%, and we increased Prime customer lifetime value by 7%. Not despite optimizing for experience, but because of it.
Beyond Amazon: Applying Product-Led Operations
When I left Amazon to lead product at JLL, I brought these principles with me.
JLL provides software for commercial real estate—building management, facilities operations, space planning. The industry traditionally thinks of this as “enterprise software,” which means long implementations, complex workflows, and training manuals nobody reads.
I asked the Amazon question: What if we treated the building operations workflow as a product experience?
We launched an IoT analytics platform that automated facility decision-making. But the real innovation wasn’t the analytics—it was treating the facility manager’s daily routine as a product to be designed.
Instead of dashboards full of data, we built a system that told facility managers: “Here’s the one thing you should do right now, and here’s why.” The product was the process of running a building.
Customer acquisition increased 40%. Operating costs dropped 20%. Not because we had better analytics, but because we had better product thinking about how analytics should fit into someone’s workday.
The Framework: Three Questions for Product-Led Operations
If you want to apply product-led operations thinking in your organization, start with three questions:
What does the customer actually want to feel? Not what feature they requested. Not what your capability allows. What emotional outcome are they seeking?
Where does your product end? Map every touchpoint from first awareness to long-term retention. If there’s a handoff to “operations,” that’s a product opportunity you’re missing.
What would you measure if you could only measure one thing? Find the metric that best captures customer experience, even if it’s harder to track than operational metrics. Then optimize ruthlessly for that.
Why This Matters Now
We’re entering an era where AI will automate most operational tasks. Route optimization, inventory management, demand forecasting—all of this will become commodity capability.
What won’t become commodity is the ability to design experiences that customers love. The ability to see operations not as execution, but as product. The ability to ask “what should customers feel?” before asking “how do we do this efficiently?”
Amazon taught me that the companies that win aren’t the ones with the best operations. They’re the ones that realize operations and product are the same thing.
That’s the lesson. That’s the advantage. And it’s available to anyone willing to think differently about what they’re actually building.
What’s one operational process in your company that could be reimagined as a product experience? I’d love to hear your examples in the comments.