Usando a abordagem Working Backwards

Durante minha carreira de gerente de produto sempre procurei abordagens diferentes pra facilitar a vida de todos (stakeholders, desenvolvedores e etc.). E então acabei conhecendo uma abordagem chamada “working backwards”, que é muito utilizada na Amazon. Não sei se eles inventaram o método, mas com certeza foram os que popularizaram.

O desenvolvimento de um produto deve sempre começar com as necessidades e benefícios que pode ser gerado para o cliente

A ideia principal de qualquer boa especificação é sempre focar no cliente, fazendo com que a feature seja totalmente centrada nele. Dai surgiu a ideia de especificar ao contrário. Esse método pode ser usado para tomar qualquer decisão específica de um produto, mas a eficácia da técnica vai variar do contexto que você está inserido — se for um contexto mais técnico que envolva integrações talvez não faça tanto sentido.

Mas, mesmo assim, recomendo usar a abordagem para o desenvolvimento de novas funcionalidades ou produtos que vão ser criados do zero.

Por onde começar?

Então se você, gerente de produto, vai lançar algo novo o que você faz por último? Escreve uma release pra divulgar o que foi feito e quando vai ser lançado. Então, utilizando a abordagem working backwards, é a partir da release que você deve começar. O público alvo dessa release vai depender do contexto que você está inserido — pode ser uma release interna caso seja uma funcionalidade voltada para os seus colegas de trabalho, ou pode ser uma release externa que você pode testar com alguns usuários para ter um feedback imediato.

Essas releases devem ser focados no problema central do cliente (interno ou externo). Nela você deve mostrar como as soluções atuais não suprem o problema e como o novo produto ou funcionalidade vai resolver isso. De preferência coloque algumas screenshots que pareçam com a funcionalidade final — crie mockups bem reais.

Depois de montar a release

A dinâmica é simples. Se os benefícios não parecerem interessantes para os clientes, então talvez não seja mesmo. É claro que isso vai dar apenas indícios, não quer dizer que a falha da release seja uma resposta definitiva. Por isso você deve continuar iterando essa release até que essas novas funcionalidades pareçam benefícios reais e encante todo mundo.

Exemplo de uma boa release Como escrever uma boa release:

  • Título — Nome do produto ou funcionalidade escrita de uma maneira que o cliente possa entender assim que ele bater o olho no título.
  • Sub-título — Descreva os usuários que vão usar a funcionalidade e os benefícios que ela vai oferecer. Tente colocar em uma sentença logo abaixo do título.
  • Resumo — Faça um resumo do produto/funcionalidade ressaltando os benefícios. Assuma que o leitor não vai ler nada além disso. Então esse parágrafo tem que ser impecável.
  • Problema — Descreva o problema que você está resolvendo.
  • Solução — Descreva, de uma maneira elegante, como você está resolvendo esse problema através dessa funcionalidade ou produto.
  • Citação de alguém da empresa — Uma citação rápida de você ou alguém importante na sua empresa. Ressaltando as vantagens.
  • Como começar a usar a nova funcionalidade — Descreva como é simples começar a usar.
  • Citação de algum cliente — Crie uma citação hipotética de algum usuário que usou a funcionalidade e ficou feliz
  • Resumo final e Call to Action — Considerações finais rápidas e um botão bem grande como Call to Action
Dicas
  • Se o release tiver mais de uma página ele provavelmente é muito grande
  • Faça 3–4 sentenças por parágrafo
  • É uma boa prática incluir um FAQ que responda todas as dúvidas de negócio para que a release seja focada no usuário final
  • Se a release é difícil de escrever, provavelmente é porque o produto não vai ser bom
  • Escreva a release de uma maneira simples que até sua mãe consiga entender. Sem “tecniquês”
  • Vai ajudar se você conversar com alguns clientes antes de fazer essa release
Ok. Release feita. E agora?

Após começar o desenvolvimento do projeto, depois de ter definido, testado e iterado a release, ela pode servir como um guia. Com ela a equipe vai poder sempre perguntar “Estamos criando coisas que foram definidas na release?” E isso é uma pergunta muito importante! Afinal, muitas equipes costumam perder tempo criando software que não está definido ou não possui um objetivo claro (overbuilding). Caso isso aconteça, a equipe precisa sentar e entender porque isso está acontecendo.

Assim a equipe consegue se manter focada em criar coisas que de fato vão beneficiar os usuários e não criar coisas que demoram muito e/ou não estavam previamente definidas.

No capitulo 11 do livro Getting Real da 37 Signals você pode ver mais detalhes sobre como escrever uma release. Isso com certeza vai ajudar você no processo de working backwards.

Acredito que escrever uma release focando nos benefícios dos usuários é um excelente exercício pra qualquer gerente de produto. Essa abordagem inclusive serve pra se manter alinhado com stakeholders e até mesmo com os clientes. Você já usou essa técnica? Não gostou e prefere outra? Comente pra gente discutir.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>