Step away from the brand: Beginning a journey into feature-set product management
Product life has been changing here at Immediate Media. Over the last few years, and with some rapid acceleration of the process during 2016, we’ve moved away from a brand-led development strategy and into focusing on cross-brand features and services. This is a logical step as it ties in with our new platform development, but it raises some interesting issues when it comes to the relationships between the product team and the wider brand teams.
In a situation that may well be familiar to many, the PMs were previously within brand-led silos. They had development teams alongside them with a varying amount of resource, and existed primarily to drive the brands’ delivery of their specific roadmaps. This led to some fantastic innovation and tangible results, but nothing that could be replicated; other brands looked on from afar at a new feature, but would have to build it again if they wanted to deploy it on their site[s]. A particularly memorable example was three separate development teams all working on gallery functionality: we ended up with some lovely galleries, but at what cost?
Over the course of 2016 we have reorganised the product & technology teams as part of our focus on platform development. The scrum teams are now based around features and services rather than specific brands, in the same way as many other technology and publishing companies. The benefits are clear: developing reusable components rather than duplicating effort, ability to test and iterate features more effectively, vastly improved page load/speed, shared standards for development and light at the end of our multiple-CMS tunnel, among others.
From a product point of view, this entirely logical restructure necessitates a good deal of change management and a fundamental rethink of brand relationships. Rather than focusing on a single title (or in some cases multiple brands) the product owner needs to consider what is best for the wider audience who will benefit from their feature or service, even if it is developed primarily for one. This lends itself to research and data-driven development; rather than constantly adding features to a site, app or service to facilitate ‘growth’, there needs to be a clear business case (based on benefits to the users, who could be internal or external, and revenue strategies) for creating or expanding a feature set.
It sounds simple (possibly) but that would be to ignore the complexity added by two factors: the transition period when many sites are still on legacy platforms, and the process of evolving the product relationship with a brand or brands.
The two factors are inextricably linked during the transition period. Editors and publishers still have plans for their publications, which need to continue to serve users and generate revenue, but the technological focus has shifted to platform development. Product teams are in the middle, with a dual role of assessing and communicating which legacy development is still necessary (the age-old business-as-usual vs new product development conundrum, on steroids) and keeping focused on their feature set roadmap. It’s not a particularly comfortable place to be, and it requires constant communication around progress and priorities. Early buy-in on the long-term benefits is vital, as without it the short-term frustration at a lack of progress on BAU is toxic. If there is one lesson I have taken away from this process, it is the reinforcement of understanding that early, proactive over-communication builds a much stronger foundation for making difficult prioritisation decisions later on. Alex Watson gives a fantastic talk about the power of communicating the story of the project here.
The transition to a feature-led structure fundamentally changes the relationship between brand and product owner. The PM is planning out the iteration of features that at their generic core need to work for multiple audiences, rather than focusing on the KPIs for one. Beyond the fun and games of the transition period, this means letting go of some domain expertise and working as a product and technology team to assess all the ideas, requests and data across the business for prioritisation. In a business where multiple teams contribute features to one primary product (a Snapchat or a major news brand, for example) this may be more straightforward than within a multiple-brand business, where features may be relevant to one, several or all brands. (I’m happy to be corrected on that one, having not yet worked in a single-brand environment.)
For a PM who has invested time, energy and emotion in building domain expertise and relationships with a brand, it’s an interesting challenge to change focus and think more generically. Luckily we have a cracking group of product managers who have risen to that challenge. The next phase is to work with all the other teams to guide our brands through the transition phase onto a new platform. Bring it on.
