The Art and Science of Product Management in Retail Merchandising

One of the interesting things I learned when I joined Walmart’s Apparel division was that this business alone would likely make it to the Fortune 100 list independently, and it’s just one of many such businesses within Walmart. And, to be honest, it did take me a while to wrap my head around the scale and scope of operations within the Apparel division. There are numerous tools and applications, multiple business groups, a host of processes in planning and operations, multiple technology teams and platforms, consulting teams, etc. all coming together to run this amazing division.

I joined the Apparel group to help create the long-term product strategy for Apparel assortment planning, and to build a centralized data and analytics-first, localized to the store, merchandising solution. My customers were the Apparel Merchandisers; buyers, and planners that would benefit from a seamless, integrated end-to-end approach to the Assortment Planning process. As is true with many such efforts, there were many learnings and takeaways from the get-go. Here are a few.

Takeaway 1: Everyone has an opinion on product features. Therefore, distilling data from opinions, and communicating them, is critical to success.

The challenge with many initiatives, particularly within large organizations, is that expert opinions have a habit of creeping in when product feature decisions have to be made. These experts could be technology leaders, business leaders, or others that have played a big role in getting the business to where it is today, and so it doesn’t make sense to disregard their input, but how does one navigate this? Can we, as product managers, make the process more scientific, instead of one based purely on opinions and feelings?

Key points to consider: How do we incorporate these expert opinions into your product strategy? How do we learn what the users want instead of making assumptions?

Takeaway 2: The “Art” of learning from users, ironically, depends on adopting the “Scientific Method”

In school, we’re taught that the scientific method relies on conducting experiments and obtaining reliable data in order to either prove or disprove a hypothesis. We have no shortage of opinions… Business leaders are mofd than happy to share them with you. However, we don’t have hypotheses derived from the opinions, nor defined experiments, nor do we always have the data needed.

In our case, we had to start by creating an environment where we could state the hypothesis, and then conduct experiments. And that’s exactly what we did.

Key Points to consider: What data do you need? What questions do you want to answer? What experiments do you need to conduct?

Takeaway 3: Be Lean — prototype often, quickly, collect data and measure

In order to determine what functionality and features the users needed, and to collect data in a scientific manner, we created a scrappy tool, where our customers could go in and enter the information needed to plan their assortments.

The prototype application was flexible enough to provide slightly different choices to users, and by understanding the user’s reaction to these different inputs, we got a very good sense of what worked and what didn’t. Yes, this is a lot like A/B testing prior to any real design with the goal of learning what the user wants.

Key points to consider: Do you have a hypothesis? Run your tests carefully, be aware of forces that could skew your results. Can you create a prototype quickly and validate it with real users? Will your users give you the time? Are they representative of the real group that will use the solution?

So, What was the result?

The Prototype application gave us great insights, by allowing us to validate our hypotheses by collecting relevant data in a risk free environment.

Here are some examples below of how this approach played out.

Hypothesis: Business-processes are mostly similar across merchant teams and therefore product features would be similar regardless of buying desk e.g. Men’s active wear and Women’s Plus would both follow the exact same buying and planning processes

If we believed this assumption, we would have built a solution quickly, assuming that all teams operate very similarly. However, when we built prototypes and collected real data, this was proved to be completely wrong. There was no true “One way” of assortment planning. There is a fair amount of “art” and variability here.

This insight told us that we needed more information and detail around specific process differences across buying desks, and we then became truly user-centric. Lack of this understanding could have resulted in a one-size-fits-all approach to apparel assortment (pun unintended), which could have been disastrous.

Result: Data obtained disproved the hypothesis. Product features changed to accommodate this need. +1 for the scientific method.

Hypothesis: Merchant teams generate require similar analytics and recommendations, and there is not much variability in data sources or quality of data

Conventional wisdom dictated that merchant teams needed similar data because they were all planning similar types of assortments. However, that was not always true — there was a fair amount of variability in this too. If we had not conducted the experiments that bubbled up this insight, there was a high likelihood that we would have designed features that did not take into account the unique needs of different buyers, and there would have been less adoption of the product overall. Rework would be needed, our users might have lost confidence, and we might have been on the back foot from the get-go. Simple insight looking back, but not collecting relevant data could have derailed the adoption.
Result: Data obtained disproved the hypothesis. Product features changed to accommodate this need. +1 for the scientific method.

A major outcome of the experiments we conducted was that we learnt a number of nuances about the Apparel business. Merchandising is really a combination of Art + Science; Successful Merchandisers understand this and balance this dual need extremely well.

For Product Managers to be successful, they should internalize this as well and adapt to this environment accordingly.

I just highlighted a couple of examples above of the lessons that we learned. In just a few weeks, we were able to identify more than a dozen such learnings. Altogether, my guess is we saved a couple of million dollars in rework, and more importantly, we exponentially increased the probability that we will be successful and the users will adopt the solution.

But that’s just my opinion! :)