A coisa mais importante que o Dropbox fez para escalar o gerenciamento de produtos

Sean Lynch 10 de janeiro de 2017

Essas opiniões são inteiramente minhas, destiladas da minha experiência no Dropbox em 2012–2015, bem como trabalhando com outras startups. Desde há alguns anos, tenho a certeza que o Dropbox e o seu processo parecem um pouco diferentes agora.

Eu passei muito tempo em 2016 fazendo mentoria, consultoria e consultoria. Muitas conversas giraram em torno da criação de equipes de gerenciamento de produtos e, por meio dessas conversas, tenho que refletir sobre as lições que aprendi com os papéis passados das MPs. Algumas dessas lições são de senso comum e compartilhadas na maioria das empresas de tecnologia com as quais conversei. Outros não são tão óbvios.

Para mim, uma das experiências mais valiosas foi ver o Dropbox rapidamente escalar (tanto em clientes quanto em tamanho de funcionário) e testemunhar todos os problemas que surgem à medida que esses números aumentam. Hoje, quero falar sobre o framework que desenvolvemos para manter a empresa em crescimento na mesma página, através do processo de desenvolvimento de produtos.

Primeiro, algum contexto

Durante a maior parte do meu tempo no Dropbox, a equipe de produtos foi liderada por nosso co-fundador e CTO. Ele estava profundamente envolvido com todos os aspectos do desenvolvimento de produtos, incluindo engenharia e design, bem como gerenciamento de produtos. Nos primeiros dias, ele reviu quase todas as decisões de produto. Dizer que ele estava ocupado é um eufemismo, mas funcionou quando nossa equipe era relativamente pequena.

Mas a empresa começou a crescer como um louco e começamos a trabalhar em muito mais projetos em paralelo. No início de 2014, tivemos um problema.

Há apenas tantas horas em um dia e todo o tempo do nosso CTO estava cheio. Era difícil para os PMs conseguirem tempo com ele para o feedback e as aprovações de que precisavam. As coisas começaram a parecer lentas e depois travadas. Não estava claro quando ele deveria estar envolvido, o que ele realmente precisava rever e qual feedback seria útil. PMs começaram a tentar contornar o processo, e a liderança ficou fora de sincronia com o que as equipes estavam fazendo. Todos ficaram frustrados.

Para resolver o problema, o colega PM Anand Subramani, propôs uma estrutura simples para rotular as fases do ciclo de vida de um projeto. Cada uma das três fases teve uma revisão associada a ele, projetada para responder a uma pergunta específica:

Fase 0 – Qual é o problema que estamos resolvendo? Por que vale a pena resolver?

Fase 1 – Como vamos resolver esse problema?

Fase 2 – Como é a nossa solução?

Para ser claro, não estou defendendo que essa estrutura específica é a perfeita para cada projeto ou empresa, e também não fomos dogmáticos em segui-la ao pé da letra. Houve momentos em que as equipes combinavam a Fase 0 e a Fase 1 para projetos menores ou realizavam várias revisões na Fase 2 à medida que se aproximavam de um lançamento. Também há valor para uma iteração pós-lançamento para revisar metas e procurar oportunidades para melhorar.

O valor não estava nesta encarnação específica. Em vez disso, a parte mais valiosa da estrutura era três características sutis, mas críticas, que você deve ter em mente ao definir a sua:

1. Esclareceu as perguntas certas para perguntar e feedback para fornecer a um determinado projeto.

Um dos principais valores do Dropbox é Suar os detalhes . Ao analisar um produto, há muitos detalhes a serem abordados e, dependendo de o produto estar em desenvolvimento, eles podem não ser os corretos. A estrutura definia expectativas compartilhadas sobre o que focar, a qualquer momento.

Por exemplo, antes dessa estrutura, era comum fazer perguntas sobre o fraseado de texto em wireframes. Ter a estrutura em vigor tornou óbvio quando um projeto era muito cedo para esse tipo de feedback, mas também dava conforto à liderança de que o projeto retornaria para esse nível de feedback quando essa fase fosse alcançada.

Quase imediatamente após a sua introdução, os revisores começaram a se auto-criticar dizendo “Opa, estou dando feedback da fase 2 em uma fase 0, minha má”.

2. Separar a obtenção de acordo sobre o problema de obter um acordo sobre a solução.

É difícil para mim exagerar a importância de obter um acordo sobre o problema que você está tentando resolver antes de começar a trabalhar na solução, particularmente quando houver muitos interessados em diferentes partes do negócio.

Sem isso, era comum ver os projetos se atrasarem no desenvolvimento, apenas para desacelerar o processo de desenvolvimento à medida que as partes interessadas discordam sobre se o produto que estava sendo construído era realmente a coisa certa a ser lançada. Isso porque as partes interessadas não estavam na mesma página sobre qual era o problema real.

Ao definir isso e obter um acordo antes de prosseguir, as equipes poderiam avançar com muito mais confiança de que estavam trabalhando na coisa certa.

3. Tão simples que poderia ser adotado por toda a empresa.

A lição principal aqui é como a comunicação concisa e consistente é importante para que uma equipe grande trabalhe de forma eficiente em conjunto.

A terminologia compartilhada permitiu que todos na empresa entendessem imediatamente onde um projeto estava em seu ciclo de vida. A engenharia sabia o quanto e com que urgência uma equipe precisava de pessoal, o suporte sabia quando um projeto começaria a impactar os clientes e a equipe de marketing sabia quando era cedo demais para montar material de marketing porque ainda haveria muita mudança no projeto.

Na verdade, na verdade, tentamos fazer um novo design dessa estrutura para resolver alguns problemas (por exemplo: pode haver uma fase adicional para a iteração de lançamento ou pós-lançamento). A primeira tentativa de redesenhar introduziu novos conceitos, o que dificultou a compreensão. A complexidade adicional impediu que o novo design substituísse a primeira definição.

Texto original en inglés.