Stuck users

Getting user experience design right is all about getting user flows right.

The first question when it comes to optimizing flows is asking – how would a user make it from one end of the process to the other? This is important because every added step or inconsistency results in drop offs.

An oft-overlooked second question is – where do users get stuck? Or, put differently – where are user dead ends?

User dead ends typically happen due to two reasons –

  1. No “escape” button
  2. Poor error notifications

No “escape” Button

The early version of Windows got the “escape” button idea right. If you weren’t used to computers, you had a way out of whatever hole you had dug yourself into. Apple did this well in their first decade with the iPhone. You were never stuck on an iPhone because the button always offered you a way out.

The lack of an escape button is all too common in customer service processes. For example, I keep getting stuck at this screen when trying to get to the results of a case dispute I filed with Equifax. The only escape here is “Please try again later” because there is no easy link to contact them directly.

Poor error notifications

The first iterations of Windows were legendary for poor error notifications. An error on Windows might say something like – “X000snjksfn9843940 – Bad command.”

Of course, this meant nothing to a user. Luckily, Google searches and forums helped solve these problems. But, if you weren’t internet search literate back then, you were in trouble.

I experienced a version of this issue today thanks to our HP Laserjet printer. It is cliche to say you are troubleshooting printer issues at your parents’ place. But, that is exactly what I was doing. The error, it turned out, was, well, “Error – Printing.”

That’s helpful.

We solved the issue by unplugging and re-plugging the printer. While it amazing how many problems that solves, an error notification that says nothing is a recipe for stuck users.

Product Leadership vs Product Management

This is a series of posts that is a synthesis of ideas from 4 sources – Marty Cagan’s workshop on Product Management, Product Leadership (the book), conversations I’ve had with experienced product managers and my own observations. I’d like to explore what building products is all about, the various folks and forces at play and tools and ideas that might help get the job done better.

Product Leadership and Product Management: Product leadership isn’t just about leading a team of product managers. Instead, every technology product manager has 2 aspects to their job – product management and product leadership. This is analogous to the management and leadership of a business. While often discussed in the same breath, they are very different. Leadership is about doing the right things or effectiveness while management is about doing things right or efficiency. Similarly –

  • Product leadership is the time spent on deciding which products to build to add value to customers. The challenges here revolve around “customer/user discovery” or finding “product-market fit.”
  • Product management is running the process of building products as efficiently as possible.  The challenge here is generally around optimizing funnels.

Folks in smaller organizations tend to spend most of the their time wrestling with product-market fit. Thus, smaller organizations requires product managers who are comfortable wearing the product leadership hat. In larger organizations, senior product leaders or product managers leading “venture bets” tend to spend more time wearing the leadership hat.

In summary, wearing the product leader hat involves spending time wrestling with questions around product-market fit while wearing the product manager hat involves spending time wrestling with optimizing funnels. 

Leading a product: A successful product is one that is valuable, usable and feasible.

When you are deciding whether to build a product, you work within these constraints by thinking of the market, the customer and the/your company. This process requires the product leader to go through a process of customer discovery (in lean start up parlance) to ensure she is building a product that has hope of finding product-market fit. Or, put differently, the product leader tries to find a customer to validate her hypothesis that her product solves a real need and is, thus, valuable. Once the value is ascertained, she can begin scoping a product that is usable and feasible.

This is best visualized when you think of the primary tool a product leader uses. For the product leader, a product strategy document is a great tool to align people around the vision. A good product strategy document includes the following –

  • Problem Statement/vision: Describe the problem we’re trying to solve and, in the process, paint the picture for what we’re trying to achieve.
  • Principles: Clear guardrails that help us make decisions.
  • Strategy/Hypothesis: Answer the questions – “where do we play?” and “how do we win?”
  • Vision Roadmap: Outline what we’ll need to build in the coming quarters/years to solve the problem.

Of course, visionary product leaders don’t just write a great product strategy document and leave it at that. But, building a compelling vision with clear product principles and a strategy are the first step. We’ll cover the rest in later posts.

Managing the product: Once you agree on what to build, you put on your product manager hat to lead the process of building the product. In doing so, you take responsibility to balance the perspectives of the business (value), design (usability) and engineering (feasibility).

The primary tool product managers use is a product roadmap in some form. Again, we’ll cover roadmaps in detail at a later time.

The 3 axes of value, usability and feasibility are very useful as you think of skills product managers tend to build. A model (that builds on this and that) I’ve found helpful is that of “explorer, scientist, driver.”

  • Explorer PMs lead with design thinking. They are very curious about users and the market and build instincts for what matters to users and what doesn’t.
  • Scientist PMs lead with analytical/engineering expertise. They know their funnels and dig deep into their data to find insights and product improvements.
  • Driver PMs lead with business acumen. They’re great at moving the organization to build products that their customers are ready to buy and understand what it takes to go-to-market with them.

This model brings forth a couple of interesting insights. First, I’ve noticed that great product folk tend to have 2 of these 3 traits and learn to build teams that balance their weaknesses.

Second, different types of products tend to require different expertise. For example, B2C products tend to require more of an emphasis on usability and feasibility while B2B products tend to place more of an emphasis on value and feasibility over usability. My hypothesis is that this means PMs who prefer the explorer hat work better on consumer products while PMs who prefer the driver hat work better on business products. This also points to what folks need to do to learn complementary skills. If you want to build your explorer/design skillset, work on consumer products. And, if you want to work on building out your business acument, work on a B2B product.

Finally, the ability to lead with analytical insight is increasingly becoming table stakes.

A question for reflection, then – how much time do you spend wearing the management and leadership hats in your jobs? Does the ratio feel right to you?

Building reputation and incentives into marketplace products | Thinking Product

This is a “Thinking Product” post where I have more outstanding notes questions than concrete thoughts or a framework. I haven’t given the subject of reputation in marketplaces much thought. But, I thought about reputation this week as I took four Uber rides during a day of travel.

The driver side of the marketplace. I read an interesting post today titled “Give me my reputation back” in which Gavin Kelly lays out a case for portability of reputations. He writes –

The popular image of this segment of our economy is of free-wheeling, hyper-flexible freelancers who come and go as they please. Gig-workers can, after all, work through whichever platform they wish, for as long as they wish. The free-market distilled. 

Yet this is a partial account. It overlooks a barrier to mobility: the non-portability of their customer ratings and reviews. This is no side-show. You can’t, as Henry Ford said, “build a reputation on what you are going to do.” Ratings crystallise hard-won reputations; they are the passport to future earning power. Lose them and, regardless of experience or prior standing, you are pretty much starting from scratch.

This state of affairs is all the more odd given that, to avoid being treated as legal employers, platform-companies like Uber present themselves as mere online notice boards used by independent businesses to pick up trade. Strange, then, that these businesses can’t move these reviews with them.

I think this is a valid thought and one that is similar to the argument that we ought to be able to take our data on centralized platforms and move it. I don’t expect the gig economy companies to take action. But, our regulators need to pay more attention.

The rider side of the marketplace. Uber has been more upfront about the rider rating (i.e. the average rating you receive from drivers) and you now see it the moment you touch the options menu. I had a few thoughts here and questions here –

  • Rating manipulation: Uber says it doesn’t reflect individual changes to ratings, for example. But, it is pretty easy to tell. For example, I received three 5 star ratings and one 1 star rating on Wednesday. It was easy to tell because I saw an immediate change in my rating and the last change involved a large fall from 4.74 to 4.64. So, is it possible to manipulate your own rider rating? Here’s an example – what if I gave a 5 star rating and a generous tip to the driver right after I finish the ride? Wouldn’t the driver know immediately and reciprocate? Similarly, what if I “got back” at the driver who rated me one star by giving him a one star rating? Could Uber update ratings after a 24 hour period instead? (I did neither – but am curious)
  • Feedback for a one star rating: I was really curious about the reason for my one star ride. I was waiting for the driver, greeted him, stayed quiet until he needed directions within our apartment boundaries and got off. I wondered if the rating was a mistake and asked Uber support if there was a reason for this. But, Uber support just gave me a list of generic tips. What if the rating system persuaded both riders and drivers to give at least a line of feedback if they gave an extreme rating – e.g. one or two stars?
  • Introvert bias?: I would be really curious for studies on the correlation between introversion and Uber rider ratings. If I’m taking an Uber after a work event or a social occasion, the last thing I want to do is have a conversation with my Uber driver. But, an extrovert would be have differently and my hypothesis would be that extroverts have higher Uber ratings, on average.
  • Kids bias?: Another bias I’m more certain of is that against parents traveling with young kids – especially if the driver isn’t a parent himself/herself. How do you correct for such biases in these rating systems? Do you bother?

As we move toward a world with more marketplaces enabled by mobile phones, I wonder what the consequences of such rating and reputation systems will be. I’ve heard great things about an episode of Black Mirror where everyone is obsessed with their overall rating. What happens in a world where we feel constantly watched and judged?

While I was curious about ratings and reputations in marketplaces during my Uber day, I definitely felt judged when I got my one star rating. For some reason, I’ve had issues with the Lyft app on my phone over the past few months. But, the one star rating with no explanation pushed me to uninstall and reinstall the app so I could use Lyft next time.

I’ll be back with more notes and questions after using Lyft on my next travel day in the coming months. :-)

Sending audios and optimizing flows | Thinking Product

I wanted to send a friend an audio message on iOS. The flow started straight forward. First, I pressed the mic button on the side of the message.

Next, I record the message.

I liked the user experience (Ux) here as it clearly separates finishing an audio, playing it and sending it. Whatsapp, for example, auto sends an audio message the moment you take your finger off. So, I can see the benefits of adding an extra step. But, however, I ran into an issue. The phone reminded me that I was low on battery (20%) and it just stopped the recording abruptly. I just lost a 5 minute audio message.

So, I recorded this again and sent it.

I realized then that I wanted to add an extra message. So, as I worked through the second message (2 minutes), I noticed that the first message had disappeared.

What the hell was going on?

So, I recorded the first message all over again. That’s when I noticed a small option to”Keep” in blue.

It turns out that the blue “Keep” is a button. And, if you don’t click it within 2 minutes, the audio message will disappear.

This can be changed in your settings. But, for some reason, this is the default experience. And, it extends to the receiver of the message as well. This friend explained that she was thoroughly confused when the memo just disappeared. As the memo included some notes that required a repeat listen, this led to a few issues at her end too.

So, what can we learn from this? The first lesson is the obvious one- we have to be thoughtful about the defaults we use. Smart defaults are critical to help users along the way. It is tiring if a user has to make every little decision and check every checkbox. But, in this case, for some reason, the product and design team decided that audio memos need to be removed by default. It is a decision that has likely caused a lot of confusion among users. And, the keep button doesn’t help matters much.

Second, and most importantly, optimizing flows is at the center of great Ux design. 

Many equate design with pretty appearances. But, users use products to get a job done – not to admire how the beauty of the product. And, when they get their job done, they win. To win, users need to flow from one action to the next.

And, great Ux design is all about optimizing these flows.

Connecting aspects of great products and great product strategy | Thinking Product

I started the Thinking Product series by sharing my hypotheses for the 3 core aspects of great technology products and great product strategy.

This evolving theory, like all theories, is necessarily imperfect. There’s a ton of nuance that goes into building technology products – e.g., products for enterprises and consumers are designed very differently. But, theories are important because they end up simplifying things. And, that’s particularly important as we begin exploring a new topic. I started this series with this image.

And, over the past weeks, we’ve explored each of these pieces. We began with aspects of great products.

  1. Nail job to be done
  2. Well designed
  3. Sticky

Then, we looked at great product strategy.

  1. Growth – i.e. bringing new users
  2. Onboarding – i.e. converting them to power users
  3. Retention – i.e. making them stay (with a note about the dark side of engagement)

For each of these, we explored 1-3 key questions that should help drive our thinking.

So, today, I wanted to bring this all back in an overview image of sorts. There’s a strong parallel between the core aspects of great products and great product strategy. That is by design of course – they exist together and feed into each other. So, when we look at them together, we arrive at the following 3 core principles –

  1. Find a niche segment of users with a problem and focus on solving it. (Nailing job-to-be-done and growth)
  2. Use the onboarding period to convert new users to power users. (Delight to use and Onboarding)
  3. Continuously improve ability to surface and drive value. (Stickiness and retention)

We have many exciting topics to explore as we dig into the nuance. But, these will likely serve as the building blocks through our journey.

For the next few posts, we will take a break from products and product strategy and move to discussing my hypothesis for the building blocks of great product management and product leadership.

 

Retention – feat the tragedy of the commons | Thinking Product

There are two questions to ask when we think of retaining users  –

  1. Are we continuing to drive value for our users via continuous improvement or better surfacing of value?
  2. Are we reminding users of the value they can drive?

Both these questions are important but drive contrasting approaches. The first question focuses on improvements within the product while the second is essentially a notifications/reminders driven strategy.

1. Are we continuing to drive value for our users via continuous improvement or better surfacing of value? 

As mentioned above, there are two ways we drive value here. First, we keep making improvements within the product. For most enterprise products, this continual part of the roadmap is typically driven by customer feedback. For consumer products, it is generally driven by rapid experimentation and copying successful features from other consumer products. And, while consumer product management is arguably more gut driven than enterprise product management, great consumer products are often molded by their users. A seminal example of this is the story behind Twitter’s hashtag.

The first hashtag appeared thanks to Chris Messina, a user who suggested using # for groups. Interestingly, he got inspiration for this from another social network (perfect illustration of my point above) – Jaiku- and from tags on Flickr. In time, Messina’s idea spread and Twitter, after a period of resisting it, came around to it.

Second, most products generally do a poor job surfacing value to users. That’s because our assumptions about the most valuable aspects of our products are rarely what our users value. This is where analysis of usage data goes a long way in improving the product.

Overall, however, this question is all about continuously improving our products to drive value for our users and is the surest proxy for long term product success.

2. Are we reminding users of the value they can drive?

Any savvy mobile product manager today has a sophisticated notifications strategy. She has a point of view on when to surface a push notification versus a badge and when to use email to drive users back to the product. This isn’t limited to small companies trying to get traction. We see the largest companies use notifications a fair bit to drive usage as well. For example, Facebook gets very aggressive with email notifications if you don’t visit your profile or feed. I use Facebook primarily for my blog’s Facebook page. But, that engagement clearly doesn’t count for Facebook – so, I receive an email reminding me of what’s going on on Facebook every day.

Twitter, recently, shifted its notification strategy pretty drastically as well. This was what a notification email from Twitter looked like until the first week of July.

And, this is what happened once they shifted strategy.

Now, I have to click on “Take a look,” head to Twitter to see what happened. Twitter has been having difficulties with user growth and this is clearly a metric mover. The big question with such changes, of course, is whether it will continue to be a metric mover in the long run.

Notifications are important. When done right, they are good reminders of the value a product can drive for the user. However, too often, they are used as short term metric movers that only end up annoying users. The problem with notifications is classic “tragedy of the commons.” If a company has 5 teams who all want to drive up their numbers, how long before they all surface frequent notifications and compel the user to turn off notifications?

The bottom line – a retention strategy that is driven by notifications is a poor retention strategy. I think retention strategies work best when 80% of the effort goes into driving real value and the remaining 20% (and not any more) focuses on reminding users via notifications.

If our users aren’t listening to our many reminders of how great we are, maybe we ought to revisit our assumptions.

The dark side of engagement | Thinking Product

Today’s post, on retention, was supposed to be the final one in the “building blocks” series where we bring together the various aspects of great technology products and the questions that can guide our thinking through this process.

But, before I spent time on retention, I thought I’d take a detour and share a few notes on the dark side of engagement from the author of a book on the subject, Nir Eyal. Nir Eyal had a thought provoking post on this in which he called out the dark side of aiming for engagement – unfortunately, making things more engaging also makes them more potentially addictive. 

We’ve all experienced this with some of our favorite technology products. They are engaging to the point where we can’t really access them without experiencing that daily hit. His suggestion is to build in safeguards within our products. Here are a few examples –

For example, instead of auto-starting the next episode on Netflix or Amazon Video, the binge-inducing video streaming services could ask users if they’d like to limit the number of hours they watch in a given weekend.

Online games could offer players who cancel their accounts the option of blacklisting their credit cards to prevent future relapses.

Facebook could let users turn off their newsfeeds during certain times of the day.

And rather than making it so fiendishly difficult to figure out how to turn off notifications from particularly addictive apps, Apple and Android could proactively ask certain users if they’d like to turn off or limit these triggers.

We saw real life examples of these issues recently when a 13 year old in China jumped off a building after being denied access to the very addictive “Honor of Kings” game by Tencent. Then, a 17 year old nearly died of cerebral infraction after 40 hours of continuous playing. So, Tencent responded with time limits for anyone upto 18 years of age. Of course, one would hope that companies won’t wait for a tragedy before creating such safeguards.

These examples aside, there have been studies on the negative effects of social networks on teenagers’ self worth and body image. And, we’ve all likely experienced meals where we wished there was a sign like this.

Nir Eyal concludes his post with this –

Of course, tech companies won’t be able to “cure” addictions, nor should they attempt to do so. Nor should they act paternalistically, turning off access after arbitrarily determining that a user has had enough. Rather, tech companies owe it to their users simply to reach out and ask if they can be helpful, just as a concerned friend might do. If the user indicates they need assistance cutting back, the company should offer a helping hand.

With the data these companies collect, identifying and reaching out to potential addicts is a relatively easy step. A harder one, it seems, is caring enough to do the right thing.

For anyone part of a team or company that’s involved in building technology products, this responsibility to care is on us.