As I get more rigorous with my product development approach and philosophy, I was introduced to the idea of ”personas”. Fundamentally, it is the creation of a highly detailed (with detailed being the keyword here) individual who might be one of the consumer of your product. When you create a persona, it is highly recommended that you name them -  to assign a distinct personality to them.

A persona cannot be created from thin air - primarily because your intended persona for your product may not be your actual persona. In an ecommerce context, personas need to be created by understanding the merchandisers (or the category managers), the product management/UI team, the engineers and lastly the customer service reps. It is easy to see how the merchandisers would give an idea of the most wishful persona and the CS gives us the most real persona.

One of the reasons of Amazon’s success is that they adopted a pervasive, customer-service centric model of running the company pretty early - which meant that everyone, from the engineer to the CEO, was doing customer service. This meant that the broad spread of personas gets narrowed down. If there is indeed a missing persona, you need to create it explicitly and steer the entire organization towards it.

When you create personas, especially in ecommerce, you need to create both positive and negative personas. You might want to correlate your negative personas to low customer lifetime value (LTV), but I’m not sure whether that is always right. Additionally, re-creation of personas need to be an ongoing practice and in case of online retail, need to driven by specific campaigns (is your regular customer  persona and Diwali customer persona the same?)

Personas need to be created by each individual functional group (customer service, product management, etc.) and then (atleast attempt to be ) merged together. There is a very interesting behavior which occurs when all individual personas are brought together. You sort of figure out that each functional group was actually addressing a different persona. Personally, I have seen this happen very frequently between customer service and merchandising teams - when the personas are finally brought before them, they realize ”hey, I wasnt even talking to that customer”. In several cases, feature requests for a particular functional group in the company usually mapped to the persona they were servicing and lack of homogeneity between many of them led to long feature backlogs. Once you sort of agree on your primary, secondary, dont care and negative personas, you can prune your feature backlogs to be much more effective.

As part of product development, it then becomes essential to map a feature request to a persona. In case of Tradus, we have both seller as well customer personas - features for one may not make sense for the other. From the perspective of the project manager, you can either prefer to  maintain multiple backlogs (which is seriously anally retentive) or basically fight it out gladiator style and re-prioritize features depending on specific personas (my preference).

Either ways, having personas as a drop down in your bug-tracker is a big step towards a true agile direction for an ecommerce shop.