Curiosity Before Credentials

I have always been technically curious. That curiosity predates cloud platforms, modern developer tooling, and artificial intelligence. When I graduated from college in the 1990s, I did not start my career as an engineer. My formal training was in business. Still, I felt a persistent pull toward how software actually worked. I taught myself Visual Basic to automate real-world problems. I learned basic networking because systems felt fragile and opaque. I started learning C++ because I wanted to understand what serious software development looked like. I was not trying to become a programmer. I was trying to understand how ideas became executable reality.

A Career Built on Translation

That instinct shaped the next thirty years of my career. I worked across some of the world’s largest technology companies and smaller, fast-growing ones. I held roles in product management, product marketing, and eventually engineering leadership. At various points, I ran engineering organizations numbering in the hundreds. Despite the scale and variety, the core challenge remained the same. Someone had intent. A market opportunity. A vision. My job was to translate that intent into something teams could build, operate, and scale.

Why Product Management Really Matters

This is why product management matters far more than most people realize. At its core, product management is the discipline of translation. It sits between strategy and execution, between ambiguity and precision. A great product manager does not simply collect requirements. They shape them. They decide what must be explicit and what must remain flexible. They write documents that reduce uncertainty without eliminating engineering judgment. This is not administrative work. It is intellectual labor.

The best product managers I have worked with are exceptional writers. Not because they enjoy documentation, but because writing forces clarity. Engineers do not struggle because they lack skill. They struggle when intent is unclear or contradictory. A well-written product requirements document reflects deep thinking about tradeoffs, constraints, and outcomes. It shows respect for the people building the system. It acknowledges what is known, what is unknown, and what must be discovered through iteration. This craft takes years to develop, and it sits at the heart of building enduring technology companies.

Learning to Write by Working Backwards

One of the most formative chapters of my career came during my time at Amazon. Amazon did not treat writing as a communication preference. It treated writing as an operating mechanism. The working backwards process required ideas to be expressed clearly, completely, and defensibly before a single line of code was written. Press releases, FAQs, and narrative documents were not artifacts. They were the work.

That discipline changed how I think. Writing exposed weak thinking immediately. If you could not explain a customer problem crisply, you did not understand it. If you could not articulate tradeoffs, you had not made them. There was no hiding behind slides or slogans. The document had to stand on its own. This obsession with detail was not pedantic. It was practical. Writing forced decisions earlier, when they were cheaper to change. It aligned teams before execution began. It respected engineers by giving them a clear intent rather than an ambiguous direction. Over time, I internalized that rigor, often without realizing how foundational it would become.

When Product Leaders Become Engineering Leaders

Later in my career, I transitioned from leading product management teams to running engineering teams. My first role in an engineering leadership capacity was at Xero, during a period of intense growth. I loved my time there. The people were exceptional. The mission was real. Still, that transition was more challenging than I expected.

I had not coded seriously in a long time. I understood systems and architecture conceptually, but I struggled to relate to frontline builders in meaningful, credible ways. I could not always feel the friction they felt. I could not always distinguish between complex problems and merely annoying ones. That distance mattered. Outstanding engineering leadership is not about telling engineers what to do. It is about earning trust. Trust comes from understanding the constraints people live with every day.

Relearning to Build, With Help

Looking back, that role was a significant learning moment. Careers are full of those inflection points. You do not always recognize them while you are in them. You see them clearly later. I often think about how different that experience might have been if I had access to today’s AI tools.

Over the past year, I have returned to hands-on building. I have been learning Python again. Then React. Then newer protocols and patterns that did not exist earlier in my career. This time, I had a new kind of collaborator by my side. AI did not replace thinking. It demanded it. It helped me learn to code again without pretense. It helped me debug not just syntax but also logic. It walked me through why something failed, not just how to fix it.

AI as a Mirror, Not Magic

In doing so, it gave me a window into the daily reality of modern developers that I had not had before. I feel the friction again. The false starts. The cognitive load. The satisfaction when something finally works. That experience has changed how I think about engineering leadership. It has changed how I listen. It has changed how I write.

This is where many fears about AI miss the point. AI is not magic. It is a multiplier. It amplifies clarity. It amplifies confusion. It responds to what you write, not what you mean. In this way, AI behaves much like an Amazon review meeting. Weak logic shows itself quickly. Muddled narratives produce muddled outcomes. Strong inputs produce surprisingly strong results.

The Cost of Translation Has Collapsed

What has truly changed is the cost of translation. In the past, turning a product idea into a working prototype required significant coordination and time. Today, with clear intent and disciplined inputs, that loop is dramatically shorter. In a matter of weeks, I built a working prototype with real depth. Not a slide deck. Not a mock. A system that encodes decisions and reveals its own limitations. AI did not do the work for me. It removed friction between thinking and execution.

Why This Moment Belongs to Product Managers

This is why I see AI as an opportunity, not a threat, especially for product managers. Product management has always been about judgment under uncertainty. AI accelerates the feedback loop. The skills that have always mattered still matter most. Clear writing. Structured thinking. Respect for constraints. AI makes those skills unavoidable.

For product managers and technology leaders willing to embrace this moment, AI is not a disruption to fear. It is an accelerant for good judgment, grounded leadership, and disciplined execution. The distance between idea and reality has never been smaller. And that makes the craft of product management more critical than ever.

Are you in Product Management? What are your thoughts?