Don’t be mean, be lean

Using a lean approach to build a new embeddable linking tool at Trinity Mirror has been a positive experience all round

I have read a lot of articles stating things like “the best product managers are those who know how to say no,” or “the hardest thing about being a product manager is saying no,” and, within reason, I agree. It is vital to stay focused on your product’s true mission and value, and your target users’ goals, and to keep your roadmap tightly aligned. However sometimes you have to say no to features that do keep those in mind, purely because there is a limit to how much one team of people can do at any one time.

‘Read more’ links are an example of a feature that could easily have been rejected early on. They do align with our strategy and have the potential to move our core KPIs, but we weren’t sure they would be worth prioritising ahead of other work we were already focused on. By using the lean approach, we built enough to help us to learn more. The feature ended up not only proving itself to be worth doing, but also helped to improve transparency and openness in our organisation.

The rise of mobile and the demise of the right-hand column

With the steady rise of mobile traffic and the focus on Facebook Instant Articles and Google AMP pages, the fact we were losing space to promote additional content to our readers hadn’t passed us by. While the overall experience of a lightning-fast page is undoubtedly an improvement as a reader, it does beg the question of how we can highlight other great content our users may enjoy.

How can we help users find all our content? Photo by Glen Noble

Our editorial teams already use contextual hyperlinking, often to great effect as shown by this analysis of Ann Gripper’s treatment of Hilary Benn’s speech on a vote on air strikes in Syria. But as Rob Hammond, Head of SEO, pointed out, inline links are generally context and background-based; adding texture and value to the story that you are reading. What we were missing was something within an article’s body that focused on navigation beyond that story and enabled exploration around the fringes of a topic.

Over in product and engineering we had been brainstorming ideas and discussing potential solutions, but in the meantime the editorial team simply began dropping links to related stories directly inline — see below.

Manual lateral link as used by our editorial teams

In theory this was a great solution because it was available on all platforms straight from the article body and required no development resource. The feedback from Chartbeat signalled that it was increasing recirculation and therefore was a potentially powerful tool. But as a product team, we had some fairly significant concerns.

Our design team noticed that different teams used different layouts and therefore the styles were inconsistent, and our Head of SEO felt it was the wrong approach for navigational links. Our UX designer pointed out that they were confusing for anyone using screen-reading software and we even saw worrying trends of bounce rates going up when they were used on some titles — particularly if multiple links were stacked together.

As a product manager, the thing that upset me most was that I had no visibility. I had no data. I had no way of differentiating these ‘lateral links’ from normal hyperlinks in order to compare them. Beyond an indication from Chartbeat, we had no simple and solid way of analysing what impact, positive or negative, they were having on our traffic. My instinct was we should tell the teams to stop using them, but without data it was hard to justify either discouraging the practice or prioritising an alternative product solution.

The smallest possible feature in order to learn

So before we just said no, we decided to set up a test and start collecting some data. The list of things we wanted to consider included:

1. How can we track performance to measure impact and feedback best practice advice to our editorial teams?
2. How can we ensure the links are SEO friendly and screen-reader friendly?
3. Can we speed up the editorial workflow to make it quicker and easier for editorial to add these links?
4. Can we ensure a standardised layout/design to ensure we stay on brand?
5. How can we ensure all users on all platforms continue to get a great experience?
6. What is the minimum we need to get to a position where we can measure and learn, then iterate and improve?

Based on this, an initial user story went into the product backlog and we started to refine it and discuss how it could be implemented. Provided we kept it simple, the team were confident they could get something out that would tackle all of our top priorities and allow us to begin testing and measuring within a sprint.

Thanks to previous work, our stakeholders are pretty comfortable with working in a lean fashion. Those we spoke with were immediately on board with the benefits of getting something out quickly that we could measure and improve on and were happy with the designs for our first attempt. We went with a simple line of text on a grey background — removing any requirements for handling multiple links, images and different display options. We knew we could tackle those later, once we were sure the feature was worth spending more time on.

We now had our Minimally Viable Feature.

The simple design for our first attempt at a lateral linking tool

Fast-forward a week or so and we were already rolling out a new workflow to a small subset of editors. By keeping it small, we had a great feedback loop, giving us confidence any issues would be quickly flagged. It also ensured any risk to the wider business would be reduced if the stats showed it really wasn’t working.

When we looked over the data with the editors a week later, we were quickly able to not only see total clicks driven, but also to rank all of the links by click-through rate. This allowed us to start digging into trends around the top-performing examples and use this to build a picture of what works best. Perhaps more importantly, it also allowed editors to see which examples were not bringing us any value so they could reduce the number of them in future. We were also able to play with the data to ensure it wasn’t unintentionally affecting any of our other metrics.

A positive experience from this was knowing we weren’t just throwing a new feature over the fence and forgetting about it, but really working with the editorial users to build the documentation and training guides and to continue the learning experience beyond the release of the code.

Where to next?

We are continuing to review the analytics and monitor performance. As we have some hypotheses about potential improvements, we are currently planning some A/B tests. Without a simple version on the live site we would be making those changes blindly, with no idea of whether they were actually bringing any additional value. Now we can do it with confidence.

The future of this individual feature is yet to be seen, but the benefits of adopting a lean mindset have been tangible. Delivering something fast got us access to the data we needed, built trust with our editorial stakeholders and increased team morale. The transparency from trying something out and involving people from the wider business throughout means that if the result is to say no to any further work on this feature, we are doing so based on evidence, with clear visibility as to why — not on gut feeling.