In 2008, the Financial Times was redesigned in a supposedly Agile way – it took four years, they ended up just shipped what they had, and was not considered a resounding success. Bede McCarthy talks about the latest attempt to update the FT.com site, and how they’re getting it right. The team has hit every major milestone on or ahead of time – internal and external alphas, getting traffic on the new platform… partly by making milestones less date-specific, but also (more importantly) by taking a different approach to product development.
They know how to build a website for media – want to get to a platform to experiment on ASAP. Separate product from platform. Not against “feature teams” but, in practice, web tech moves fast, but the work required to modify editorial flows (inc. APIs etc.) are slower. Platform team owns as much of the technology (down to CDNs) as possible! If you’re asking internal / external teams to make changes, the bottlenecks add up! Business agreed to lower standard of service (not 99% uptime or 24/7 support) to enable faster turnaround. Use pilot projects to test technology AND build support.
Early-Stage Team Manifesto
Self-Organising – No assumed support roles like business analysts, project masters or tester. If the team needs them, they’ll ask for it. Product manager not defining vision, but acting as a facilitator. As little process (whiteboards, story-points, meetings) as possible.
Empowered and cross-discipline – Strong sense of ownership leads to engagement and hard work. Push the stakeholders back, and let the team be jointly responsible.
Direct access to metrics – Team builds their own dashboard as they build product (as a priority). Access to metrics allows team to BE self-organising and empowered.
Co-located – This can be challenging, but it purely boils down to high-bandwidth communication, team alignment, and forcing the team to form good working norms.
Practice continuous delivery – in many tech-first companies this is how established dogma, but in a publishing business like the FT this is quite a challenge. Critical as it allows the team to build, ship and test features within days, rather than weeks or months.
Test with real users in every cycle – This is about learning as much as possible about your customers, but it’s also about building and maintaining momentum – if you know you’re demoing to real customers who are taking time out of their day, and who hold your brand in high esteem, then you’re likely to work harder to have something to show!
How to Prototype
There are a few key factors that contribute to the team’s ability to prototype well, and prototype fast. To start with, the team have a “shipping mentality“, meaning that they prototype before investing time on design, and they prototype and test in code (bringing in design skills if there is some traction). Once the team have a prototype, they focus on real releases and real traffic – it doesn’t necessarily matter what the source of that traffic is – it could be internal, it could be a random sample of your external traffic, or it could be a specific group of beta testers. It allows you to test features, and also prevents teams from building “dirty” prototypes which then need to be rebuilt entirely for production.
Testing, Analytics & Metrics
To make sure the team have got a good handle on how the product is performing, and understand what to measure, it’s essential that they get constant contact with customers (in the case of the FT, subscribers & registered users). It’s also helpful if you can capture information at the point when someone stops using your product, which the FT team have done by getting notifications whenever someone decides to leave the beta and go back to the mainstream site.
It is crucial to identify and agree key metrics ahead of time with the stakeholders. This means that you’ll be collecting good, valuable data right from the start. More importantly, it’ll move any conversations with stakeholders away from “which features to build and ship” (which the stakeholders shouldn’t be involved in), and towards “How are we performing against our metrics?“. Stakeholders have to agree to this, and then let the product team be empowered and autonomous.
Challenges & Lessons
As powerful as this approach is, it isn’t right for everybody – some people find the constant questioning and effort to do cross-functional work to be incredibly draining. It’s also hard to scaling this kind of methodology. Although it’s not about good process, this way of building product does rely on there being a lot of clarity – not only around product vision and prioritisation, but also around who needs to be involved (and, by extension, who should not be involved) in any given piece of work.
Focus on building clarity within your team, and in your communications and visibility to the world outside your team. Work with your stakeholders to agree on ways to intelligently empower your product teams to have a rich understanding of their users, and to make decisions about how to improve the product, and to do so at speed.
