Why reviews are just like voicemails

Most marketplaces today have some kind of 5-star review system that allow you to rate the provider of that service. Whether it's an on-demand marketplace or just e-commerce, the quantity and distribution of these reviews gives people a good at-a-glance view of the quality of that item or service. Getting deeper than just a cursory star rating is much more difficult.

When considering how to build a reviews product for your marketplace, there are two important questions to consider:

  1. To what extent is your service commoditized?
  2. How will you use more detailed individual reviews to improve the marketplace?

Where the item or the service is a commodity, the value of individual reviews is limited, i.e. a simple numerical rating convey the majority of what someone needs to know. As a result, the effort invested in creating a more robust reviews system doesn't justify the value. 

However, when it comes to items where an individual's taste and preferences can vary greatly, these kinds of individual reviews can be critical. This isn't a small segment; it applies to huge categories like books, clothing and even restaurants, e.g. someone who likes reading futuristic action-packed plot-turners is far less likely to appreciate a light class-driven comedy of manners. And similarly, while an individual Uber driver's ratings may not be useful to you, they can highlight important trends to the company, e.g. the actual ETA of drivers in a region is often X% longer than the predicted value.

But as useful as this information is, it's hard to get more detailed information in a review. In the case of Uber, the review often happens right as someone is looking to use the service again so their time is limited. In many other cases, it's because the effort required to fill out a review is too high for the value that it ultimately yields for the reviewer. In a way, it's like voicemail. The person leaving voicemails finds it much easier than having to write or text or email. However, the person receiving it has to be in a place where it can be heard clearly, and needs to actively pull out the necessary information (phone number, prescription ID, order number) to truly make use of it. The reviewer wants to leave a voicemail, i.e. get their opinion out as quickly and easily as possible. The reviewee (or company) wants the details in a clean structured format so that it can be fed back into the system and acted upon.

Here are two contrasting examples from Opentable and Amazon:

In the Opentable example, the length alone is overwhelming; there are six numerical rating sections, a yes/no option and fourteen different tags to read through and choose from. This is before even getting to MULTIPLE free text responses. In contrast, Amazon limits itself to four questions with a limited set of choices that are easy to distinguish between.

I'll leave you to guess which review I completed and which review I didn't even start.

How do you build useful reviews in a marketplace that meet the needs of both reviewer and reviewee? Start thinking about how people leave voicemails.

Realistic startup roadmap planning

We're a little ways into 2016 but since I've just gotten back from my travels, it really feels like the beginning of the year to me.

Calendar time breaks like years and quarters naturally lend themselves to planning for the future. As a product person, this usually means it's roadmap time! Ideally, you're not waiting until the end or beginning of a year to sit down and then have a giant planning session with the big extended team in which you map out the entire roadmap for a year. Invariably, this results in a grand aspirational strategy which will stay in a beautiful unsullied shell for exactly one week before engineering realities, new strategic partnerships and unexpected growth (or lack thereof) intrude.

Of course, that doesn't mean that planning is useless. The last thing you want your product team to be doing is aimlessly launching bits and pieces that don't make sense in a larger context. However, it's important to understand what your planning session should focus on and what you just don't know and shouldn't try to detail out in that session.

Whether it's a product roadmap or a new company venture, here's a framework I like to use for the outputs from a single roadmap planning session:

  • what's our one focus and why?
    • e.g. validating assumption X - it's the largest need for our target audience
    • e.g. improving metric Y - it's the single biggest contributor to revenue
  • what are the one or two key metrics that we'll track?
    • e.g. engagement, new user growth, revenue
    • include the set up for how you will monitor it - query, dashboard, automated report
  • what are the high-level products for this focus?
  • what is the priority for those products?
    • based on how well related it is to focus and how much we think it will affect the relevant metrics
  • what's our timeframe to revisit the roadmap?
    • arbitrarily, two to three months feels like a good amount of time to build something that can actually show results
    • this is not a timeline for project or sprint planning

And that's it. The key thing here is that this is a single session. In short order, teams then have to take this roadmap and actually get into the guts of building out the product and features.

Ideally, the roadmap helps guide teams as they go through this process. It creates a sense of focus by acting as the magnifying glass under which we view product development in a specific timeframe. At the breakneck pace of a startup, there's always something more to be done and something new to deal with. A realistic and tightly defined set of goals can help us keep the momentum to build the most important products for the company at that specific time.

Tidbits from my daily reading diet

My parents still subscribe to the daily newspaper, so when I visit home, my morning ritual invariably involves crinkly paper and the delicious smell of newsprint. In my own home, I'm mostly digital but the start of my day is still my own cobbled together electronic newspaper. Especially in a period of enforced inactivity (thanks Doc!), I find myself reading more than ever.

For me, there are three main values: gaining perspective on the marketplaces and industries that I work in, finding great inspiration for my blog posts and also to feel more generally informed about the world in which we live. A number of people recently have asked where I like to spend my online reading time so in no defined order, here are the regulars of my daily reading diet:

Aside from the quick(ish) reads, longform articles from The Guardian, Longform.org and Brain Pickings also inspire me and end up adding to my ever growing Pocket list. I've resigned myself to always having more to read than time to read but in some ways it's comforting to know that there's never a dearth of reading material.

Too much personalization is dangerous in a marketplace

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?