Scarcity and the trap of the daily deadline


For the past four years I have been working in an editorial environment Metro, the third largest daily UK newspaper. Over this time I have been amazed at the number of times that serious change has been attempted and failed. This seems to be a common problem with newspapers. Initially it confused me as there are a lot of very clever, passionate and motivated individuals involved. Over time however I have come to believe that there are three main components behind this.

Having to fill a set number of pages by a daily deadline creates scarcity of time. The focus required to achieve this creates tunnel vision that both helps and hinders. It helps editorial climb their daily mountain but the bandwidth tax of doing this reduces their cognitive capacity for change. This theory formed after reading Scarcity by Sendhil Mullainathan and Eldar Shafir. The Guardian review sums up the main premise of the book well:

“Scarcity captures the mind,” explain Mullainathan and Shafir. It promotes tunnel vision, helping us focus on the crisis at hand but making us “less insightful, less forward-thinking, less controlled”. Wise long-term decisions and willpower require cognitive resources. Poverty (the book’s core example) leaves far less of those resources at our disposal.

The editorial process is driven by risk aversion, due to a lack of ability to change a printed product after the deadline. Banks of subs check and recheck work and a single person runs each section as well as an overall editor. These create multiple bottlenecks which adds significant overhead, coupled with low levels of autonomy which increases the queuing further. Most of the paper remains a work in progress until the last possible minute.

Many of the systems that enable editorial processes are very old and not built for the current world we live in. Complex to change and expensive to run, this is the final piece holding back progress. Change requires running multiple concurrent systems. Each of these is tightly coupled with other complex systems and risk aversion is high. Cost to achieve this change is very high in monetary terms, training and complexity.

Complex process coupled with complex systems and a reduced cognitive capacity for anything outside of their deadline has been holding back editorial progress for years. I believe this is one of the reasons why newer entrants without this legacy have fared so well. They don’t have any of these previous constraints. Change is possible but usually underestimated due to the multiple layers of complexity and need to continue the existing process whilst building the new one.

21 product development tips from the trenches


Over the past four years at Metro we have delivered one replatform, four redesigns, multiple native apps and built and sold an online casino. From these experiences we have iteratively built a process and environment that aids product development. An Agile mindset has helped the development team achieve a consistent output. This coupled with Lean thinking delivered growth that convinced the business to fully embrace our process. The below are 21 product development tips that were hewn in the trenches of failure we call learning.

1: Ensure everyone has a clear vision of the end goal

This needs to be concise, measurable and most importantly achievable. A strong reason behind why that goal was chosen will help motivation. Everyone should be clear on what they can do to affect the goal. This should be the main job of leadership.

2: Use small cross functional, self organising teams

Should have as much autonomy as possible in how they affect their goal. This is key to enabling faster decision making which increases learning velocity. Proximity is the best hack to maximise face to face communication. This is the most effective way to ensure a common understanding.

3: Timing is everything

The biggest challenge is building the right product/feature, at the right time, using the right technology. The biggest waste is building things that people don’t want or need now.

4: Focus on figuring out the next releasable step that takes you closer to your goal

Ensure it is small, releasable and gets you both closer to your goal and provides valuable feedback.

5: Prototypes are a great way to improve early and ongoing feedback

Paper/whiteboards are a great place to start as they allow the quickest iteration. Later prototypes are most effective when viewed in the medium they will be delivered in e.g. In browser/device.

6: Project plans should as high level as possible

They are great for making a high level view of major deliverables visible. If they constantly need updating they are too granular.

7: UX/Design should be 2-4 weeks ahead of development

Designing and building prototypes with a goal of getting as much feedback as possible before development begins.

8: What is designed and what is built are two separate things

Both should inform the other but there is no master due to constraints on both sides.

9: Just in time is the best approach to detailed planning

Any earlier can be wasteful due to risk of new data from earlier releases or prototypes. Pair up on ticket writing using face to face communication and attach any prototypes/mockups/wireframes.

10: Less is more with process once you have a mature team

An agile journey must start somewhere and a fixed process like Scrum/Kanban is a great place to begin. However as the team and process matures your aim should be to reduce this to the minimum possible for your environment.

11: Centralised communication is best done outside of email

Slack/Trello are great examples of products that allow a participatory conversation without the cognitive overload of email.

12: Evolutionary architectural approach works best, complexity shows where work is needed

The simpler you start the quicker you can get real feedback. Avoiding over architecture allows you to combat scaling issues when required, usually by following established patterns. This avoids adding unnecessary complexity early on which can seriously hamper your ability to learn fast.

13: Micro services are a great pattern for a service based architecture

The ability to pick up, modify and release a service with complete confidence that it won’t impact anything else helps you move faster. They also allow you to prototype new technologies in a production environment. Focus on automation up front to minimise overheads of running multiple services.

14: Focus

The less we build the better we build what we do. Cognitive overload of working on multiple things at a time has a huge impact on quality.

15: Limiting work in progress is the best way to speed up delivery

Queues are very ineffective, the more queues you have and the more items they contain the worse they perform.

16: Product feedback should happen on a regular basis and have all stakeholders attend

Feedback should be constructive, open and honest. As we release everyday we have two demos a week and our Slack channel is constantly open for feedback. This is where work is prioritised, discussed and tweaked.

17: Data wins arguments

It’s ok to loose a battle based on opinion to come back and win the war with data. Make sure you are measuring the right things, this takes time but is worth the investment. Then look for anomalies or what I call “data smells”. Following these to their cause will give you great insight into your product.

18: Innovation needs time and space to happen which initially needs to be forced

Hacks days/afternoons are a great way to kick start this process. Give people the a fixed time with a clear direction and see what they come up with.

19: Beware of the curse of knowledge

Don’t get frustrated, embrace the fact that some people aren’t as far along the journey as you and help them take those next steps.

20: People should have strong opinions that are weakly held

An opinion is always useful to speed up the ideation phase. Logic around environmental constraints should shape the final decision.

21: Embrace your constraints

Each environment has a unique set of constraints. Use these to aid quick decision making. This should give you time to focus on what you need to change long term to be most effective.

During my time at Metro the only constant was change. We were able to embrace this and use it to our advantage. Iterative learning based approaches helped us maintain consistent growth. Delaying every decision until we had the best data possible kept our failures small and valuable. Building great products is about forming a team around an achievable goal and iterating based on the best feedback available at each stage.

Evolution of the Metro.co.uk homepage over the past four years

This slideshow requires JavaScript.

How software ate manual content placement on Metro.co.uk

Trending and Newsfeed Automatic Placements

Trending and Newsfeed Automatic Placements


The majority of content placement on metro.co.uk is now managed by software. This has been a long journey based on real world feedback and incremental addition of complexity. My goal has always been to take a developer’s view of the editorial process and optimise where possible. Looking at the numbers it became clear that for large areas of the site a disproportionate amount of time was spent on content placement for the value it returned. My previous post covered the first part of the journey and now I will explain how we extended this to run the majority of the site.

We gather a lot of information from WordPress, Facebook, Twitter and Omniture into a MySQL database. This data is passed through a stored procedure to return five different sorts:

Score

((Tweets + Facebook Interactions) * Social Multiplier) + Views

Trending

Score Now – Score 30 Mins Ago

Social

Tweets + Facebook Interactions

Date

Date descending

Coefficient

((((Tweets + Facebook Interactions) * Social Multiplier) + Views + Editorial Boost) * Hour Coefficient) + Tag Boost

We also pass in the following to modify the results depending on the channel, e.g. news, that the data sits within.

Hours to return

e.g. From 24-336 since publishing

Filter Subcategories

e.g. Football,Oddballs,Weird,Food

Boost Tag

e.g. arsenal-fc

Social Multiplier

e.g. 10

Content Type

e.g. Blog or Post

Remove Tags

e.g. tottenham-hotspur-fc

Coefficient

e.g. 0-4 * 3, 4-12 * 1. 13-24 * 0.5, 25-48 0.3

The coefficient sort now takes input from the articles that the editors place at the top of each of the channel pages of the site. This editorial boost allowed us to keep everything feeling much fresher until the data catches up. We have also built our own real time page view tracking system with Node and Redis to get around the time lag in Omniture of 30-60 mins.

We recently centralised all of the settings so that they are easy to view and change. I focused on optimising the cluster of content returned and timeframes to retrieve within to get them working with publishing patterns per channel. The ability to cluster content of similar channels has helped ensure we offer a wider variety of content at different stages of the user’s journey.

Using different sort methods coupled with this clustering has reduced duplication. The design has also helped by using different image ratios and colours for different sections of that page that may contain the same content. We have standardised the bottom of all pages to be the same. This means if we are able to improve performance then it is felt across the entire site.

The last addition was the ability to boost by tag. This has enabled the article based algorithm to be much more relevant. At this level of granularity we decided context is much more important than freshness. Moving the tag boost outside of the coefficient enabled this to be clustered at the top but we limit this to the five most recent related articles.

Our API is able to deliver everything that the front end needs for rendering including title, image and excerpt. This has also enabled us to use this data in multiple places such as the native Tablet and Phone Editions and the glance journalism experiment Metro10 and MetroVision. Our feeds finally go through an additional layer that allow us to add sponsored content at fixed positions for traffic driving purposes.

The great part of all of this is that the maths is still very simple and can be explained to anyone who is interested. Having a set of values to tweak per channel has enabled us to have enough options to slice the data for use in multiple contexts. It has taken 12 months and a full redesign to really see this come to life but I hope it will be a part of Metro for years to come.

Home Page

Metro Homepage Placements

Metro Homepage Placements

Article Page

Metro Article Page Placement

Metro Article Page Placement

My talk at the WordPress VIP Big Media Meetup on this.

21 product guidelines forged while growing Metro.co.uk 400%

Metro Quarterly Traffic Growth

For the last two years I have been focused on the design, build and growth of Metro.co.uk utilising the WordPress VIP platform. Our approach consists of constant experimentation with both product and content which has returned a large set of data mixed with editorial feedback. This has been refined into a list of product guidelines to help us remain focused on growth. These are based on my experiences and our audience so yours may differ.

1: Good editorial content will deliver more growth than any product based approach

With a single well written/planned/timed story able to deliver millions of page views and course through the veins of social networks for weeks this should be the number one focus.

2: Good UX turns the dial more than any product hacks

The better the experience of product and content the more likely people are to visit your site, share your content and form habits around its consumption.

3: The closer to the main content area of the page the more related the content should be

Our data has shown that the closer to the article body or top of channel pages the better contextually related content perfoms. Once you are below these areas users are more open to a wider set of content to continue their journey.

4: Where content is placed on the page is almost as important as the content that is placed there

Our testing revealed content placement is almost as important as content selection (as long as it is relevant and recent). This is one of the reasons we have moved to an algorithmic approach for large areas of the site.

  • Nothing beats the value of an editorially selected contextual link within the article body
  • The area just after article delivers a lot of value as users have finished reading and can be easily tempted into something else
  • Sidebars aren’t shown on mobile and banner blindness often turns them off for desktop users so they are not an area we focus on

5: Fill dead space with content, people like to scroll it’s the natural behaviour of the web

Our newsfeed delivers over 10% of the page views of our site, this is pretty impressive considering it used to be blank space at the bottom of every article and channel page.

6: Don’t mess with the natural way that the web works

We tried and failed with this during our swipe phase. 5-7% of users delivered 20% of our page views but that didn’t increase their overall time on site. However it complicated everything we built hampering our ability to learn fast. It also didn’t quite fit into commercial or editorial strategies. This frustration/learning was what inspired the algorithm and scroll based newsfeed you now see.

7: Algorithms are great but need help from humans to perform at their best

Simple algorithms are a great way to optimise editorial workflows especially around content positioning. However these are only as good as the data behind them. Often you have to wait for this to be gathered before acting on it. Using editorial intuition is a great way to shortcut this process. Especially if you can make it run off existing priorities then process change isn’t required to participate.

8: Whatever Google/Facebook ask you to do just do it

They deliver so much of your traffic don’t question, just do what they recommend.

9: Feed the beast

Google and Facebook are always hungry for quality content. Gaining momentum requires constant feeding. They both have overall scores for domain as well as article urls so focusing on keeping this high means a better chance to gain and then maintain momentum.

10: Think of every page as a funnel, you loose users as they scroll but the lower they get the more open to their next engagement they become

The higher up the page something is placed the more people will see it. However the lower down the page someone is the more open they are to being tempted by some more content, advertising or interactions (e.g. poll vote, comments)

11: A mobile first approach is a great way to approach product prioritisation

Most of our traffic comes from mobile rather than desktop so it is logical to prioritise. This has formed a major part of our growth strategy.

12: Goals need to be concise, measurable and focus on why

The more people understand the goal and are able to affect it the more powerful it is. A goal that contains a why will always beat a goal that just contains a what.

13: Product specific performance should be broken down to actions per daily active users for comparison

This gives a much better overview of actual performance. Allows you to take out traffic fluctuations, just make sure you have enough data.

14: A week seems to be the minimum amount of data required to see if a feature has worked

Due to fluctuations in traffic and browsing habits. Also good to look at monthly and quarterly trends over longer periods as quite often they exhibit patterns that aren’t found at lower levels. It was asking questions around unexpected trends/data that helped teach me most around product growth.

15: Distribute weekly reports to show trends and give your stakeholders an overview of how the product is performing

Have these scheduled to your team and stakeholders via email. Also very useful if you break something when fixing something else. Great safety net to minimise impact and spot any unexpected growth.

16: Any new feature needs to be taken in context of how it fits in the editorial work flow. The closer it is to the existing process the more likely it will be adopted.

The best way to change a habit is build off an existing trigger. New features that leverage existing habits will get much higher adoption than building new habits/process.

17: Consider the users current journey and their emotional state in all features

Segmenting users based on mindset is a great way to understand data. e.g. Social browsers are likely on a multi site journey in a chromed browser on a mobile device. So they are only looking for a single story from your site so optimise for that. No point in worrying about pages/visit focus on getting more return visits via a social follow.

18: When coming from social users are often looking to enhance their social status

Our top share buttons get clicked on 4 times more than our bottom share buttons. Social proof around number of others already shared also promotes more sharing.

19: When coming from search users are usually in a topic based mindset

More likely to click on related, in article links and masthead channel links. Continue to deliver great content around a niche to form habits. Particularly useful around passion centres e.g. Premier League clubs.

20: It’s better to have 100 amazing tag pages that look and feel like a destination than 10,000 that feel like they were made for Google

Quality trumps quantity every time, Google knows if you users are clicking through.

21: People click on headlines 4x more than they click images

This is why A/B testing headlines is a great idea. It is the single piece of the editorial process that can have the biggest impact on growth. We also have SEO and socially optimised headlines to ensure we cater to both needs.

These are the principles that I have applied to the product development of metro.co.uk over the past two years. The key takeaway is that constant experimentation is a great way to unlock growth if your environment supports it. The hard part is achieving that without adding too much complexity. Complexity inhibits your ability to learn and learning is central to any successful product growth strategy. Building a set of guidelines has enabled us to move faster and helped foster our continued growth.

One for the future.

Micro interactions help drive habitual use

We don’t have a lot of data on this yet but there seems to be a correlation between micro interactions such as poll votes and habitual use. My theory is that by engaging different parts of the brain you become more memorable. These simple actions form the basis of new habits around content consumption. I think this is a major opportunity for future growth.

The thoughts and process behind Metro10

This slideshow requires JavaScript.

Metro 10 was born out of a desire to experiment with native mobile news reading experiences that solved a different problem to our already fully responsive website. We had an algorithm that allowed customisation and decided to use this as our data source. The concept of restricting the volume of content would help us differentiate from our infinite web experience. We also wanted our users to engage with each article fully before moving on and not just get into a state of skimming which we had seen with infinite lists online.

Our goal was to minimise the time to launch so we decided a hybrid approach would help this. Utilise the native elements for caching and navigation but a web view for the article body. As our CMS stores all of the HTML and other markup in a single blob stripping this out was too much work for the first iteration of an idea that was unproven. Our initial ideas were based on simple mobile interaction patterns. Swipe to dismiss, interaction based personalisation and full bleed images as our tablet edition had experimented successfully with this. We decided on an Android first approach as we had Java skills in house and we also wanted to iterate quickly once it had launched. The turnaround in the Play store would allow us to do this.

I hadn’t written any code in four years and getting back in the saddle was a rewarding experience. Leaning a new language and platform at the same time took a little time but the tools and ecosystem are pretty mature. Initially I got out my little black Moleskin notebook and started sketching. Putting something down on paper helped me to start to visualise flow and basic function. I am no UX designer but I find sketching a really valuable first step in any design process.

Once we had a basic idea we jumped into a rapid prototyping phase. This involved a lot of copying and pasting from Stack Overflow and some working from home to get some focus to get the bare bones of an app together. It was buggy as hell but being able to show people on a phone and see there reaction was priceless. I then involved Matt our UX designer and he started to iterate on the design. We were lucky that the concept was simple and allowed very quick iterations. The design quickly morphed from a list that looked very web based to a full bleed image that felt more mobile first.

It was at this stage I got a few more of the team involved. When rapid prototyping it was good to be solo and really iterate quickly but once we were locked on an idea we needed stability and to start on a refactoring process to move towards a proper architecture. I believe in emergent design where you don’t over architect things up front but as you learn more of the systems and domain build what is most appropriate. This can save a lot of time as you only build what is necessary and refactor once you are sure of its value.

The next phase of development to our first alpha was frustrating at times but also very rewarding. We kept the requirements process very fluid as things would change on a daily basis. This was a challenge but having written user stories which were quickly out of date and fought with automation of testing we decided keeping things simple was the best approach. Guerrilla usability testing has been key to shaping the UX. As the initial idea was pretty out there putting it in real peoples hands in the real world was priceless. We quickly learnt that people liked the limited number of stories, enjoyed the full screen design but having to dismiss every story Snapchat style wasn’t something that they felt comfortable with. The paradox of choice was blinding them. With 10 possible stories to read and only one visible at a time and only one chance to read it they couldn’t decide whether it was interesting enough.

We decided to strip the user experience back to its most basic and only give people 10 stories at at time that they can scroll through left and right. With this approach people were quickly able to grasp the concept and understand the navigation. Calling it Metro10 ensured that we kept to our goal of just the 10 most popular stories right now. Throughout this process there have been a lot of tension between what constitutes our MVP. Due to a fixed timeframe we had to make some compromises around fluidity of design. The biggest was to leave all interactions via gestures rather than fluid animations. The level of complexity rose exponentially with these.

We were able to get validation of our ideas without them. Learning if the concept works is the most important and all of the underlying data, service and business layer need to work no matter what the front end looks like. Overall it has been a great experience in taking a concept from paper to reality in less than two months. There have been lots of zigs and zags along the way but that is what makes this job interesting.

MVP

This slideshow requires JavaScript.

Later iteration

This slideshow requires JavaScript.

Responsive Design and the Mobile First Mindset

Image from: Brad Frost

Image from: Brad Frost

Responsive design was a key enabler of the strategy that enabled Metro to grow to 34m monthly uniques. It put the end user first and ensured our content looked the best it could at the time of render. We worked from the mobile screen up to the desktop and this enabled us to make quick design decisions. Key principles like this are a cornerstone of rapid project delivery.

Changing the mindset of the business to make mobile a first class citizen was a big challenge. However once they had agreed on a mobile first paradigm we were able to tackle the hard questions up front and once this allowed the development team to focus on how best to approach the responsive elements.

Image resizing was a key part of keeping our file sizes low and having a fast perceptive render. We also dropped our custom font on mobile due to render speeds. An adopted an adaptive approach that only delivered the HTML necessary for the page to render and prioritised mobile for speed reasons.

Mobile first ensured we spent our time focussing on the main content that the user had come to read. We went for the simplest option of not including the sidebar of content on mobile as it would only add page weight. The volume of clicks in this area also justified it not being included. Users have a sidebar blindness and unless it is the main navigational feature will rarely get used as the brain turns it off to focus on reading the main content area.

We are currently going through a new redesign process which will give a new lick of paint to what we achieved two years ago but the principles remain the same.

The below is a presentation delivered at the Google HTML5 Roundtable about Metro’s journey into responsive design

Ten things we learnt building the Android App Metro10

10---Metro-Android-App-UPDATED

Metro10 is the first Android App that I have been involved in from concept to release in the Google Play store. It was designed, developed, tested and deployed in the first three months of 2014. We spent the entire process learning and here are details of 10 things that we learnt as part of the process.

1 – To begin the pen is mightier than the keyboard

Starting with a paper and a pen is a great way to iterate quickly through ideas. Sketches are one of the easiest forms of communication at this stage. There lofi form means you are usually more comfortable with changing them.

2 – Keep the concept simple

We went through many stages of adding complexity to Metro10 but we always came back to the simplest implementation. With the lack of space on a mobile screen and wide audience we intended to go for this was what kept redefining our approach.

3 – Rapid Prototyping is your friend

We managed to get a version on a phone within 3 days that had our initial concept on it. This helped us put it in front of a much wider set of people very early in the process. It didn’t run off feeds, ran out memory quickly and had random image sizes but was key to getting a wider set of people giving us feedback on our concept.

4 – Guerrilla usability testing is a great way to get early feedback

As we had a prototype early I just started going up to people and giving it to them without any instructions. Watching their frustrations and listening to the questions they asked provided amazing feedback to help shape our product.

5 – Image resource management on Android is not straight forward

We probably spent close to half the time on the app stopping out of memory errors due to cropping and displaying of images. By making sure you manually clear the copy of the image that is attached to the image view we managed to fix this.

6 – Do as much processing as you can on the server

We ended up using the WordPress image resizer to resize all of our images to the specific screen size before they got to the device. This helped speed up processing and ensured we only downloaded the image size we needed.

7 – 7″ tablets are actually treated as large phones

Android treats 7″ tablets as very large phones rather than small tablets. This can mean your app needs some adjustment to look good on the larger screen.

8 – Google Play Store Alpha and Beta Communities are the best use for Google+

Google allow you to set up a community on Google+ which will give pre-release access to members. This was a great way to get feedback and manage the roll out of the app. It really made this part of the process a pleasure.

9 – Unit testing and front end automation for repeatable testing

We used both JUnit tests and front end automation to quickly get feedback on every change. We moved away from the Android unit tests due to speed issues with the emulator. We managed to integrate those and the front end framework with our CI environment though the management of emulators again provided some interesting challenges.

10 – There is no substitute for using real devices in testing

Emulators provided a great way for us to get started quickly but using a mouse to control features proved tricky. We also saw different behaviour on emulators and real devices over the time period.

The best way to learn something is by doing it, by starting with a set of constraints and a focus on simplicity and I am very happy with the results we got with Metro10. We have now passed 500 downloads, are maintaining over 100 daily active users and still have over a four star rating.