Esta é a tradução do texto original de Joakim Sundén, publicado no blog da CRISP. O artigo pode ser acessado aqui, e todos os créditos são devidos ao autor, Joakim Sundén.
Nota de Joakim:
Spotify é uma empresa excepcional, a melhor em que já trabalhei. Quando deixei a empresa após mais de seis anos, quis ajudar outras companhias a se tornarem mais parecidas com o Spotify. No entanto, eu não acreditava que as empresas poderiam simplesmente copiar as estruturas organizacionais de tribes, chapters e squads que ficaram conhecidas como o “Spotify model”, mas queria explicar o que realmente diferenciava o Spotify. Com esse objetivo, nasceu o curso “Agile at Scale, Inspired by Spotify” (em colaboração com o colega da Crisp, Jimmy Janlén). O tema central do curso girava em torno do conceito de Autonomous Squad e descrevia como o Spotify e seus líderes promovem e apoiam essa autonomia.
As práticas no livro de Marty Cagan, “Inspired”, influenciaram significativamente o modelo operacional do Spotify. Então, quando ele começou a falar sobre Empowered Product Teams, isso ecoou exatamente o que queríamos dizer com “autonomous squad”. Logo comecei a incorporar essa terminologia e baseei-me fortemente nas explicações perspicazes de Marty e da SVPG sobre a ideia. Quando o livro “Empowered” foi lançado, fiquei impressionado com o quanto ele articulava de perto minhas experiências no Spotify. E agora, eles me forneceram conceitos ainda melhores para explicar o verdadeiro Spotify model por meio da definição de “product operating model” e como esse modelo é diferente do que a maioria das empresas está fazendo.
Quando Marty visitou Estocolmo e a Crisp para conduzir seu novo workshop “Transformed”, onde explicou o modelo e seus conceitos, ficou claro para mim que o modelo do Spotify é um product operating model — ou mais precisamente, uma variante dele. Marty propôs que coautorássemos um artigo para ilustrar esse paralelo. Para compreender completamente os insights que compartilharemos, é benéfico ter pelo menos uma compreensão em alto nível do product operating model, já que este artigo irá comparar o Spotify model ao modelo de produto. Se você não estiver familiarizado com os conceitos fundamentais, recomendo começar com esta série de quatro artigos.
Background
No final dos anos 2000, o Spotify transformou a indústria da música ao convencer as principais gravadoras de que o streaming era o futuro.
Até 2014, o serviço já havia acumulado 60 milhões de usuários ativos, e a batalha agora havia mudado para outro campo de disputa. Muitos novos concorrentes, incluindo Google, Amazon e Apple, estavam prontos para entrar na competição com seus próprios serviços de assinatura de streaming.
O fácil acesso à música por meio do streaming — algo que o Spotify havia batalhado tanto para conquistar — já não era mais um diferencial competitivo, e sim uma obrigação básica (table-stakes). O Spotify precisava continuar inovando para manter sua liderança no mercado.
O Modelo Operacional de Produto
Quando discutimos o product operating model, no alto nível, estamos olhando para três dimensões principais:
A primeira é como a empresa decide quais são os problemas mais importantes a serem resolvidos — a product strategy. A segunda é como a empresa resolve esses problemas e descobre soluções que valem a pena serem construídas — a product discovery. E a terceira é como a empresa constrói, testa e entrega essas soluções aos seus clientes — a product delivery.
Este artigo tentará destacar como o Spotify abraça e incorpora os princípios por trás de cada uma dessas três dimensões.
Como Decidir Quais Problemas Resolver – Estratégia de Produto
O CEO e cofundador do Spotify, Daniel Ek, descreveu a situação como enfrentar o “end-boss” em um jogo de videogame. “Estamos na liga principal agora, e [algumas das maiores empresas do mundo] estão nos atacando… Acreditamos que a coisa mais importante que podemos fazer para maximizar nosso potencial é aumentar nossa diferenciação em relação a outros serviços.”
A product strategy do Spotify foi moldada por insights sobre como seu público se segmentava. O Spotify sabia que basicamente tinha dois tipos principais de usuários: aqueles que sabiam qual música queriam ouvir, que chamavam de ouvintes “lean-forward”, e aqueles que não sabiam realmente quais artistas ou álbuns queriam, e apenas queriam que o serviço os ajudasse a descobrir músicas que amariam, chamados de ouvintes “lean-back”.
Por muito tempo, o Spotify achava que o serviço já era bom o suficiente para a descoberta de músicas. Tudo o que você precisava era de uma boa barra de pesquisa e uma ferramenta de listas de reprodução. Quão difícil poderia ser?
Bastante difícil, como acabou se revelando, para os muitos usuários “lean-back” que não tinham o tempo, nem o conhecimento, que os primeiros adeptos e os nerds musicais empregados pelo Spotify tinham.
Outro insight estratégico foi que mais e mais usuários estavam descobrindo músicas por meio do que o Spotify chamou de Moments, como “estudando”, “correndo” ou “jantar”, em vez de procurar gêneros ou artistas específicos.
O Spotify já havia começado a transição de um modelo onde o usuário fazia o trabalho de seguir pessoas e listas de reprodução para construir sua biblioteca musical, para um modelo baseado em recomendações, onde o serviço fazia o trabalho com base no que o usuário havia ouvido anteriormente.
Ao perceber que as recomendações precisavam se tornar uma parte central da estratégia de produto, o Spotify adquiriu recentemente a start-up de Massachusetts chamada The Echo Nest. Os ex-engenheiros da Echo Nest agora trabalhavam junto com os engenheiros de machine learning do Spotify para ajudar a melhorar a descoberta de músicas baseada em recomendações.
Assim, a liderança do Spotify reuniu suas equipes de produto e explicou que precisavam focar em entender por que o serviço não estava performando tão bem no caso de uso “lean-back” e tentar resolver isso.
Esse foco significou dizer “não” para muitas outras oportunidades potenciais e adiar ou descontinuar outras. Por exemplo, eles encerraram uma grande iniciativa em torno do streaming de vídeo, e as pessoas e os recursos foram realocados para focar no problema dos ouvintes “lean-back”.
Essa visão holística do negócio e o foco resultante permitem que as equipes de produto dediquem sua energia aos problemas mais críticos a serem resolvidos, aumentando a probabilidade de sucesso.
Como Resolver Problemas – Descoberta de Produto
Inicialmente, o Spotify tinha uma abordagem de recomendações chamada Discover, que apresentava sugestões de álbuns em um layout estilo Netflix, com base no histórico de audição pessoal do usuário, mas isso parecia exigir muita interação dos usuários, que expressaram o desejo de “me coloque em movimento rapidamente, sem muito esforço.”
Ao mesmo tempo, o novo recurso Browse do Spotify, que se tornou a nova visão inicial do aplicativo e exibia listas de reprodução selecionadas manualmente, como “Your Favorite Coffeehouse” pela equipe editorial do Spotify, estava experimentando um envolvimento significativamente maior dos usuários em comparação ao recurso Discover.
Além disso, certos críticos da indústria argumentavam que os usuários “lean-back” simplesmente não estavam interessados em explorar novas músicas.
No entanto, alguns dos engenheiros de machine learning que estavam trabalhando em recomendações não acreditavam nisso. Eles achavam que deveria haver uma maneira de reduzir a fricção para os usuários e ajudá-los a navegar pelos 30 milhões de músicas para encontrar ótimas recomendações.
O otimismo deles foi reforçado por um projeto recente de hack week, chamado Play It Forward, que era um complemento ao recurso popular do Spotify, Year In Music (agora conhecido como Wrapped), uma funcionalidade que fornecia um resumo do ano do usuário no Spotify.
O Play It Forward analisou o histórico de audição dos usuários, usando o mesmo algoritmo do Discover, para criar uma lista de reprodução de músicas que você ainda não tinha ouvido no Spotify, mas que provavelmente iria gostar.
A lista de reprodução foi apresentada aos usuários ao final de sua revisão do Year In Music. Meses depois, os engenheiros ficaram surpresos ao descobrir que milhões de usuários continuavam engajados com ela.
Isso gerou uma ideia: e se pudéssemos criar uma lista de reprodução assim e apenas atualizá-la com mais frequência? Essa foi a semente da ideia que seria conhecida como Discover Weekly.
O conceito era relativamente simples e poderia potencialmente aproveitar a tecnologia existente. O recurso categorizava seu histórico de audição em micro-genres. Ele então usava collaborative filtering em bilhões de listas de reprodução criadas por usuários, identificando aqueles usuários que, assim como você, ouviam x e também ouviam y — uma faixa que você ainda não havia descoberto no Spotify.
Os engenheiros apresentaram a ideia ao product manager e ao product designer, e eles iniciaram a colaboração multifuncional entre produto, design e engenharia para avaliar os possíveis riscos do produto.
Como Você Constrói – Entrega de Produto
Em 2006, no início do Spotify, a abordagem padrão Waterfall para o desenvolvimento de produtos de software envolvia meses de codificação, predominantemente guiados por partes interessadas internas, antes de lançar o produto para o mundo.
Uma desvantagem óbvia dessa abordagem era o feedback escasso dos usuários até o final do projeto, resultando em um produto mais reflexo das preferências das partes interessadas internas, com a esperança otimista de que também ressoasse com os potenciais clientes.
Reconhecendo essas limitações, os líderes e as equipes de produto do Spotify perceberam logo no início da jornada que uma abordagem melhor para descobrir e entregar produtos era necessária.
Consequentemente, foram feitos investimentos substanciais para apoiar a experimentação necessária e fornecer às equipes de produto acesso a dados cruciais de comportamento dos usuários. Isso incluiu a infraestrutura para instrumentação, telemetry, monitoramento e relatórios. A empresa também investiu fortemente em infraestrutura de implantação, especialmente para A/B testing, com uma equipe de produto dedicada à plataforma focada em habilitar esses testes com dados ao vivo.
O Spotify também foi um defensor precoce de releases pequenos, frequentes e desacoplados, investindo nas ferramentas e técnicas de Continuous Delivery.
Como as habilidades do Spotify em entrega de produtos são bem conhecidas na indústria, não vamos gastar muito tempo nisso aqui. No entanto, é fundamental perceber que esses investimentos são o que capacita as equipes de produto do Spotify a entregar outcomes, e não apenas output.
Essa infraestrutura de entrega abriu caminho para o Discover Weekly e inúmeras outras inovações do Spotify, grandes e pequenas.
Os Resultados
Poucos meses depois, o Discover Weekly estava pronto para sua estreia global, sendo lançado para todos os usuários do Spotify.
O release foi um sucesso retumbante, com 1 bilhão de faixas transmitidas nas primeiras 10 semanas. Notavelmente, 71% dos ouvintes adicionaram pelo menos uma música às suas playlists pessoais, e 60% daqueles que experimentaram o Discover Weekly continuaram a ouvir cinco ou mais faixas.
O burburinho online foi igualmente entusiástico, com usuários compartilhando reações emocionais como: “Fiquei muito animado e comecei a chorar um pouco porque percebi que amanhã é segunda-feira, e o Spotify está me fazendo um novo Discover Weekly.”
Equipes de Produto e Cultura de Produto
Esperamos que essa análise sobre o trabalho de produto no Spotify ajude a esclarecer o poder de equipes de produto fortes, lideradas por líderes de produto fortes, trabalhando no product model.
Embora o Spotify seja bem conhecido por suas equipes de produto capacitadas, esse exemplo mostra o que esse conceito realmente significa na prática. Requer líderes de produto fortes que forneçam o contexto estratégico – especialmente as difíceis decisões de estratégia de produto – e saibam como criar o ambiente necessário para que as equipes de produto façam um bom trabalho.
O cofundador Daniel acreditava em uma estrutura onde a responsabilidade pelos resultados de negócios, alinhada com uma compreensão clara da estratégia de produto, utilizando experimentação orientada por dados, produziria os melhores resultados – mesmo que as ideias não fossem dele.
Uma das razões pelas quais esse exemplo do Discover Weekly é tão ilustrativo é porque Daniel foi abertamente cético em relação à ideia do produto e compartilhou suas preocupações com a equipe de produto. Mas, para seu crédito, ele deu à equipe um problema a ser resolvido e então permitiu que o trabalho prosseguisse.
E para o crédito da equipe de produto, eles viram o potencial da tecnologia capacitadora e se encarregaram de enfrentar os riscos do produto de forma responsável e eficaz. Isso está por trás de muitas inovações movidas pela tecnologia, e é isso que realmente significa equipes de produto capacitadas.
Como outras empresas que seguem o product model, o Spotify reconhece que as ideias mais inovadoras – aquelas que realmente ressoam com os clientes – muitas vezes surgem daqueles que interagem com a tecnologia capacitadora diariamente: os engenheiros. Eles estão em uma posição única para identificar novas possibilidades.
Grandes líderes entendem a necessidade de criar um ambiente onde equipes de produto capacitadas possam exercer sua criatividade, descobrindo e entregando soluções inovadoras que não só os clientes amam, mas também impulsionam o sucesso dos negócios.
Aprendendo Mais
No ano passado, a convite da Crisp, Marty fez uma palestra relacionada voltada principalmente para coaches de produto e Agile, tentando explicar as diferentes abordagens para scaling e por que o Spotify prosperou enquanto muitos outros falharam. Você pode ver a palestra aqui.
E claro, eu falei longamente sobre o Spotify e sua cultura. Aqui está uma das minhas palestras mais populares, e eu também ensino um curso sobre o tema.
Treinamentos relacionados com essa postagem
