As part of our ‘5 Minutes With…’ series, we caught up with David Berlin, who launched DAZN across all platforms and the BBC iPlayer iPhone app, amongst others, during a career in product spanning more than 20 years. David has recently taken up post as VP of Product at UNiDAYS.
The iPlayer app became the most successful iPad app ever in the UK and iPlayer was the number 1 app in the UK in both app stores for over a year during his time at the BBC. He joined DAZN as a founding team member of 12 employees and helped grow the organisation to more than 3,000. He launched and grew the mobile apps to be the top grossing sports apps worldwide with 8 million paying subscribers of DAZN within 3.5 years, which we believe was a growth record, until more recently broken by Disney Plus. We talked to him about the secret sauce behind inventing these icon apps.
David, you’ve launched two of the world’s most successful streaming services, have you always had the Midas touch?
With both of those launches, I worked within brilliant teams, including Ben Lavender (invented iPlayer, launched Amazon Prime Video and DAZN), David Madden (iPlayer mobile), Marcus Parnwell (iPlayer and DAZN living room) and Will Briggs (Livesport and DAZN) amongst others, but I think much of the success of my particular involvement was due to the large amount of myspectacular failures / learnings with previous projects.
I invented and launched the world’s first interactive VOD shopping channel in September 2009 on the BT Vision platform. Gaby Roslin was your celebrity shop assistant, helping you find a kitchen gadget for your parent, or a tech tool for your sibling’s birthday. The concept was a great idea that no one wanted, and the project failed badly / provided badass learning!
Later in 2009, during the first year of the existence of the Apple App Store, I founded a start-up to build a satirical news mobile app. I approached the project in a very Waterfall way and tried to get funding for a well-rounded experience at launch, when we should have focussed on a basic Minimum Viable Product (MVP), launched, and then iterated based on user feedback. Unfortunately, we didn’t manage to get sufficient funding due to these failings / learnings.
However, in 2011 the BBC were looking for a Product person with rare VOD and mobile app experience to work out what the iPhone iPlayer app should do, and in their desperation, they turned to me. Throughout my career, my past disappointments have proved genuinely helpful with future challenges, without learn / fail!
So how do you get started with any new innovation project?
First you need to understand the user need/problem/opportunity.
Einstein is commonly quoted as saying: “If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions.” In fact, he didn’t ever say this, but he should have done, it’s very wise and whoever did come up with this was well worth listening to.
I was very lucky when, early on in my career, senior members of Apple Developer Relations from Cupertino shared some gold with me: “Don’t try to create a new user need - it is very hard and only organisations with extremely large existing userbases can even contemplate it - find an existing need and serve it better than before. That’s what makes a successful app!” For example, Netflix, Uber, Airbnb etc. all cater to long standing existing needs, but serve them better due to technological advances.
So, you first need to look for pain points in modern life that are relevant to your area of business and make sure you really understand where there could be opportunity for your organisation to focus
How do you go about finding these pain points?
It is important to consider the goals of your organisation - your North Star, or top level OKRs; what the company is trying to achieve, because whatever user needs you try to solve must align with the company goals, for example if the company is focussed on retaining existing users, you should not be innovating in the area of expansion into new markets.
You also need to understand the parameters within which your organisation is prepared to operate. For instance, if your core business is a marketplace app, your Board may not be prepared to let you innovate with producing a new product to sell on that marketplace, jeopardising the company’s impartiality and damaging partner relationships etc.
Clues to underserved needs and new opportunities can come from many places, including your usage data, market data, competitor analysis, tech trade fairs, user testing, stakeholders ,and the zeitgeist etc.
Only once you have comprehensively understood your business goals and parameters, as well as your problem / opportunity / need, can you move onto the ideation phase and start thinking about solutions.
Who do you invite to participate in the ideation phase?
There are 2 traditional approaches to innovation:
Microsoft/Tony Blair: Ask the people what they want
Apple/Henry Ford: "If I had asked people what they wanted, they would have said faster horses.", ask the experts instead
Neither of these approaches work in isolation and in reality, both Microsoft and Apple, as well as anyone who has successfully innovated, combine the two. Obviously, an expert, who is aware of what cutting edge technology could help, is better placed to try to solve a user need than an unskilled user who has no expertise in that field. However, as Marty Cagan stresses in The Inconvenient Truth About Product: “At least half of our ideas are just not going to work… customers just aren’t as excited about this idea as we are… it’s so complicated that it’s simply more trouble than it’s worth”.
So, we must ask experts to hypothesize which solutions will serve those user needs best, then rapidly test the hell out of these solutions to validate they genuinely work with real users, before committing too much company time or resource.
And who are these “experts”? I generally assemble an Avenger-like team of representatives from Product, UX (incl. UX Research), Tech, Data, and “The Business” (whilst a Programme Manager is also a good idea once people start getting actions). ‘The Business” is represented by whoever is best placed from elsewhere within the organisation, depending on the area you are innovating. For instance, if your innovation is surrounding landing pages, then invite someone from Marketing, whilst if you are thinking about Homepage layout, perhaps someone from Content would be appropriate and so forth.
How do you structure an ideation phase to optimise innovation?
There are a few common elements that I have found to be useful in all innovation scenarios:
When introducing the project to the innovation team of experts, it is the leading Product Manager’s role to frame the business and user need, without suggesting their own ideas for solutions. You may have a strong idea for a solution, but you should first illicit ideas from the group. There are 2 major benefits of this:
If necessary, you can usually gently steer consensus in the direction of your original idea, but your team members will think it was their idea. This will mean that they evangelise the concept to the rest of the development team, work harder to deliver it and skip to work with a beam on their face.
More importantly, your teammates may come up with better ideas than you, but you seeding your original idea in their brains could have sabotaged this.
Use an “algebraic approach” – make a list of principles and elements that are already known to you and from this you can start extrapolating what should happen in the unknown scenarios. As an example, Known Element: users will want to download content; Previously Unknown: we will need an area of the app that’s available offline where users can access their downloaded content.
Identify all the user touchpoints along the journeys through your innovation and brainstorm what the specific user needs are at each interaction – this will help you focus on relevant solutions and prioritise recurring themes. Miro is a brilliant collaborative tool for mapping and commenting on this.
Identify the ideal user experience first and work backwards to how you might get there with iterations, rather than looking at your current situation and thinking about a first iteration. You want to get to the ideal ASAP, so all iterations should bring you in that direction. If you just think about your first iteration, you may start in the wrong direction and waste valuable time and code – the only exception to this is if you have a hard deadline and you are prepared for your first iteration to be thrown away later.
In my experience, completely separating R&D teams from production delivery teams is a bad idea. The R&D team have all the creative fun and throw an innovation over the fence, then the delivery team get that “not invented here” feeling and pick holes in the solution. Also, the ideation should be performed by experts who are close to the coalface and best understand the problem space. So, it is important to pick individuals for the ideation team from amongst the wider team who will deliver the solutions, as they will evangelise the ideas that they feel they had a hand in and work infectiously hard and happy.
No bad ideas –no one should be ridiculed for anything they say. In addition to the obvious cultural benefits of creating a safe space for your team, a crazy idea could spark something brilliant and viable in another teammate’s mind.
Now you understand the business and user needs, and have a load of hypothesized solutions, how do you work out which ideas are likely to be a success?
It really depends on the nature of the project. For example, are you launching a whole new app from scratch, or just optimising an existing function. Horses for courses.
Here are a few of the main approaches I have found useful, and once you have agreed success metrics for each hypothesis, you can use any of these methods or a combination, whatever the size of your organisation:
Google Design Sprints – An intensive week of understanding needs, defining, sketching, deciding, prototyping and validating with users. Great for proper blue sky thinking around chunky projects, especially when involving multiple departments.
PR-FAQs – Developed by Amazon as part of their ‘working backwards’ methodology, where you imagine it is launch day for your initiative and write a Press Release (PR) for it. You then ask yourself which Frequently Asked Questions (FAQs) users would have, as well as what others in your organisation would need to know about the project. Once you have an initial draft, you call a company meeting with all major stakeholders from relevant disciplines and everyone sits in awkward silence to read and comment on the doc, before discussing the main issues as a group. This is a brilliant way to gain rapid buy in from all stakeholders (or failing / learning fast), as well as enabling Marketing and PR to start thinking about if they want to promote it, uncovering data gaps, architectural, legal or privacy issues etc. Again, this is great for major projects, where you need to take the whole business on the journey.
Prototyping – I like to rapidly test solutions to whatever need is coming up on the roadmap, usually every week. We have an Experimentation Pipeline always running a few weeks or sprints ahead of the Tech Roadmap and we only move solutions into a build phase once they’ve been de-risked with users, so we only back the horses that evidence suggests will win. The focus is building confidence in the concept and making evidence-based decisions with minimum fidelity. Figma and ProtoPie are great prototyping tools, whilst Usertesting.com makes getting new, or existing, user feedback easy.
PoCs – Proofs of Concept are useful to establish whether your tech team will be able to deliver your desired solution, and they are often well worth user testing. Tech should advise on whether one is appropriate, for instance how your service could benefit from integrating with Machine Learning functions.
Fake door testing – For some solutions user feedback is not reliable, for example when testing pricing or discounts. You could ask a user if they are more likely to subscribe or buy if they got 30% off, or pay monthly, and they are bound to say “Yes”, but in a user test you can’t then say “Well go on then!” and expect a realistic (or polite) response. Instead of building a fully functioning feature with no evidence of validation, you can think cleverly about how to test the concept cheaply, perhaps with CTAs on landing screens like “Pay monthly” which just bring up a message saying something like “We’re currently working on this feature” etc. Be sparing with this method, as you can really annoy your users.
Surveys – You can often get a basic steer on whether users will want a feature by simply asking them via user surveys. Reaching out by email, in-app, or during user testing. I’ve used these well in advance to get a feel of whether there’s basic user interest in a general area.
Holistic Behavioural Design Framework – This is a framework developed by the Principle UX Researcher and Psychologist Dr Sam Howard, with whom I worked at DAZN and Curio, which identifies the key factors determining whether a user will decide, and is also able, to use a service. It is based on previous models by the likes of BJ Fogg and can act as a checklist to determine whether a solution tickles all the right zones for users, as well as uncovering untapped opportunities.
More than 50% of the experiments that the likes of Amazon or Microsoft try have negative results and it is imperative for organisations of all sizes to build confidence in solutions quickly and cheaply, before moving them into an expensive full fat build phase.
The above is really just scratching the surface, but since co-founding the Business Analysis course at the BBC Academy, I have thoroughly enjoyed mentoring and coaching, whilst there is always more to learn; so, I’m really interested if you think I’ve missed anything major, you need advice on structuring an innovation workshop, or you want to share any of your own useful past failures / learnings.
