One problem does not always mean one product

I initially considered combining three related sourcing workflows into one product.

On the surface, they looked similar:

Find a product.
Organize the information.
Prepare it for sale.

But the more closely I mapped the workflows, the more different they became.

One workflow focuses on preparing products from 1688 for Coupang and Naver Smart Store.

Another deals with multiple Chinese sourcing platforms, where access methods, product data, and failure patterns are different.

The third explores safety checks before a seller moves toward an actual listing.

Each workflow has different:

• platform constraints
• data requirements
• error conditions
• policy risks
• approval boundaries

Combining them would make the product look larger.

But it would also make responsibility less clear.

In ecommerce operations, automating the wrong step does not simply produce an inconvenient result.

It can create incorrect listings, duplicated products, policy violations, or account risk.

So I decided to separate the product boundaries while keeping the underlying logic connected.

Two workflows are now functional MVPs under validation.

The third remains a concept and validation scope until its safety boundaries are clear enough.

This reminded me that product architecture is not only about grouping similar features.

Sometimes, good architecture means knowing what should not be combined.

When do you decide that related workflows belong in separate products rather than one larger platform?

#ProductArchitecture #EcommerceOperations #SystemsThinking