When making 100, 000 foot statements, it's useful to group a number of related things. As you start to narrow down your focus, it's necessary to break apart those same groups. For example, Europe or USA is a helpful broad construct but to have good discussions about policies in those parts of the world, you need to start talking about specific countries, states and perhaps even smaller geographical areas.
Similarly, when talking about marketplaces, we need to consider different cuts of companies that fall under this banner to understand their product principles. Last time, I proposed the on-demand v. planned model to define a mobile strategy. This time, I want to explore the idea of personalized v. commoditized marketplaces as it relates to request flows.
I'm defining a commoditized marketplace as one where the service being offered is considered the same regardless of the specific provider. While there may be different product lines to choose from, the consumer is agnostic to the person who ultimately provides the service. In contrast, a personalized marketplace is one where the consumer wants to select the specific person(s) who provide the service.
Why does this matter? When defining a request conversion flow, this division informs the product principles. In a commoditized case, we need input from a user and then the algorithm does all the work to optimize for speed, i.e. getting the service to the user as fast as possible. In a personalized case, speed is still important but we want to optimize for individual choice. Ultimately, the goal is always to get conversion to a request so we never want people stuck in analysis paralysis.
When the service is commoditized, there is a minimal amount of information required both from the user and for the user. As such, product flows here generally want to optimize for one screen and only the required information for the algorithm to process it. Then, when the request is completed and the information is relayed back, the information is again minimal - only what the user needs to take advantage of the service.
In a personalized service, there's generally more information that the user needs to see to select the appropriate provider. Product flows here will want to enable the right hierarchy of information. In selecting a provider, the ease of reading, summarized information and the option to delve deeper as needed will help to get the user to a selection. Additionally, navigation is needed between choices so that people can effectively make their way through the options. Whether it's a list, a grid or a swipe, people need simple ways to get to the next option, review a previous option and also to make their final choice. This makes the request flow of personalized marketplaces much more complex for the users and for product development. Finally, if people need to spend a lot of time thinking about the specific provider the first time, they will likely want this same provider in the future. They'll also want to protect the specific provider from being taken by other consumers. In this case, the marketplace and its matching technology becomes less useful, leading the user to transact outside of the product.
So in developing the request flow of your marketplace, it's useful to think about where your marketplace sits on the commodity and personalization spectrum. How personalized does your service really need to be? How much cognitive load do you want or need to put on the user? And how certain are you that your marketplace product continues to be the best place for the user to make the transaction?