Selected work

The problems behind the work.

Three stories about listening closely, understanding where friction lives, and helping a customer, a product organization, and an emerging technology move forward.

01Customer

Listen

02Product

Understand

03Category

Shape

Listening before solving

Start with what isn't working.

One of my most notable successes as a Solutions Engineer started as a relatively low-signal higher education opportunity.

A medical school in Boston had issued an RFP to address deficiencies in its existing project management software. I knew we had a powerful product, but I went into the first discovery call less interested in demonstrating what it could do and more interested in understanding what wasn't working.

The CTO was gregarious. Before we got anywhere near software, she told me about singing and her interests.

Eventually, the conversation moved into the challenges her organization was facing: reporting wasn't giving them what they needed, their existing systems weren't being adopted consistently, and they were struggling to understand work across the organization.

So I listened.

Only after I understood the problems did I start showing her where our software could help.

That initial opportunity eventually grew into a multi-department university purchase. The CTO became an advocate in large part because she believed I understood the challenges they were trying to solve, not simply the product I was trying to sell.

That experience crystallized something I've carried into every role since:

Be curious. Listen. Then advise.

Building the story around an acquired product

Understand the product through the work customers are doing.

Supplier Data Manager came to me at an inflection point in my own time at the company. My department had changed, the manager who hired me had moved on, and I was given an opportunity to take ownership of something that interested me and deepen my impact within the organization.

I chose Supplier Data Manager.

I've always been interested in data transformation, and this was a product line that had come into the company through an acquisition and had never had dedicated product marketing support. That meant there wasn't an established playbook waiting for me. I had an opportunity to learn the product alongside new leadership, understand the problems it was uniquely positioned to solve, and help create the story around it.

What emerged was a much clearer way of understanding the product through the work our customers were actually trying to do:

CollectTransformDistribute

Those three ideas became more than messaging. They gave us a shared way to explain the product, organize its capabilities, and connect what we were building to the customer problems behind it.

My approach

When I took ownership of Supplier Data Manager, I saw two possible paths forward. We could revisit the product's pricing and packaging, or we could focus on enabling the organization to better understand and sell what we already had.

Before choosing, I wanted to understand where the friction actually was.

Through a combination of qualitative and quantitative analysis, I found an interesting disconnect. The product was compelling to me, but to many of my sales counterparts it felt highly technical and difficult to approach. Before changing what we sold or how we packaged it, we needed to make the existing value easier to understand.

That was something I could help fix while continuing to deepen my own understanding of the product.

I started by developing clearer product descriptions and a stronger narrative around the problems Supplier Data Manager solved. From there, I created a qualification framework that gave commercial teams a more practical way to recognize the right customer problems, ask better questions, and understand when the product belonged in a conversation.

Then I rolled that framework out across the organization.

The work reinforced something I continue to believe: before changing the product, you need to understand where the friction actually lives.

Positioning an emerging technology while it's still emerging

Learn while the category is still being defined.

MCP was, and continues to be, a difficult problem because the technology itself is evolving. It represents a new standard for how AI interacts with software, and we knew early that we wanted to explore the space quickly.

We started with the problems we could solve: what this new integration method made possible and why developers would care. As we expanded the use cases and brought the technology to customers, though, we learned that functionality was only part of the story.

Customers wanted to understand governance.

AI has introduced a confidence gap that follows it wherever it touches data. Customers weren't only asking, What can this do? They needed to understand what the AI could access, what remained under their control, and whether they could trust the interaction.

That changed how I thought about the positioning problem.

What can this do?

What can the AI access?

What remains under my control?

Can I trust the interaction?

Working in an emerging category means learning while the category itself is still being defined. It requires enough technical understanding to explain what's possible, enough curiosity to recognize when the questions are changing, and enough humility to let what you learn reshape the story.

Learning and applying those lessons in real time has been one of the most rewarding problems I've had the opportunity to work on.

My role

MCP became one of several moments in my career where my participation in product development extended beyond the traditional boundaries of my role.

For the first time, I wasn't only being asked to determine how we would tell the story of something after it was built. I was invited into the questions that came before that story: What should this feature actually do? Which problems should it solve? How should developers understand and use it? How do we document it? And ultimately, how do we translate all of that into something meaningful for the broader market?

That changed the nature of my contribution.

I was able to bring customer context and market perspective into product conversations while developing enough technical depth to challenge assumptions, ask better questions, and help shape the product itself.

The story wasn't something we applied at the end. It developed alongside the product.