Scaling Digital Commerce: Turning Everyday Transactions into Revenue Growth for Merchants
Building for E-Commerce

Kwiksell was a SaaS commerce platform designed to give small and growing businesses a single place to sell online, collect payments, issue invoices, manage retail activity and understand business performance.
When I joined the product, the opportunity was bigger than building another online selling tool. Many merchants were already selling through social channels, collecting payments manually and managing their businesses across spreadsheets, messaging apps and disconnected tools.
The product challenge was to turn those fragmented activities into a connected merchant experience, while building enough trust in the platform for merchants to use it as part of their daily business operations.
💡 At launch, Kwiksell generated more than $150,000 in revenue and achieved 100% user growth.
Merchants could sell, but they couldn't always see the business.
Kwiksell operated across several critical parts of the merchant journey:
Sell → Collect → Track → Understand
A merchant could create a sale, receive a payment or issue an invoice, but the information needed to understand what was happening across the business was often fragmented.
This created practical questions that the product needed to answer:
The deeper problem was therefore visibility and trust.
Merchants did not necessarily need more functionality. They needed confidence that the platform reflected what was actually happening in their business.
That became the central product problem I used to shape the roadmap.

Product Manager (me), 4 Software Engineers, a Product Designer, a UX Researcher. For this project, I also frequently aligned with the Customer Service team.
I combined qualitative and quantitative signals to understand where merchants were experiencing the most friction.
My inputs included:
Across these signals, a consistent pattern emerged:
💡 The biggest opportunity was not adding more features. It was reducing the blind spots merchants experienced while running their businesses.
This changed how I thought about prioritisation.
Rather than treating commerce, payments, invoicing and reporting as separate feature areas, I looked at them as connected parts of one merchant operating journey.
If a merchant could not confidently answer "Have I been paid?", better reporting would not solve the underlying problem.
If onboarding prevented a merchant from reaching their first successful transaction, adding more downstream functionality would not improve activation.
The roadmap therefore needed to strengthen the fundamental merchant journey first.

I focused the product strategy around four connected merchant needs:
1. Sell
Make it easier for merchants to get their products and businesses online and start transacting.
2. Collect
Make payment collection simple, reliable and transparent, particularly around payment status.
3. Track
Give merchants a clear record of sales, invoices, transactions and customer activity.
4. Understand
Turn activity into useful business information that could help merchants understand performance and make decisions.
This framework gave the team a clearer way to evaluate roadmap opportunities.
Instead of asking:
"Should we build this feature?"
we could ask:
"Which part of the merchant journey does this improve, what problem does it solve, and what business outcome should it influence?"
I owned product strategy, roadmap direction and delivery priorities across commerce, payments and reporting.
I worked closely with:
I also managed and coached Product Managers working across merchant onboarding, payments, reporting and customer experience. My responsibility was not simply to maintain a roadmap. It was to create alignment around why we were building, establish clear priorities and ensure that individual product initiatives contributed to the broader business strategy.
One of the challenges was balancing merchant needs, commercial requests, customer feedback and internal feature demands. I introduced greater discipline into how the team evaluated opportunities by connecting roadmap decisions to:
Merchant problem → Product opportunity → Business outcome → Success metric
This helped move conversations away from isolated feature requests and towards the underlying problems we were trying to solve. I also strengthened the product operating rhythm through clearer roadmap planning, backlog quality, discovery practices and delivery reviews. For the PM team, this created a stronger connection between individual workstreams and the overall Kwiksell strategy.
Simplify Onboarding
Activation was a critical part of the merchant journey. If merchants could not reach value quickly, downstream product functionality had limited impact. I prioritised reducing friction in onboarding and improving the path towards meaningful first use. The objective was straightforward:
Get merchants from sign-up to successfully using the core product with less friction.
Make Payment Status more visible
Making payment status more visible
Payment was one of the highest-trust moments in the product.
A merchant needs to know whether money has actually been received, whether a payment is pending and whether an issue requires action.
I prioritised clearer payment status and transaction visibility so that merchants could understand what was happening without relying on manual reconciliation or support.
This reinforced the wider product principle that visibility creates trust.
Strengthening invoice and sales tracking
Invoices and sales activity were not just transactional records. They were part of the merchant's operational workflow.
I prioritised improvements that helped merchants understand what had been sold, what had been invoiced and what remained outstanding.
This brought more of the merchant's day-to-day business activity into the platform.
Prioritising reporting around real business questions
Rather than building reporting for the sake of reporting, I focused the team on the questions merchants actually needed answered.
The goal was to make business performance easier to understand without requiring merchants to manually combine information from different systems.
This helped position reporting as part of the core merchant experience rather than a separate analytics feature.

How might we empower customers to act confidently and decisively during high-risk transactions, while reducing fraud losses and meeting regulatory standards of care?
The Design Challenge
ABOUT ME
WORK
CONTACT