{"id":1656,"date":"2024-10-03T07:05:00","date_gmt":"2024-10-03T10:05:00","guid":{"rendered":"https:\/\/www.semeru.com.br\/blog\/?p=1656"},"modified":"2024-09-26T14:33:35","modified_gmt":"2024-09-26T17:33:35","slug":"o-modelo-de-produto-no-spotify","status":"publish","type":"post","link":"https:\/\/www.semeru.com.br\/blog\/o-modelo-de-produto-no-spotify\/","title":{"rendered":"O Modelo de Produto no Spotify<\/strong>"},"content":{"rendered":"\n

Esta \u00e9 a tradu\u00e7\u00e3o do texto original de Joakim Sund\u00e9n<\/strong><\/a>, publicado no blog da CRISP<\/strong><\/a>. O artigo pode ser acessado aqui<\/a>, e todos os cr\u00e9ditos s\u00e3o devidos ao autor, Joakim Sund\u00e9n<\/a><\/strong>.<\/em><\/p>\n\n\n\n

Nota de Joakim<\/em>:<\/p>\n\n\n\n

Spotify \u00e9 uma empresa excepcional, a melhor em que j\u00e1 trabalhei. Quando deixei a empresa ap\u00f3s mais de seis anos, quis ajudar outras companhias a se tornarem mais parecidas com o Spotify. No entanto, eu n\u00e3o acreditava que as empresas poderiam simplesmente copiar as estruturas organizacionais de tribes<\/em>, chapters<\/em> e squads<\/em> que ficaram conhecidas como o \u201cSpotify model<\/strong>\u201d, mas queria explicar o que realmente diferenciava o Spotify. Com esse objetivo, nasceu o curso \u201cAgile at Scale, Inspired by Spotify\u201d (em colabora\u00e7\u00e3o com o colega da Crisp, Jimmy Janl\u00e9n). O tema central do curso girava em torno do conceito de Autonomous Squad<\/strong> e descrevia como o Spotify e seus l\u00edderes promovem e apoiam essa autonomia.<\/p>\n\n\n\n

As pr\u00e1ticas no livro de Marty Cagan, \u201cInspired\u201d, influenciaram significativamente o modelo operacional do Spotify. Ent\u00e3o, quando ele come\u00e7ou a falar sobre Empowered Product Teams<\/strong>, isso ecoou exatamente o que quer\u00edamos dizer com \u201cautonomous squad<\/strong>\u201d. Logo comecei a incorporar essa terminologia e baseei-me fortemente nas explica\u00e7\u00f5es perspicazes de Marty e da SVPG<\/strong> sobre a ideia. Quando o livro \u201cEmpowered\u201d foi lan\u00e7ado, fiquei impressionado com o quanto ele articulava de perto minhas experi\u00eancias no Spotify. E agora, eles me forneceram conceitos ainda melhores para explicar o verdadeiro Spotify model<\/strong> por meio da defini\u00e7\u00e3o de \u201cproduct operating model<\/strong>\u201d e como esse modelo \u00e9 diferente do que a maioria das empresas est\u00e1 fazendo.<\/p>\n\n\n\n

Quando Marty visitou Estocolmo e a Crisp para conduzir seu novo workshop \u201cTransformed<\/strong>\u201d, onde explicou o modelo e seus conceitos, ficou claro para mim que o modelo do Spotify \u00e9 um product operating model<\/strong> \u2014 ou mais precisamente, uma variante dele. Marty prop\u00f4s que coautor\u00e1ssemos um artigo para ilustrar esse paralelo. Para compreender completamente os insights que compartilharemos, \u00e9 ben\u00e9fico ter pelo menos uma compreens\u00e3o em alto n\u00edvel do product operating model<\/strong>, j\u00e1 que este artigo ir\u00e1 comparar o Spotify model<\/strong> ao modelo de produto. Se voc\u00ea n\u00e3o estiver familiarizado com os conceitos fundamentais, recomendo come\u00e7ar com esta s\u00e9rie de quatro artigos.<\/p>\n\n\n\n

Background<\/em><\/h3>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n

No final dos anos 2000, o Spotify transformou a ind\u00fastria da m\u00fasica ao convencer as principais gravadoras de que o streaming era o futuro.<\/p>\n\n\n\n

At\u00e9 2014, o servi\u00e7o j\u00e1 havia acumulado 60 milh\u00f5es de usu\u00e1rios 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\u00e7\u00e3o com seus pr\u00f3prios servi\u00e7os de assinatura de streaming.<\/p>\n\n\n\n

O f\u00e1cil acesso \u00e0 m\u00fasica por meio do streaming \u2014 algo que o Spotify havia batalhado tanto para conquistar \u2014 j\u00e1 n\u00e3o era mais um diferencial competitivo, e sim uma obriga\u00e7\u00e3o b\u00e1sica (table-stakes<\/em>). O Spotify precisava continuar inovando para manter sua lideran\u00e7a no mercado.<\/p>\n\n\n\n

O Modelo Operacional de Produto<\/strong><\/h3>\n\n\n\n

Quando discutimos o product operating model<\/strong>, no alto n\u00edvel, estamos olhando para tr\u00eas dimens\u00f5es principais:<\/p>\n\n\n\n

A primeira \u00e9 como a empresa decide quais s\u00e3o os problemas mais importantes a serem resolvidos \u2014 a product strategy<\/strong>. A segunda \u00e9 como a empresa resolve esses problemas e descobre solu\u00e7\u00f5es que valem a pena serem constru\u00eddas \u2014 a product discovery<\/strong>. E a terceira \u00e9 como a empresa constr\u00f3i, testa e entrega essas solu\u00e7\u00f5es aos seus clientes \u2014 a product delivery<\/strong>.<\/p>\n\n\n\n

Este artigo tentar\u00e1 destacar como o Spotify abra\u00e7a e incorpora os princ\u00edpios por tr\u00e1s de cada uma dessas tr\u00eas dimens\u00f5es.<\/p>\n\n\n\n

Como Decidir Quais Problemas Resolver \u2013 Estrat\u00e9gia de Produto<\/strong><\/h3>\n\n\n\n

O CEO e cofundador do Spotify, Daniel Ek, descreveu a situa\u00e7\u00e3o como enfrentar o \u201cend-boss<\/em>\u201d em um jogo de videogame. \u201cEstamos na liga principal agora, e [algumas das maiores empresas do mundo] est\u00e3o nos atacando… Acreditamos que a coisa mais importante que podemos fazer para maximizar nosso potencial \u00e9 aumentar nossa diferencia\u00e7\u00e3o em rela\u00e7\u00e3o a outros servi\u00e7os.\u201d<\/p>\n\n\n\n

A product strategy<\/strong> do Spotify foi moldada por insights sobre como seu p\u00fablico se segmentava. O Spotify sabia que basicamente tinha dois tipos principais de usu\u00e1rios: aqueles que sabiam qual m\u00fasica queriam ouvir, que chamavam de ouvintes \u201clean-forward\u201d, e aqueles que n\u00e3o sabiam realmente quais artistas ou \u00e1lbuns queriam, e apenas queriam que o servi\u00e7o os ajudasse a descobrir m\u00fasicas que amariam, chamados de ouvintes \u201clean-back\u201d.<\/p>\n\n\n\n

Por muito tempo, o Spotify achava que o servi\u00e7o j\u00e1 era bom o suficiente para a descoberta de m\u00fasicas. Tudo o que voc\u00ea precisava era de uma boa barra de pesquisa e uma ferramenta de listas de reprodu\u00e7\u00e3o. Qu\u00e3o dif\u00edcil poderia ser?<\/p>\n\n\n\n

Bastante dif\u00edcil, como acabou se revelando, para os muitos usu\u00e1rios \u201clean-back\u201d que n\u00e3o tinham o tempo, nem o conhecimento, que os primeiros adeptos e os nerds<\/em> musicais empregados pelo Spotify tinham.<\/p>\n\n\n\n

Outro insight estrat\u00e9gico foi que mais e mais usu\u00e1rios estavam descobrindo m\u00fasicas por meio do que o Spotify chamou de Moments<\/strong>, como \u201cestudando\u201d, \u201ccorrendo\u201d ou \u201cjantar\u201d, em vez de procurar g\u00eaneros ou artistas espec\u00edficos.<\/p>\n\n\n\n

O Spotify j\u00e1 havia come\u00e7ado a transi\u00e7\u00e3o de um modelo onde o usu\u00e1rio fazia o trabalho de seguir pessoas e listas de reprodu\u00e7\u00e3o para construir sua biblioteca musical, para um modelo baseado em recomenda\u00e7\u00f5es, onde o servi\u00e7o fazia o trabalho com base no que o usu\u00e1rio havia ouvido anteriormente.<\/p>\n\n\n\n

Ao perceber que as recomenda\u00e7\u00f5es precisavam se tornar uma parte central da estrat\u00e9gia de produto, o Spotify adquiriu recentemente a start-up<\/em> de Massachusetts chamada The Echo Nest<\/strong>. Os ex-engenheiros da Echo Nest agora trabalhavam junto com os engenheiros de machine learning<\/strong> do Spotify para ajudar a melhorar a descoberta de m\u00fasicas baseada em recomenda\u00e7\u00f5es.<\/p>\n\n\n\n

Assim, a lideran\u00e7a do Spotify reuniu suas equipes de produto e explicou que precisavam focar em entender por que o servi\u00e7o n\u00e3o estava performando t\u00e3o bem no caso de uso \u201clean-back\u201d e tentar resolver isso.<\/p>\n\n\n\n

Esse foco significou dizer \u201cn\u00e3o\u201d para muitas outras oportunidades potenciais e adiar ou descontinuar outras. Por exemplo, eles encerraram uma grande iniciativa em torno do streaming de v\u00eddeo, e as pessoas e os recursos foram realocados para focar no problema dos ouvintes \u201clean-back\u201d.<\/p>\n\n\n\n

Essa vis\u00e3o hol\u00edstica do neg\u00f3cio e o foco resultante permitem que as equipes de produto dediquem sua energia aos problemas mais cr\u00edticos a serem resolvidos, aumentando a probabilidade de sucesso.<\/p>\n\n\n\n\n \n<\/a>\n\n\n\n

Como Resolver Problemas \u2013 Descoberta de Produto<\/strong><\/h3>\n\n\n\n

Inicialmente, o Spotify tinha uma abordagem de recomenda\u00e7\u00f5es chamada Discover<\/strong>, que apresentava sugest\u00f5es de \u00e1lbuns em um layout estilo Netflix, com base no hist\u00f3rico de audi\u00e7\u00e3o pessoal do usu\u00e1rio, mas isso parecia exigir muita intera\u00e7\u00e3o dos usu\u00e1rios, que expressaram o desejo de \u201cme coloque em movimento rapidamente, sem muito esfor\u00e7o.\u201d<\/p>\n\n\n\n

Ao mesmo tempo, o novo recurso Browse<\/strong> do Spotify, que se tornou a nova vis\u00e3o inicial do aplicativo e exibia listas de reprodu\u00e7\u00e3o selecionadas manualmente, como \u201cYour Favorite Coffeehouse\u201d pela equipe editorial do Spotify, estava experimentando um envolvimento significativamente maior dos usu\u00e1rios em compara\u00e7\u00e3o ao recurso Discover<\/strong>.<\/p>\n\n\n\n

Al\u00e9m disso, certos cr\u00edticos da ind\u00fastria argumentavam que os usu\u00e1rios \u201clean-back\u201d simplesmente n\u00e3o estavam interessados em explorar novas m\u00fasicas.<\/p>\n\n\n\n

No entanto, alguns dos engenheiros de machine learning<\/strong> que estavam trabalhando em recomenda\u00e7\u00f5es n\u00e3o acreditavam nisso. Eles achavam que deveria haver uma maneira de reduzir a fric\u00e7\u00e3o para os usu\u00e1rios e ajud\u00e1-los a navegar pelos 30 milh\u00f5es de m\u00fasicas para encontrar \u00f3timas recomenda\u00e7\u00f5es.<\/p>\n\n\n\n

O otimismo deles foi refor\u00e7ado por um projeto recente de hack week<\/strong>, chamado Play It Forward<\/strong>, que era um complemento ao recurso popular do Spotify, Year In Music<\/strong> (agora conhecido como Wrapped<\/strong>), uma funcionalidade que fornecia um resumo do ano do usu\u00e1rio no Spotify.<\/p>\n\n\n\n

O Play It Forward<\/strong> analisou o hist\u00f3rico de audi\u00e7\u00e3o dos usu\u00e1rios, usando o mesmo algoritmo do Discover<\/strong>, para criar uma lista de reprodu\u00e7\u00e3o de m\u00fasicas que voc\u00ea ainda n\u00e3o tinha ouvido no Spotify, mas que provavelmente iria gostar.<\/p>\n\n\n\n

A lista de reprodu\u00e7\u00e3o foi apresentada aos usu\u00e1rios ao final de sua revis\u00e3o do Year In Music<\/strong>. Meses depois, os engenheiros ficaram surpresos ao descobrir que milh\u00f5es de usu\u00e1rios continuavam engajados com ela.<\/p>\n\n\n\n

Isso gerou uma ideia: e se pud\u00e9ssemos criar uma lista de reprodu\u00e7\u00e3o assim e apenas atualiz\u00e1-la com mais frequ\u00eancia? Essa foi a semente da ideia que seria conhecida como Discover Weekly<\/strong>.<\/p>\n\n\n\n

O conceito era relativamente simples e poderia potencialmente aproveitar a tecnologia existente. O recurso categorizava seu hist\u00f3rico de audi\u00e7\u00e3o em micro-genres<\/strong>. Ele ent\u00e3o usava collaborative filtering<\/strong> em bilh\u00f5es de listas de reprodu\u00e7\u00e3o criadas por usu\u00e1rios, identificando aqueles usu\u00e1rios que, assim como voc\u00ea, ouviam x e tamb\u00e9m ouviam y \u2014 uma faixa que voc\u00ea ainda n\u00e3o havia descoberto no Spotify.<\/p>\n\n\n\n

Os engenheiros apresentaram a ideia ao product manager<\/strong> e ao product designer<\/strong>, e eles iniciaram a colabora\u00e7\u00e3o multifuncional entre produto, design e engenharia para avaliar os poss\u00edveis riscos do produto.<\/p>\n\n\n\n\n \n<\/a>\n\n\n\n

Como Voc\u00ea Constr\u00f3i \u2013 Entrega de Produto<\/strong><\/p>\n\n\n\n

Em 2006, no in\u00edcio do Spotify, a abordagem padr\u00e3o Waterfall<\/em> para o desenvolvimento de produtos de software envolvia meses de codifica\u00e7\u00e3o, predominantemente guiados por partes interessadas internas, antes de lan\u00e7ar o produto para o mundo.<\/p>\n\n\n\n

Uma desvantagem \u00f3bvia dessa abordagem era o feedback escasso dos usu\u00e1rios at\u00e9 o final do projeto, resultando em um produto mais reflexo das prefer\u00eancias das partes interessadas internas, com a esperan\u00e7a otimista de que tamb\u00e9m ressoasse com os potenciais clientes.<\/p>\n\n\n\n

Reconhecendo essas limita\u00e7\u00f5es, os l\u00edderes e as equipes de produto do Spotify perceberam logo no in\u00edcio da jornada que uma abordagem melhor para descobrir e entregar produtos era necess\u00e1ria.<\/p>\n\n\n\n

Consequentemente, foram feitos investimentos substanciais para apoiar a experimenta\u00e7\u00e3o necess\u00e1ria e fornecer \u00e0s equipes de produto acesso a dados cruciais de comportamento dos usu\u00e1rios. Isso incluiu a infraestrutura para instrumenta\u00e7\u00e3o, telemetry<\/em>, monitoramento e relat\u00f3rios. A empresa tamb\u00e9m investiu fortemente em infraestrutura de implanta\u00e7\u00e3o, especialmente para A\/B testing<\/strong>, com uma equipe de produto dedicada \u00e0 plataforma focada em habilitar esses testes com dados ao vivo.<\/p>\n\n\n\n

O Spotify tamb\u00e9m foi um defensor precoce de releases<\/em> pequenos, frequentes e desacoplados, investindo nas ferramentas e t\u00e9cnicas de Continuous Delivery<\/strong>.<\/p>\n\n\n\n

Como as habilidades do Spotify em entrega de produtos s\u00e3o bem conhecidas na ind\u00fastria, n\u00e3o vamos gastar muito tempo nisso aqui. No entanto, \u00e9 fundamental perceber que esses investimentos s\u00e3o o que capacita as equipes de produto do Spotify a entregar outcomes<\/strong>, e n\u00e3o apenas output<\/strong>.<\/p>\n\n\n\n

Essa infraestrutura de entrega abriu caminho para o Discover Weekly<\/strong> e in\u00fameras outras inova\u00e7\u00f5es do Spotify, grandes e pequenas.<\/p>\n\n\n\n

Os Resultados<\/strong><\/p>\n\n\n\n

Poucos meses depois, o Discover Weekly estava pronto para sua estreia global, sendo lan\u00e7ado para todos os usu\u00e1rios do Spotify.<\/p>\n\n\n\n

O release<\/em> foi um sucesso retumbante, com 1 bilh\u00e3o de faixas transmitidas nas primeiras 10 semanas. Notavelmente, 71% dos ouvintes adicionaram pelo menos uma m\u00fasica \u00e0s suas playlists pessoais, e 60% daqueles que experimentaram o Discover Weekly continuaram a ouvir cinco ou mais faixas.<\/p>\n\n\n\n

O burburinho online foi igualmente entusi\u00e1stico, com usu\u00e1rios compartilhando rea\u00e7\u00f5es emocionais como: “Fiquei muito animado e comecei a chorar um pouco porque percebi que amanh\u00e3 \u00e9 segunda-feira, e o Spotify est\u00e1 me fazendo um novo Discover Weekly.”<\/p>\n\n\n\n\n \n<\/a>\n\n\n\n

Equipes de Produto e Cultura de Produto<\/strong><\/p>\n\n\n\n

Esperamos que essa an\u00e1lise sobre o trabalho de produto no Spotify ajude a esclarecer o poder de equipes de produto fortes, lideradas por l\u00edderes de produto fortes, trabalhando no product model<\/strong>.<\/p>\n\n\n\n

Embora o Spotify seja bem conhecido por suas equipes de produto capacitadas, esse exemplo mostra o que esse conceito realmente significa na pr\u00e1tica. Requer l\u00edderes de produto fortes que forne\u00e7am o contexto estrat\u00e9gico \u2013 especialmente as dif\u00edceis decis\u00f5es de estrat\u00e9gia de produto \u2013 e saibam como criar o ambiente necess\u00e1rio para que as equipes de produto fa\u00e7am um bom trabalho.<\/p>\n\n\n\n

O cofundador Daniel acreditava em uma estrutura onde a responsabilidade pelos resultados de neg\u00f3cios, alinhada com uma compreens\u00e3o clara da estrat\u00e9gia de produto, utilizando experimenta\u00e7\u00e3o orientada por dados, produziria os melhores resultados \u2013 mesmo que as ideias n\u00e3o fossem dele.<\/p>\n\n\n\n

Uma das raz\u00f5es pelas quais esse exemplo do Discover Weekly \u00e9 t\u00e3o ilustrativo \u00e9 porque Daniel foi abertamente c\u00e9tico em rela\u00e7\u00e3o \u00e0 ideia do produto e compartilhou suas preocupa\u00e7\u00f5es com a equipe de produto. Mas, para seu cr\u00e9dito, ele deu \u00e0 equipe um problema a ser resolvido e ent\u00e3o permitiu que o trabalho prosseguisse.<\/p>\n\n\n\n

E para o cr\u00e9dito da equipe de produto, eles viram o potencial da tecnologia capacitadora e se encarregaram de enfrentar os riscos do produto de forma respons\u00e1vel e eficaz. Isso est\u00e1 por tr\u00e1s de muitas inova\u00e7\u00f5es movidas pela tecnologia, e \u00e9 isso que realmente significa equipes de produto capacitadas.<\/p>\n\n\n\n

Como outras empresas que seguem o product model<\/strong>, o Spotify reconhece que as ideias mais inovadoras \u2013 aquelas que realmente ressoam com os clientes \u2013 muitas vezes surgem daqueles que interagem com a tecnologia capacitadora diariamente: os engenheiros. Eles est\u00e3o em uma posi\u00e7\u00e3o \u00fanica para identificar novas possibilidades.<\/p>\n\n\n\n

Grandes l\u00edderes entendem a necessidade de criar um ambiente onde equipes de produto capacitadas possam exercer sua criatividade, descobrindo e entregando solu\u00e7\u00f5es inovadoras que n\u00e3o s\u00f3 os clientes amam, mas tamb\u00e9m impulsionam o sucesso dos neg\u00f3cios.<\/p>\n\n\n\n

Aprendendo Mais<\/strong><\/p>\n\n\n\n

No ano passado, a convite da Crisp, Marty fez uma palestra relacionada voltada principalmente para coaches de produto e Agile<\/em>, tentando explicar as diferentes abordagens para scaling<\/strong> e por que o Spotify prosperou enquanto muitos outros falharam. Voc\u00ea pode ver a palestra aqui<\/a>.<\/p>\n\n\n\n

E claro, eu falei longamente sobre o Spotify e sua cultura. Aqui est\u00e1 uma das minhas palestras mais populares, e eu tamb\u00e9m ensino um curso sobre o tema.<\/p>\n\n\n\n

\n