One thing I want to emphasize is what you're seeing in this artifact is the final version of this document. I view this as a tool for discussion that evolves significantly over its life cycle.

I usually have a line above the question "What should we build?" that says "do not touch this until you filled out the first section" because the worst thing you could do as a product manager is show up to the meeting having already spec'd out what we should build because that completely obliterates the need for cross functional collaboration to actually come up with something to build together. Your job as a PM is actually to define the problem and convene the team, not to say how we should solve it.

Looking back at this doc now, I definitely could have condensed the background section. However, this particular project had a lot of history and we wanted to give that historical context. You can see in the third paragraph it goes into the details of how we tried to solve it with this other project.

In this case, we did want to give that historical context to someone before they came in and were like, "Well, why haven't you tried to solve it in this way?"

Project Clementine was an effort to clarify login flows that had been built early in the product's history and hadn't been improved in a long time. Medium users sometimes had many accounts - for example, if you had an account with one email address, and someone sends you an article to a different email address and you click on it, then sign up again, and now you have two accounts... . There were so many different entry points into the product where you could conceivably create another account.

Then you have to add in the context that we now have paying memberships, whereas before Medium was an entirely free product. If you had three different free accounts it was like yeah, sure, it would be a little annoying but it wasn't a huge issue. But if someone's paying for something on their one account, and they try to log in with a different account and can't view the article, that is a big pain point. Once we introduced this element of paying memberships, it just became more and more critical that we actually solve the multiple login issue.

In past efforts to tackle multiple logins, I think honestly, we hadn't made a concerted effort to sit down and bring a high degree of clarity to the exact nature of the problem.

What I like about this product brief is that when we describe the problems we're solving, we're both very specific and very clear. Then we go through and say, "Okay, this is how we're addressing each of these problems." I think we just hadn't dedicated enough energy or thought to tackling these problems in a systemic way before.

We don't have a separate spec so this gets pretty granular in the details, but again, I don't want to give the false impression that this doc in its first version was fully formed like this.

This project was actually super successful. Just having the copy that said, "Hey, we think you have a different account," just that small amount of prompting really helped people. We were able to recognize them and identify that this might be an issue for them.

We saw a good reduction in the number of users who were complaining about this issue. Our number one success metric was tickets decreasing, and we actually did see tickets decrease as a result.

Looking back on this doc, in this case, it looks like we didn't end up circling back and saying what was the preliminary estimated level of effort. However, I think that is a good thing to include to make sure you're getting a gut check early on about roughly how much time this feature would take to build. Ideally in the quarterly planning process, there should have been a preliminary level of effort that was super high-level, like a low, medium, high, very hand-wavy estimate. Ideally you always have that level of effort estimate and then you just keep refining it as you talk more with the team and get more granular about what you're building.

Caitlin Roman

I wrote this product proposal to help the team at Medium tackle the thorny issue of multiple logins.

Improving clarity in our login flows - product proposal

Medium has a multiple account problem. If you haven’t personally experienced it, then you probably know someone who has - you have accidentally created a new account without meaning to, and are left with multiple Medium accounts and confusion around which account is which.

While this has been a problem for as long as Medium has been in existence (or so I am told), it has become more and more of a concern with the introduction of Medium membership and our rapid member growth. Now, we have paying members who unintentionally create other accounts, and cannot access stories when logged in to those accounts - and think their membership is “broken”. We have had more than 1,000 such tickets from members over the last 4 months - this issue impacts an unacceptably high percentage of our member base, especially given how negative an experience it is to feel like you cannot access the value you paid for.

It is worth noting that we tried to solve this problem to some degree in Fall 2017 with Project 

. This project split out sign up and sign in as distinct screens, and also introduced error messaging when users tried to sign up with an existing account, or sign in with a new email address (error cases highlighted in yellow on this [sheet redacted]). However, we saw significant login rate dropoff (as documented in this 3-part investigation [link redacted]), and decided to roll back the error messaging part of the new login experience in order to mitigate the drop. It was unclear whether the error messaging was, in fact, reducing multiple accounts, and the login drop was deemed unacceptable at the time. Of course, we might make a different decision about the tradeoff now!

As we continue building our membership business, we need to get this multiple accounts problem under control, or we risk increasing negative sentiment and confusion among our paying users.

We can introduce changes to the login flow that reduce the incidence of multiple accounts. Some of these changes may reduce our login rate somewhat, but we believe the impact will not be significant in terms of activated users.

Members who are not logged into their member account cannot access stories on Medium and feel they aren’t getting value from their membership.

 There are two primary scenarios where this can occur:

Members access content while logged out and see the paywall.

 First of all, these members are frustrated by not being able to see the content they paid for and getting a generic message. And second, these members may not remember which sign in method they used, and can therefore unintentionally create a second account that does not allow them to view the content (i.e., they are at an elevated risk of creating a duplicate account).

Members get logged in to a non-member account, do not understand that they created a different account, and are confused by the paywall messaging.

 This is an extension of the problem above - if a member actually creates or logs in to the non-member account, they will see the paywall and may not understand why they cannot access the content.

Users who already have an account accidentally create a new account.

 Again, there are two primary scenarios in which this can occur:

They forgot they had an account, and create a new account with a different sign up method.

 We don’t leverage any signals to suggest whether someone trying to create an account may already have another account - currently, if someone clicks “create account” with an account method we don’t already have in our system, we’ll go ahead and create that account.

They try to sign in but don’t remember how they created it, so they select a different sign in method, and we create a new account.

 We currently make it very easy to create a new account even if the user is trying to sign in. If a user selects “sign in with Facebook”, for example, and we do not recognize that account, we simply create a new account, without alerting the user that a new account is being created. In that scenario, the user might have thought they had an account with Facebook, but they actually had previously signed in with gmail - with a different email address than associated with the Facebook account. (Solving this problem was an original part of the Clementine flow).

Members who accidentally create or log into an account that does not have a paid membership attached to it

Users who create additional accounts without intending to

The Medium User Happiness team, which deals with hundreds of these tickets every month.

Ticket volume on this issue is high and only increasing in velocity. The User Happiness team is now on their 6th iteration of this [ticket] since June; a ticket can only have 200 comments before it maxes out. It is a major contributor to negative sentiment around membership. We believe that solving this problem sooner rather than later is critical for the continued growth of our membership business.

Tickets from members with issues related to multiple accounts decreases.

 We are increasing our member base, so we would expect this number to go up naturally. Therefore, holding the number constant would be a win; decreasing it would be an even bigger win.

Retained users do not drop beyond an acceptable level. It’s hard to define this out the gate, but we will assess each experiment and understand its impact before moving forward.

Passwords! For this first iteration, we are taking passwords - which are a massive investment, both in terms of building the new system and migrating existing accounts - off the table. Let’s see if we can solve this problem to a reasonable degree without adding passwords. That’s not to say we won’t add them later on - just not in this go-round.

Another bigger idea is adding SMS as a method to sign in (i.e., get a text with a link to sign in OR 6-digit code instead of a magic link via email).

Add “sign up with email” as a link to the Sign Up screen (ticket)

Make “Already have an account? Sign in” bigger on the Sign Up screen (ticket)

Tell visitors who we suspect are users to log in

For all logged out users - members and non-members

Different copy for suggested account: members vs non-members

Preference social sign in where we have a token in the following order:

If no social sign in token - show email sign in

“Not you? Sign in or create an account” or “See all login options” link

Fire a tracking event (see tracking spec in Google doc)

Capture the signal in local storage when this link is clicked → do not recommend that User ID again within that browser

“See all login options” links to Sign Up SUSI modal

Show on all surfaces where we prompt login, when we have token:

Login prompt (post_free) / logged out meter modal / SUSI prompt

Leverage signals for when to show this flow:

P0: Referrer = Medium email (e.g., Digest, Pub Digest, Intercom)

Tell non-member users who we suspect are members to switch to the member account

For non-member logged in users where we have signal that they actually have a member account

New endpoint that signs out and then signs in in one step

When switching account, do not log the user out of the first account until we successfully log them in to the suggested account (or other). I.e., if they click social sign in but do not complete, do not log them out.

Transition to “normal” meter/paywall.

Dismisses the “switch” version of the meter

For paywall, swap out copy and CTA. No UI switch

Show on post and other surfaces where we prompt upgrade:

P0: Referrer = Medium email sent to a member (e.g., Digest, Pub Digest, Intercom)

Add friction for people signing in with a new method i.e. make it more difficult for them to unintentionally create a new account

IF the email address (via any sign in method) is not already in our system, then temporarily block the user from creating a new account

Show the social button that they had previously clicked

Ask them to enter another email address to sign in

Link to other sign in options AND to create a new account

Product Proposal—Addressing Multiple Logins at Medium

Improving clarity in our login flows - product proposal

October 2019

Background / intro

Sign up to see more