Self Serve Publishing

Helping furniture makers create ecommerce listings faster and more reliably

Company
CommerceBear
Role
Senior Product Designer
Period
2024 -2025

87.5%

Reduced Time-to-Submission

30%

Reduced Ops Weekly Project Load

2

Net Promoters Created

At CommerceBear, I led the design of a self-serve web app that enabled furniture manufacturers to publish their products across five major e-commerce marketplaces simultaneously. This replaced a manual, agency-style process and became the foundation of the company’s product-led strategy.

While we did manage to release a successful MVP, getting there took several lengthy iterations due to a complex initial product vision.

Those failures served as a key learning for me to become more involved in the product requirements stage of the process - something that I was able to apply within this project to contribute to the product that we ultimately released.

Background & Opportunity

Historically, furniture manufacturers were slow to adopt e-commerce due to product complexity, cost, and return logistics. COVID-19 changed that - without access to in-person showrooms, online sales became a necessity.

However, each marketplace (Wayfair, Amazon, Walmart, etc.) has its own complex and inconsistent product data requirements. Manufacturers often needed internal experts dedicated to each channel.

CommerceBear’s original agency model helped manufacturers that were net-new to e-commerce get online, but it was labor-intensive, slow, and unsustainable for scale.

We saw an opportunity to productize the process, enabling all manufacturers to self-publish efficiently with or without deep marketplace expertise.

An Important Lesson LEarned

A common refrain from our customers had always been that they were frustrated by having to spend their entire day in Excel. This led to a company-wide sentiment that our product needed to minimize the amount of spreadsheet work being done by the user at almost any cost. But this problem was too broad and undefined. We had no clear direction, and the solutions that I designed grew overly complex before ultimately failing.

When reflecting on these iterations, I came to the conclusion that the team lost significant amounts of time developing them because I wasn't involved in product requirements definition and didn't push back when I was struggling to conceive of simple design solutions.

For example, when presented with the challenge of replacing excel in our app, I could never clearly visualize what a solution might ultimately look like - which should have been a signal to spend more time defining the use cases we wanted to target and any additional functionality we might be willing to cut from an MVP, rather than continuing to push further on the designs.

A new Approach: Back to Basics

I immediately put this learning into practice on our next iteration, partnering directly with our CTO to define a constrained, testable version of the publishing experience that could deliver value fast while validating our core assumptions.

We established clear, achievable product rules:

  1. Embrace spreadsheets (for now):  Trust that users will want to use the product if it increases their efficiency enough to justify the price, regardless of how much spreadsheet work is required

  2. Start narrow: Support only the Rugs and Lighting product categories in V1 - these have simpler requirements across marketplaces and still contained a reasonable number of customers willing to become early adopters

  3. Simplify product complexity: Exclude complicated product structures like variations, kits, and components that aren’t common in our initially supported categories, and build support in later once we have confidence in the general publishing flow

An early requirements whiteboarding session

This lead to the following success metrics, set by my CTO in collaboration with the rest of the leadership team:

  • Reduce time-to-submission (i.e. when data is submitted to channel) from 20 business days to 7

  • Reduce the operations team's weekly project load from 10 to 7

  • Earn one customer testemonial

Designing the MVP Workflow

With the company in a tight financial situation as a result of the time spent on previous iterations, we needed to move through the design process quickly. I again collaborated with our CTO on developing a single vision for the product workflow.

By considering fewer options at length we may have cost ourselves in the ultimate usability of the product, but in this scenario I felt it was necessary to save the time and accept a solution that was “good enough” - if the product concept indeed turned out to be valuable to our users, I had faith that we would have enough time to iterate and optimize the UX as we went on.

The workflow we landed on mirrored the Ops team’s manual workflow but automated validation and feedback loops - which we hypothesized were the largest controllable variables impacting time-to-submission.

  1. Upload a data file and map columns via OneSchema (a third-party software we had experience using)

  2. Generate a Missing Data Request (MDR) spreadsheet which only contained columns that needed additional data or had errors

  3. Complete & re-upload the MDR to get products to 100% completion

  4. Submit the data to the selected channels

Missing Data Requests make it easy for users to quickly find the gaps in their data

Collaborative Design Review & Validation

I worked on low-fidelity mockups in a tight feedback loop with the CTO to develop a unified vision that Leadership was aligned with, before sharing the direction with the rest of the dev team. Due to our close collaboration throughout the requirements stage, there were no surprises in the UX of the lo-fi mockups which enabled us to move much faster than normal.

Note: Normally I would seek out developer feedback in the middle of the low-fidelity stage, but it was clear in this case that our developers were suffering from iteration fatigue and needed to see a coherent and well-backed vision before we would get their buy-in again.

My general design process as of October, 2025

Once the concept was stable, I:

  • Created a high fidelity prototype

  • Conducted walkthroughs with potential early adopters

  • Monitored additional feedback collected in sales calls

Key findings included that:

  • Customers were encouraged with the direction, and excited to try it out. They believed this had the potential to create valuable time-savings for them, though I didn’t believe this was verifiable until we were able to observe real-life usage

  • Larger manufacturers needed additional quality of life features before being onboarded, and needed to be removed from the early access cohort.

    For example, one customer had a catalog of 70,000 rugs and requested a feature that auto-filled values that were always the same - this was a reasonable request but not one that we would be able to fit into the scope of the MVP

Results

We launched the beta in June 2025. Despite expected bugs, early adopters were enthusiastic and agreed that the app improved their own publishing timelines.

Additionally, we met all of the success metrics that had been set for the product:

  • Reduced time-to-submission to 2.5 business days (goal exceeded)

  • Reduced Ops' Weekly Project Load to 7

  • Collected positive testimonials from 2 early adopters (goal exceeded)

The released of this feature validated CommerceBear’s product-led pivot, replacing the agency model for a subset of product categories with scalable self-serve technology.

Next Steps

Before my departure, I helped shape the roadmap and provide designs at various levels of completion for future enhancements to the Publishing feature:

  • Default Values: Auto-fill repeat attributes across products

  • AI Value Mapping: Automate data translation per channel in a predictable way

  • Support for Kits & Components: Expand to more complex catalog structures to enable additional category support

These initiatives would significantly expand the addressable market for the product and further reduce customer effort.

View Next Case Study