I started my career with an engineering background, but what fascinated me most was never just how technology worked. It was understanding why we were building something in the first place and whether it genuinely solved a problem.

Product management gave me the opportunity to connect technology with human behavior, business needs and real-world outcomes.

Early in my career, I was naturally focused on delivery. How do we build this? How quickly can we launch? How do we get the requirements right?

Over time, especially working in operationally complex industries, my questions changed.

Why does this process exist? Who actually benefits from it? What happens before and after someone uses our product? Are we solving the root problem or simply digitizing an inefficient process?

One of my biggest realizations was that digitizing a broken process does not fix it. It simply makes the broken process digital.

Today, I spend considerably more time understanding systems, challenging assumptions and identifying the right problems than immediately discussing features.

I have also learned that great product leadership requires knowing when not to build something. Sometimes the most valuable decision is simplifying an existing workflow, changing a business process or removing a feature entirely.

My approach has evolved from building products to building outcomes. That shift has fundamentally changed how I lead teams, engage stakeholders and define success.

Different industries often appear to have completely different problems. But when you look beneath the surface, the patterns are remarkably similar.

Information is fragmented. Teams operate in silos. Processes depend on manual intervention. Customers have limited visibility. And people develop workarounds because existing systems do not support how they actually work.

I have encountered these challenges in almost every industry.

At Tradeling, scaling fulfilment meant understanding what happened beyond the digital interface, including warehousing, order processing and the physical movement of goods.

At CAFU, mobility services required technology to work seamlessly with real-world operations. A beautifully designed application meant very little if the operational ecosystem behind it could not deliver the promised experience.

Today, in business aviation, the complexity is even more pronounced. A single trip can involve multiple countries, regulations, service providers, operational teams and systems. A seemingly small product decision can have significant downstream consequences.

These experiences taught me something important: complexity is rarely a technology problem alone. It is usually a coordination problem disguised as a technology problem.

The solution begins with understanding the complete operational journey, not just the screen someone interacts with.

My biggest advantage from working across industries is that I do not automatically accept industry conventions as limitations. Sometimes the best solution comes from applying a principle that worked successfully somewhere entirely different.

Technology changes. Industries change. But the fundamentals of understanding people, simplifying processes and creating value remain surprisingly consistent.

I believe product management exists at the intersection of three realities: what customers need, what the business must achieve and what technology can sustainably support.

The challenge is that these three do not always agree.

A customer might request a feature that solves an immediate inconvenience. The business may be focused on efficiency or cost reduction. Engineering may be dealing with architectural limitations that are invisible to both.

My responsibility is not to automatically choose one side. It is to understand the underlying problem and find the best possible outcome.

One principle I follow is to separate a customer's requested solution from their actual need. Customers are incredibly valuable at explaining their frustrations, but the solution they propose is not always the most effective one.

Similarly, business priorities need to be translated into measurable outcomes. If the objective is cost reduction, the conversation should not immediately become about reducing resources. It should be about identifying which processes create unnecessary cost and whether automation can remove that burden sustainably.

Technical constraints matter, but they should inform the solution rather than end the conversation.

At UAS, we work with operational teams whose processes are deeply interconnected. We cannot make decisions in isolation because a change that benefits one department might create additional work for another.

I encourage teams to understand those dependencies early, involve the right stakeholders and evaluate decisions against their broader operational impact.

Ultimately, good product decisions are not about making everyone happy. They are about making informed trade-offs that create the greatest sustainable value.

I believe we are entering a particularly exciting phase of technology, especially for industries that have historically relied on human expertise to manage operational complexity.

For years, digital transformation largely focused on moving manual processes into software. We built dashboards, workflows, forms and reporting tools.

That was necessary, but it was only the beginning.

The next opportunity is to build systems that do more than store information. Systems that understand context, connect fragmented data, identify risks and help people make better decisions.

Consider business aviation. Planning a flight involves evaluating aircraft capabilities, airport restrictions, weather conditions, regulatory requirements, fuel availability and operational feasibility. Much of that information exists across different systems and requires experienced people to interpret it.

With SkyX, our AI-powered flight feasibility initiative at UAS, we are exploring how these considerations can be brought together to support faster, more informed operational planning.

But the opportunity extends far beyond aviation.

In logistics, AI can anticipate disruptions and recommend alternatives. In mobility, it can improve demand forecasting and resource utilization. In enterprise operations, it can automate repetitive decisions and surface exceptions that genuinely require human judgment.

However, I strongly believe that AI should not become another interface employees must learn to operate. Its real value is reducing the amount of work they need to do in the first place.

The greatest transformation will happen when AI, automation and connected data become embedded within everyday workflows.

My vision is not to replace operational expertise. It is to give experts better information, remove repetitive work and allow them to focus on decisions where their experience matters most.

One of the biggest misconceptions about B2B products is that user experience matters less because the customer is a business.

I believe the opposite.

In consumer products, the person choosing, paying for and using the product is often the same individual. In B2B, those responsibilities can belong to completely different people.

The person purchasing the software may care about return on investment. Management wants visibility and control. Operational teams need efficiency. End users want simplicity.

And sometimes what one stakeholder wants creates friction for another.

This means B2B product strategy requires a deeper understanding of the entire value chain.

At CAFU, for example, delivering mobility solutions involved connecting the digital customer experience with the operational teams responsible for fulfilling the service.

At UAS, a customer-facing capability in GTMX may depend on internal operational workflows, backend services and integrations with third-party systems.

The customer experiences one product, but delivering that experience requires an entire ecosystem to work together.

My approach is to distinguish between the buyer, the user, the operator and the beneficiary, then understand what success means for each.

The product must create commercial value for the business while making the daily experience better for the people using it.

I often remind teams that B2B users are consumers too. They use intuitive, beautifully designed applications in their personal lives and should not have to lower their expectations when they arrive at work.

Enterprise complexity is not an excuse for poor product experiences. It is precisely why thoughtful product design matters so much.

One of the most defining experiences in my career was working on large-scale digital transformation at CAFU.

We were dealing with an operational environment where customer journeys, internal processes and supporting systems had to evolve together. Migrating thousands of B2B customers was not simply a technical exercise. It required understanding established customer behaviors, operational dependencies, data readiness and the risk of disrupting an existing service.

The challenge was balancing the ambition to modernize with the responsibility to maintain business continuity.

What made the experience particularly valuable was realizing that a technically successful migration does not automatically translate into a successful customer experience.

You can move customers onto a new platform, but if the experience introduces confusion, disrupts familiar workflows or creates additional work for operational teams, the transformation is incomplete.

It reinforced the importance of phased execution, cross-functional ownership, clear communication and measuring success beyond the launch itself.

Another important lesson was that leadership during transformation is less about having all the answers and more about creating clarity when multiple teams are dealing with uncertainty.

I learned to bring people closer to the problem, make trade-offs visible and establish shared accountability for outcomes.

Those lessons continue to shape how I lead product transformation today.

A successful transformation is not when the new system goes live. It is when the business and its customers are genuinely better off because of it.

Scaling is often misunderstood as acquiring more customers, launching in more markets or adding more capabilities.

To me, real scalability means the business can grow without complexity, operational effort and customer friction growing at the same rate.

I learned this particularly through my experiences in mobility and logistics, where digital products depend heavily on physical operations.

At CAFU, expanding mobility services and working on new propositions, including electric vehicle services in Canada, required us to think beyond the application. We had to consider whether the operational model, supporting systems and customer experience could work together in a different market.

At Tradeling, building fulfilment capabilities reinforced the same lesson. Growth exposes every weakness in a process. What works through manual coordination at a small scale can become a significant bottleneck when transaction volumes increase.

My approach to scaling rests on a few principles.

First, simplify before automating. Automating unnecessary complexity only makes it harder to change later.

Second, build reusable capabilities instead of solving every new requirement as an isolated feature.

Third, make operational visibility part of the product. Teams cannot manage what they cannot see.

And finally, treat customer feedback as an ongoing input, not something collected only before launch.

I also believe in progressive transformation. Large, disruptive changes may look impressive on a roadmap, but smaller, carefully managed improvements often deliver more sustainable value.

The true test of scale is whether your thousandth customer receives an experience as thoughtful and reliable as your first.

I think the biggest risk for product leaders today is confusing AI adoption with AI strategy.

Integrating a large language model into a product is becoming increasingly accessible. Building an AI-powered experience that is accurate, trustworthy, commercially viable and genuinely useful is a very different challenge.

Product leaders need to understand how AI systems behave, where they fail and what it takes to operate them responsibly.

That includes understanding data quality, context engineering, retrieval, model limitations, evaluation frameworks, latency, cost and the importance of human oversight.

But technical literacy is only part of the equation.

The more important question is whether AI is solving a meaningful problem.

I have seen how easily organizations become excited about the technology before clearly defining the business outcome. That creates a risk of investing in impressive demonstrations that never become valuable products.

In operationally sensitive industries such as aviation, the consequences of incorrect information can be significant. An AI system must distinguish between verified information, assumptions and uncertainty. It also needs clear boundaries around decisions that require human validation.

I believe product leaders should approach AI with both ambition and healthy skepticism.

We should experiment aggressively, but evaluate rigorously.

And we should measure outcomes such as time saved, decision quality, reduced errors and improved customer experience rather than simply counting AI features shipped.

The future will not belong to companies that use the most AI. It will belong to those that apply AI to the right problems with the greatest discipline.

Building a leadership career in technology has taught me that competence, confidence and influence are three different things.

You can be exceptionally capable, understand your domain and consistently deliver results, yet still need to learn how to communicate your perspective with conviction.

Over the years, I have learned that leadership is not simply about being the person who knows the most. It is about being willing to make difficult decisions, challenge assumptions and take accountability for outcomes.

Working across engineering, commercial, operations and executive leadership environments has required me to develop that confidence continuously.

One lesson I would share with women is not to wait until you feel completely ready before pursuing an opportunity.

Growth often happens when you take responsibility for something that initially feels bigger than your experience.

I would also encourage women to build strong technical and commercial understanding. Product leadership requires more than empathy, communication and stakeholder management. You need to understand technology, business economics and how decisions translate into measurable outcomes.

And importantly, develop your own point of view.

It is easy to spend a career becoming excellent at executing other people's ideas. Leadership begins when you start bringing your own thinking to the table and can explain why you believe in it.

I want more women to see themselves not just as participants in technology, but as people who can shape its direction.

You do not need to be the loudest voice in the room. But you should never underestimate the value of having a voice worth listening to.

I believe the next major shift in enterprise technology will be from systems that help people manage work to systems that actively help them complete it.

For decades, businesses have invested in software that records transactions, tracks tasks, generates reports and provides visibility.

But employees are still responsible for connecting information across systems, interpreting what it means and coordinating the next action.

AI agents, intelligent automation and interoperable platforms have the potential to fundamentally change that model.

Imagine an operational system that does not simply tell you a service is delayed, but understands the downstream impact, identifies alternative options, prepares the necessary actions and brings the right decision to the right person.

Or an enterprise platform that can connect commercial commitments, operational delivery and financial reconciliation without requiring employees to manually transfer information between disconnected systems.

That is the kind of transformation I find most exciting.

I am particularly interested in the convergence of AI, workflow orchestration, predictive intelligence and enterprise data.

However, I do not believe the future is entirely autonomous. In complex, high-stakes environments, the most successful products will combine machine intelligence with human expertise, accountability and judgment.

As for what I hope to build next, I want to continue creating products that challenge the way entire industries operate.

Products that make sophisticated capabilities accessible, reduce unnecessary complexity and create measurable value at scale.

Ultimately, I want to build technology that makes the difficult invisible, so people can focus on what actually matters.

One belief that has stayed with me throughout my career is that simplicity is not the absence of complexity. It is the result of understanding complexity deeply enough to remove it from the user's experience.

When someone completes a task in a few clicks, they rarely see the years of operational knowledge, business rules, integrations and design decisions that make that simplicity possible.

That is what I find most rewarding about product management.

The real achievement is not how sophisticated the technology appears. It is how naturally it fits into someone's life or work.

I believe the best product teams are the ones willing to take on complexity themselves rather than passing it to their customers.