Experience

Scope of responsibility

Product Director · September 2021–June 2022: Led 2–6 PMs focused on backend and back-office products.

Principal Product Manager · July 2022–May 2026: Worked across multiple teams, primarily Decisioning. Added Banking in December 2025.

Product Director · June–August 2026: Retained Decisioning and Banking while taking on leadership and management of eight PMs.

Why I joined

I joined Lendio to help a FinTech grow from a scrappy startup into an enterprise. My initial responsibility was leading PMs working on lender integrations and the internal tools loan processors used to do their jobs.

As the business explored its marketplace, SaaS, and Forward Flow offerings, my assignments changed. I built a reputation for taking on the tough, gritty work and delivering. Over time, that work became a shared foundation supporting those different parts of the business.

Building around the lender’s policy

Lenders wanted submissions they could trust, evaluated against their own policies using the data sources they preferred. The existing approach could evaluate the latest value available without distinguishing where it came from.

One lender needed TransUnion credit support on a deadline. The longer-term vision was a configurable system that could recognize which data a lender required, retrieve it when missing, and then evaluate the application.

We started with a lender-specific solution to meet the commitment. Each subsequent iteration moved us toward the broader design. The platform eventually supported more data sources and policy rules that could work with multiple owners and collections of data.

My role was to align business and product leadership on the outcome required by the deadline, then work with my engineering lead on how to deliver it. Within the team, ownership was collective. We could meet the immediate need while continuing to build toward a more flexible system.

What changed

Our comparisons showed higher conversion and fewer requests for additional information among lenders using decisioning. Decisions and potential offers were faster. Those lenders also had larger average deal sizes; speed to offer and deal size appeared correlated.

Helping people make their case

One PM I coached was ready for a promotion, but the final decision was outside my control. We focused on delivering outcomes the decision makers could not ignore. He went on to become a director and win Lendion of the Year. The results were his; my part was helping him focus his work and make its value visible.

What I carry forward

If I started again in 2021, I would be more vocal about product strategy and more disciplined about quantifying ROI before accepting a top-down mandate. I would bring the same attention to why we should make an investment that I brought to how we could deliver it.

Why I joined

I joined Shareworks after a layoff at Kuali. I had two offers on the same day and chose the opportunity to return to FinTech, a field I love.

During my time there, I took responsibility for four distinct products: Option Driver, Option Impact, Shareworks Startup, and Scenarios & Valuations. My contribution was often getting up to speed on an unfamiliar product, understanding what the organization needed, and bringing stability to the work.

Saving minutes with a change that took less than a day

Scenarios was a legacy web application that loaded a substantial amount of data at sign-in. Users told me they would log in when they arrived at work, then get coffee and chat while they waited. Once loaded, the application performed well enough.

I added Pendo analytics to see how people used it. More than 90% of the time, the first click after loading was to a different tab. That tab needed much less data.

We changed the default sign-in tab to the one users already chose. The implementation took less than a day. The new starting point took roughly 30 seconds to load and saved users minutes each time they signed in.

Users noticed and appreciated the improvement. Pendo reporting set up to compare behavior before and after the change also confirmed the benefit. Understanding what people actually did exposed a useful improvement that did not require a large engineering project.

View chart at full size (opens in a new tab)

Making survey delivery smoother

The Option Driver and Option Impact suite also included the Venture Capital Executive Compensation Survey. Venture capital firms paid for results delivered in individually customized Excel workbooks.

Those files contained macros that triggered security warnings. I redesigned the workbook so the macros were no longer needed and customization for each firm was faster. The business owners described the 2019 delivery as the smoothest in the survey’s history.

Helping customers grow into the next product

My integration responsibilities included rebranding Capshare as Shareworks Startup and providing a migration path for businesses that outgrew that tier and needed the main Shareworks product.

That work called for learning the products well enough to understand how they fit together and where a customer’s needs changed. Across the four products, flexibility and a willingness to learn were central to taking on what the organization needed.

What I carry forward

Integrating products after mergers is demanding work. It takes the ability to learn multiple products and understand how each fits into the larger business.

I also carry forward the value of paying close attention to everyday friction. A change to the opening tab or a redesigned workbook can make a meaningful difference. The size of the engineering effort is a poor measure of the value to the people doing the work.

Why I joined

Kuali offered a very different environment from FINRA: fewer than 100 employees, a product being built from the ground up, and a team with an embedded UX designer. I wanted that experience.

I brought experience with complex systems and business rules. I also brought habits from a larger organization that did not always fit the urgency of a smaller business. Kuali showed me gaps in my approach and helped me understand how to address them.

Understanding the complexity

My work focused on student enrollment within a new Student Information System. I built relationships with institutional partners and ran several week-long discovery sessions.

During one week at the University of Toronto, we met with representatives from CSU and CSU-Pueblo to work through the rules their institutions needed to follow. Many were enforced through policy rather than software. We explored how a configurable rules engine could give business users a simple experience while supporting complex behavior underneath.

That experience sharpened my approach to early product development: use discovery to identify a focused entry point, keep the first release small, and move quickly toward something customers can use.

Finding a smaller entry point

Toward the end of my time there, my UX partner and I pivoted toward a student-facing schedule optimizer. The full Student Information System was too complex for an initial release. A useful tool that could sit on top of existing systems offered a smaller entry point.

A student would enter their desired courses and scheduling preferences, such as no classes before 9 a.m. or after 5 p.m., with lunch kept free from 12:30 to 1:30. The tool was intended to return two or three optimized schedules that met those criteria.

That pivot made the opportunity more concrete: help a student solve a specific problem without first replacing the institution’s underlying systems. It did not reach production during my tenure, but it changed how I thought about finding the first useful release.

Learning to share discovery

Working with an embedded UX designer also changed my approach. At FINRA, I had done the analysis myself or assigned it to someone reporting to me. At Kuali, my UX partner could lead discovery and return with ideas of their own. The analysis and ideas could come from both of us.

What I carry forward

Speed to delivery matters. A smaller business needs evidence that a product is useful while there is still time and funding to act on it. I believe finding the schedule-optimizer opportunity earlier and delivering a focused version could have given the product a better chance of retaining partner investment.

I also learned to make more room for a UX partner to shape the work. Discovery is a shared responsibility, and a product manager benefits from ideas and analysis that do not all originate with them.

How I got there and grew

I came to FINRA looking for room to grow beyond the role I had held at Thomson Financial. I started in business analysis and testing work on national exam-delivery software. Over nearly 13 years, that grew into product leadership across testing, continuing education, and legal applications.

The work helped me recognize that I was a product manager. Understanding requirements was part of the job. So was understanding the people using the software, building trust with business sponsors, and helping a team make decisions when the consequences mattered.

Knowing when to pause a national rollout

One of those decisions came during a phased rollout of exam-delivery software across Prometric and Pearson VUE testing centers. The national platform served roughly 500,000 exams a year, so we planned the rollout around disciplined monitoring and agreed stop conditions.

When monitoring showed missing exam-log data, we looked for other examples and found them. We knew there was a problem before we knew its cause. We paused immediately.

Final scores were unaffected. The missing records concerned timing and changes to individual question responses. If an interrupted exam needed to restart, incomplete records could restore the wrong remaining time or omit a response. Those records also mattered for auditability and test calibration.

We had agreed pause and rollback procedures with the testing vendors before deployment began. Coordinating the pause meant notifying the key leaders at each vendor. Within an hour of notification, the rollout was paused.

Earning the decision to resume

Engineering traced the defect to a race condition involving disk writes. I helped reproduce the error locally, tested the corrected executable, and coordinated its distribution with the vendors.

Once we understood the defect, the team could build tests that reproduced it. We then used those same tests to verify the fix. That testing round trip was required before we resumed the pilot and continued the rollout to completion.

The safeguards had been agreed before the pressure arrived. When the evidence told us to stop, the team and vendors already knew how to act.

Modernizing the work and developing the team

Other work included replacing fragmented continuing-education authoring tools with a web application. When publishing differences between vendors required a recurring workaround, I diagnosed the export issues and handled the monthly content packaging and activation coordination. At roughly one day a month, I chose not to prioritize automating that work.

As my responsibilities grew, I led delivery across teams of up to 24 people, including PMs, developers, and test engineers. I helped early analysts grow into lead product and management roles, while moving teams toward more frequent delivery and retiring legacy applications.

What I carry forward

Building a culture of trust and psychological safety produces the collaboration required for the best solutions. People need room to raise a concern, challenge an assumption, or ask for help. That requires trust in each other and clarity about the standards we are working toward.

I carry that into how I work with engineering and business partners: agree on the outcome, make it safe to surface problems, and give the team room to find the solution together.

Research, learn, and write

I finished school during the dot-com boom knowing I wanted to work in technology. I liked reading and writing, and I had chosen an English degree after asking my father what he looked for when hiring people at his consulting firm.

His answer was simple: “I look for someone who can research, learn and write; I can teach them everything else they need to know.”

Writing manuals and help systems looked like a way into the industry. In each early role, the documentation work eventually gave way to testing. I found automated testing more engaging than repeating manual tests, so I learned the tools.

The combination opened my eyes to how systems were built and how people interacted with them. I discovered that I enjoyed finding problems and figuring out how to solve them.

Making the evidence visible

At Thomson Financial, I wrote performance and stress tests for ThomsonONE wealth management before its initial launch. My tests simulated user activity, gradually increasing the load from five users to 100 while monitoring server metrics.

I could see memory usage climbing with the user load until errors appeared. That pattern led me to flag a likely memory leak and estimate the load the production hardware could support.

The findings were questioned because I was new to automation and the test environment was smaller than production. I raised the risk, but the decision was to proceed. As I recall, the application failed about an hour after launch, consistent with what I had predicted.

I then configured and ran the tests against production at midnight, on conference calls with developers and system engineers watching the behavior. Engineering owned the technical diagnosis and code changes. My contribution was making the behavior reproducible and testing whether those changes resolved it.

The product returned to production when my tests passed without the memory pressure.

What I carry forward

That experience taught me to trust my findings when I have done the work to support them and to make sure decision makers understand the risk.

It also taught me that others may have information and visibility I do not. I can make a clear recommendation, disagree with a decision, and still respect the responsibility of the people making it. If the team needs help afterward, the work is to help solve the problem.

Research, learning, and clear communication became the foundation for how I approach product work. Testing added the discipline to make an observation, check it, and turn it into something the team can act on.