Adding "Resume Where You Left" to Twitter: a Product Manager Journey

I spent years carefully crafting who I follow on Twitter. Not many, just 50 or so people. But they consistently talk about things I want to read about. They have great ideas and opinion and I don’t want to miss them. It is my daily stay-up-to-date source of information.

It is so good that I don’t want to miss any. I have a mild (well…) form of FOMO (fear of missing out) for the Twitter updates in my timeline.

The problem

When I am commuting, I read Twitter on my mobile. But when I am at home, I read it on the tablet. When I open the Twitter app it shows me where I left on that device, while I would like to see where I left reading on the platform.

So now I have to scroll down the timeline, trying to get where I left. I sometimes use the tweet age to get me there. Or I try to recognize the images while I scroll. Or I try to spot a tweet I favourited already.

Now, let me put my product manager hat and try to better analyse and solve this problem.

Understanding more about the problem

I have a single data point regarding this problem: me. I need to interview other people to see if it’s something common or not.

I don’t work at Twitter (or maybe not yet 😉), so I started by talking with people I know. I soon discover as I suspected, that it is not everybody problem. Some just want to see the latest update (what Twitter is optimising for). Others, don’t use the app as frequently. Others follow everyone who follows them. Others want to be influencers in their niche. Others use it to kill time, like Instagram.

Ok, now it’s worth to understanding what is the commonality between the people that want to read all the updates. Talking with more people, online and friends of friends, I discover that in general:

• they are Twitter users from a long time
• they follow tech, startup and politics news
• they follow few people, averaging 50 user

One important thing I discover is that just half of them check Twitter on multiple devices. The other half just on their mobile phone.

Is this a problem worth solving?

This is the moment in which having access to Twitter data would be essential. With the help of the analytics and data teams, I would try to estimate how many people fit the profile previously described.

Also, does it fits the long term goals of the product and company? Are this type of users the ones Twitter wants to optimise for? Is solving this problem distracting the team from more pressing problems and important opportunities? Is solving this problem going to create a worse experience for other user groups?

Is it worth spending our mental energy, time and resources in solving this problem? Solving the right problems is the essence of being a good product manager.

Assumption time

Since I don’t work at Twitter and I don’t have enough data to make an informed decision, I will just assume that it is a big problem and it is worth solving it.

Epic creation

The first step, if I worked at Twitter, would be to describe at a high level what is the problem and what segment of our users it is affecting. It should give context to the other team members that will have to help create the solution. It will also describe what is the long term goal. Something like “Allow users to rely on Twitter as their main source of information”.

Solution ideation

It would start with leads from the design and engineering team for mobile and web products. My goal is to make them understand the problem, who it is affecting and especially why do we want to solve it. They are the ones most likely to come up with solutions which make sense for the platforms they are experts on. Designers and front-end engineers are the ones that best know and understand the Human Interface Guidelines that Apple and Google have created.

Our goal is to identify possible solutions and have a general understating of the effort it will take to create them.

I would then go to talk with users, involving designers and engineers (in rotation) to make them aware of the feedback and user point of view. This will make them more informed and they would take less personally when their ideas get rejected.

We may have to repeat this process a few times to get to a solution that is familiar and intuitive.

Product design phase

Now the design team, with users and engineering feedback can start to wireframe the selected solutions.

For the sake of this article, the chosen solution is:

A call to action that appears when I open the Twitter app allowing the user to resume where he left reading

Designers will be able to come up with different user interactions to satisfy those requirements. Still just as wireframes for now. We don’t want to invest time, at this stage, in high fidelity mockups.

Designers could propose a banner which appears asking “Resume where you left?”.

Or it could be a popup asking the same thing.

Or maybe taking inspiration from messaging apps, like WhatsApp and Telegram. When you are not watching the latest message a bubble appears with an icon directing you toward the latest message.

Having wireframes allow us to star internal discussions, test them with users and choose one that we are more confident in for the next step.

As a product manager, I am the one which has to pull the trigger, but the solution should emerge from the conversations with users and the team members involved.

Gathering final requirements

There are some scenarios which we’ve not yet considered and now it’s the time. What would happen if I don’t want to tap that resume button? Does it stay there forever? What if I open the app and I’ve already read everything? What if the user chose to use the algorithmic timeline and not the historical one? And so on…

When we have all our answers, discussed with the other team representatives from product, design, frontend apps, backend, analytics, etc. I can finalise all the requirements for this epic.

Now, I can ask the different teams to give a high-level estimation of effort required, risks involved, the unknowns and the dependencies.

It’s important to know if there is a team which depends on the work delivered by another team to be able to get started.

Visual design phase

Design team, having previously finalised the UX with wireframes, can now do the visual design.

As a product manager I have to decide if it makes sense to support this feature on all platform from day one, or maybe to start with a single platform (e.g. iOS for users with an iPhone an iPad). Taking this decision will involve discussions with stakeholders.

Few feedback rounds will allow designers to produce the final version of the visual design for the different states, scenarios and edge cases.

Development phase

In previous discussions, it will likely emerge that the backend support has to be implemented first, then the frontend apps can start their piece. It would not be effective to work on it at the same time.

So user stories for backend, iOS and QA teams are written. Each one will have the requirements and technical documentation of what data is expected to be exchanged, what scenarios are considered valid and when to raise specific errors.

In this phase, it’s important to involve QAs to have a point of view of edge cases and uncommon scenarios. Also, it will allow QAs to define the test that they would perform, either manually or with automation.

Probably it makes sense to involve briefly also the analytics and data team to understand and communicate how this feature will impact their analytics collection.

We should measure the success of this feature. The analytics team is the one which can help us to track that.

All user stories are defined. Backend APIs contracts finalised. Designs for the iOS app finalised too. Now it all goes in the teams’ respective backlogs.

Sprint planning

Backend team and iOS team will have their respective sprint planning (because I assume they use Scrum to organise their work). Depending on the priorities of the other work they have, it will get eventually added to one of their sprints.

Eventually, the backend team will deliver their piece, QA tested and approved. The iOS team will pick up their user stories in their sprint and deliver them too.

As a product manager, I will be answering questions, fill in new people with details and in general do communication between the different stakeholders and teams.

Launch and followup

It’s time to launch the feature making it part of the next release. It would first be demoed to the main stakeholders in the company to inform them about the changes and to communicate what impact it will have on their departments and goals.

It will initially only released to a small subset of the iOS user (through feature flagging, A/B testing or beta release). In a matter of a few days, we would be able to compare, using data, if the expected users are using this new feature and how.

Based on this data and how it is impacting other KPIs, we would come up with other questions and assumptions we want to test. Then, we would be able to understand if this feature has been a success or not.

But we would need to first define what success looks like for this feature. Is it increasing a specific metric like daily active users or time spent in the app? Is to increase the Net Promoter Score? Is to decrease churn?

Defined this at the epic spec stage, we are now able to understand if we are on the right path to solve this user problem, if we need to iterate based on the new data we now have or if we are off-track.

Or maybe we need to start over by talking with users.