This might sound obvious, but it's harder than you'd think. And you will probably not realize until you're a few months into your project.

How you structure your catalog will define how your editors work with the site, and often the navigational structure for your customers. Doing major changes to this structure after years in production is likely to be a nightmare, so you may as well do a good job up front. Things to consider are:

Types of products

Do you have a lot of different types of products? For instance, a pair of pants is very different from a plant or a chair. Consider the different properties they have, and all the different things you as a customer might look for when buying the items. Interview people if you can, this might just give you necessary insight. Not everything is obvious. The different concepts you find here should be reflected in your code as different classes inheriting from VariationContent or ProductContent. Just like page types, really.

Understanding sellable units

Understand the concept of the variant - the Stock Keeping Unit, or SKU for short. This is the sellable unit. If your item has different colors or different sizes, each unique combination will be a separate SKU. If they share a lot of information, you should consider grouping them under a Product. However, this might not always be necessary, and you can have a webshop with no use of the ProductContent class. You never sell products, you sell SKUs.

Check out EPiServer's own webhelp for a description of the different types of catalog nodes

Catalog structure

Will your products or variants (or catalog entries) appear in multiple categories? This will affect how you structure your navigation, search engine indexing or how you look up products later. Take this into account when creating the basic structure.

Don't create a complex, deep structure if the client's editors aren't experienced enough to work with that. If the people managing the products can't do their job, your project has failed from the get-go. In the real world, people managing electronics will probably tolerate a fancier structure than someone managing antique furniture. Consider this, and do let this affect your initial estimates. You might have to work around things in code as a replacement.

Involve your customer

Your best source of product information will be your customer. Work with them. Involve them. Let them be part of the project. Do not isolate yourself away from them. No matter what you as a team think of yourself, you have no idea about how they run their business if you haven't worked with them for a while. This is crucial.

If you need info about a product to assemble it's back end business logic, ask your customer. Don't guess. It's far better to look like a dork at first, but getting it right, than to look super awesome and get it wrong. Find errors early this way, or preferably avoid them altogether.

This blog post is part of the series EPiServer Commerce project essentials which will give you a few tips on how to plan your projects.