Senior Product Designer at Podium

Customers needed an explanation, not just a total

Customer Success and Sales repeatedly heard that customers wanted more from Payments. The existing experience showed transactions and a few monthly totals, but stopped at the surface. A business owner could see money moving without understanding what contributed to it.

That gap mattered because Payments was part of the daily operating rhythm. One customer told me it was the first place he looked each morning to estimate how much money the business had and whether he could pay someone.

Better reporting was already recognized as an opportunity, but it sat deeper in the roadmap. The hackathon let me turn that known need into a complete working direction that leadership and customers could evaluate instead of leaving it as a future concept.

The existing reports answered only the first question

The Daily view listed transactions with fees and net amounts. Monthly summarized money in and money out. Insights showed deposited funds, refunds, fees, chargebacks, adjustments, and a total.

These views helped customers notice a number, but not explain it. They could not compare payment methods, card brands, locations, readers, staff, or customer behavior to understand what was shaping the business.

“Payments was the first place I looked at the beginning of the day because I wanted to know how much money I had.”

Customer interview insight

Fourteen reporting areas became a simpler mental model

I combined customer conversations with product and competitive research to identify the information businesses could use. The first pass surfaced roughly 14 reporting areas across money in, money out, operations, and retention.

Exposing all of them as equal destinations created a new problem: the reporting system felt larger than it needed to. I consolidated the structure into Financial Overview, Cash Flow, Risk & Operations, and Growth & Retention, then used tabs for related ways of examining the same question.

Customer response: Customers said the grouped version felt more organized and less overwhelming, even though it gave them access to substantially more information.

Keep the question stable, then change the lens

Within Cash Flow, the Volume report became one destination with focused views for Time, Payment Method, Card Brand, Card Reader, and Staff. Customers did not have to learn a different page for every breakdown.

Summary metrics established the answer quickly, charts made distribution visible, and tables provided the detail needed to trace activity.

Broader value: The customer could now understand payment type, card usage, and location patterns. That visibility also informed how he thought about marketing the business.

Connected system: Because Payments was part of the broader CRM, businesses could relate transaction activity to locations, staff, and who was working that day.

A hackathon created the opening; collaboration made it real

Podium used the hackathon to help designers and product managers become builders with AI. I turned a recurring issue raised by Customer Success and Sales into a working concept, validated the direction with customers, and built the first version with mock data.

I used ChatGPT to explore and organize ideas, then Claude Code, structured Markdown documentation, and reusable skills to build the experience. AI shortened the distance between the idea and a working product; it did not replace product judgment, customer validation, or technical review.

I worked in lockstep with an engineer throughout the build so the AI-assisted implementation was continually validated. The project was also reviewed during development with Sales, Customer Success, the Payments team, and the CEO. Their support helped approve the direction while it was still being built.

The project won the hackathon and moved forward as a production initiative. I pushed the implementation into GitLab and partnered with engineers through code review. They provided technical guidance and connected the reports to live backend data before release.

More useful financial visibility reached production

The full reporting experience shipped with live data. In comparative feedback, the customer strongly preferred the updated version because it made the movement of money easier to understand and investigate.

A current Podium engineer later confirmed that the work remained impactful because it gave customers substantially more information about their payments.

Evidence limit: I do not have reliable adoption or revenue metrics, so I treat customer response and internal confirmation as qualitative evidence rather than claiming a quantified business result.

The product improved, but the rollout taught me just as much

The first implementation arrived as one very large code change and introduced a substantial amount of new reporting at once. Some familiar functionality was restored after feedback because the change was disruptive for existing customers.

Today I would involve Engineering earlier, break the implementation into smaller reviewable increments, protect established workflows during transition, and define launch measurement before release. The lesson was not to make the idea smaller; it was to make the path into the idea more deliberate.