About
My story isn’t a résumé. It’s how I learned to build.
My path into Product Management was not a planned sequence of titles. Entrepreneurship taught me to own outcomes. Technology taught me how systems are built and where they fail. Product Management taught me how to connect customer needs, business goals, data, and technical execution.
Starting With Ownership
I learned to think like an owner before I had a product title.
I started as an entrepreneur, not as a Product Manager. Building and operating my own business meant owning outcomes directly: understanding customers, prioritizing what mattered with limited resources, making financial and delivery decisions, and being accountable for the result.
That experience taught me to pay attention to what customers actually needed rather than what they said they wanted, to make decisions with incomplete information, to balance short-term demands against long-term value, and to measure success through outcomes rather than effort. When something didn't work, there was no one else to defer to.
Moving Into Technology
Then I had to learn how things actually get built.
I entered technology through software quality, testing, delivery, and data validation, working closely with engineers, data teams, and business stakeholders rather than writing requirements from a distance. That meant hands-on experience with SQL validation, analytics platforms, reporting systems, and dashboards: understanding requirements, coordinating releases, and being responsible for product quality and data trust.
A feature is not complete because it appears on a screen. The data must be accurate, the workflow must make sense, and users must trust the result. That principle came directly from this stage, and it still shapes how I evaluate whether something is actually ready to ship.
Becoming a Product Manager
Product Management is where those two educations met.
My Product Management work developed from operating between customer needs, business questions, data, and technical execution: leading customer and stakeholder discovery, shaping product direction and roadmap decisions, prioritizing, writing requirements, supporting the backlog, tracking metrics, and communicating value to leadership across cross-functional delivery.
Most of that work has come down to the same shift, again and again: turning fragmented reporting, inconsistent data, manual workflows, unclear requirements, and disconnected dashboards into trusted analytics and decision support products people actually rely on.
Modern Product Judgment
AI changes what products can do. It doesn't remove the need for judgment.
I'm interested in the space between complex existing systems and modern product experiences: finding where better workflows, stronger data foundations, automation, natural language, or intelligent analysis can reduce customer friction.
It also means recognizing when a structured, rules-based workflow is more dependable than a generated answer. Financial calculations, permissions, approvals, data validation, and final transactions require consistency and clear controls. Exploration, synthesis, search, explanation, and discovery may benefit from more flexible AI experiences. For me, modernizing a product isn't about adding AI everywhere. It's about choosing the right approach for the customer problem.
What I Believe
Principles I try to build by.
See how I apply this thinking.