Módulo 5

EXECUÇÃO DO
DIA A DIA
5.1
Especificações de
requerimentos e
rollout

RAPHAEL FARINAZZO
Release - Recapitulando:

1. Uma Release é um pacote entregável que gera valor para os

usuários que tiverem acesso ao que você entregou.

2. É diferente de entregas de tarefas técnicas, de engenharia.

3. Uma Release é a tangibilização do que está previsto na sua

Estratégia e no seu Roadmap de Produto.
Como a release se liga à estratégia?

Visão

Estratégia

Roadmap
Hipóteses, problemas
e oportunidades
Itens que você ainda
quer gerenciar
Backlog Releases
Ideias e hipóteses
que ficaram para trás
AGENDA DESTE TÓPICO

1.
2. 3. 4.
Working
Specs Pós-release Lançamento
Backward
Como trabalhar “de trás para frente”?

O conceito surge na Amazon

● Começar pelo Press Release: um anúncio para a imprensa!

Ou, com uma boa variação, a Customer Letter!

Pode evoluir para um FAQ (Perguntas Mais Frequentes)

Iterar sobre Press Release x Iterar sobre software / código

Exemplo de
Press Release
Exemplo real da AWS
<< Back
Amazon Web Services Launches

SEATTLE - (BUSINESS WIRE) - March 14, 2006 - S3 Provides application Programming Interface for Highly
Scalable, Low Latency Storage at Very Low Costs.

Amazon Web Services today announced “Amazon S3(™)”, a simples storage service that offers software
developers a highly scalable, reliable and low latency data storage infra at very low costs. Amazon S3 is
available today at http://aws.amazon.com/s3.

Amazon S3 is storage for the Internet. It's designed to make web-scale computing easier for developers.
Amazon S3 provides a simples web services interface that can be used to store and retrieve any amount
of data , at any time, from anywhere on the web. It gives any developer access the same highly scalable,
reliable, fast, inexpensive data storage infrastructure that Amazon uses to run its own global network of
web sites. The service aims to maximize benefits of scale and to pass those benefits on to developers.
 ● Alinhamento e
Inspiração para o time
● Deixa clara a visão do
Benefícios e que será lançado
quando usar ● Excelente para
entregas maiores: nova
feature, por exemplo.
● Boa matéria-prima para
materiais de
lançamento
Dicas para um bom Press Release

1. Evite descrever funcionalidades e soluções que ainda não foram

pensadas pelo time.
2. Escreva a primeira versão, mas itere com todo o time até chegar à
definitiva.
3. Envolva pessoas de outras áreas, principalmente (Product) Marketing.
4. Apesar de existirem templates, coloque seu storytelling para funcionar!
No que você está trabalhando
neste momento? Como
escrever esse Press Release?
Variação: Carta do Cliente

Ideal para evitar Press Releases muito focados em solução

Escreva como se fosse um cliente muito feliz com a novidade

Descreva como você se sente

Explique no que a sua vida melhorou com a novidade recém-lançada

Customer
Letter
Benefícios

Mais inspiração e alinhamento para o time

Foco maior no problema que está sendo / foi resolvido

Mais empatia pelo cliente que será impactado pela melhoria

Perguntas Mais Frequentes (FAQ)

Explicar alguns detalhes da Release com mais contexto

Exercício de empatia com as dúvidas dos clientes

Antecipar-se às perguntas = diminuir risco

Boa matéria-prima para material educacional (Central de

Ajuda, roteiro para o Suporte etc.)
Opportunity
Assessment
AGENDA DESTE TÓPICO

1.
2. 3. 4.
Working
Specs Pós-release Lançamento
Backward
Histórias: narrativas de valor para o usuário.
Alguns modelos mais usados:

PRD - Product Requirements Document Problema

Histórias de trabalho (Job stories)

Histórias de usuário
Solução
Wireframes / protótipos
 ● Objetivo
● Elevator pitch
● Onde serão feitas as alterações
PRD - Product / melhorias
O que vai mudar, o que será
Requirements ●
feito
Document ● Riscos mapeados
● Resultado esperado
● Outras métricas para
monitorar
Elevator pitch

Para [cliente final],

que [enfrentam tal problema],

Use como recurso para:
o [produto]
➔ Visão clara
é [tal coisa] ➔ Alinhamento
➔ Foco
que visa [entregar tal benefício].

Diferente da [alternativa],

nosso produto [tem tal diferencial].

Nome da Iniciativa Em Estudo

ELEVATOR STATEMENT (Estudo do problema)

Para empresas que ... tem dificuldade de..., o Contratação Online é uma …... que visa ….. Diferentemente da … que …. nós …. .

BENEFÍCIOS O QUE FAREMOS (Plano de release)

- ….

PARA DAR CERTO PRECISAMOS

RESULTADO ESPERADO (Projeção) CUSTO (Cronograma)

Revenue: R$ XXX X meses

COMO VAMOS MEDIR

O QUE PODE DAR ERRADO?
- % Share
- #
PRD simples
Desdobramentos no Kanban:
Problema Solução
Desdobramentos no Kanban:
Problema Solução

Cada um poderia ser uma release?

Histórias de Usuário
Como [usuário / persona],
eu quero [fazer tal coisa],
para que eu [obtenha tal resultado].
Use como recurso para:
➔ Manter o foco na persona
➔ Clarificar o resultado esperado
➔ Dar margem para retornar ao
problema e resolvê-lo de outra forma
Histórias de Usuário
Características de uma boa user story

Invest
Antes de entrar em Job Stories

Clayton Christensen + Alan Klement: jobs como progressos em

circunstâncias determinadas

Como as coisas são -> progresso -> como eu gostaria que as coisas fossem

Teoria conceitual para explicar por que as coisas acontecem.

Antes de entrar em Job Stories

Tony Ulwick: jobs como atividades para resolver um problema, com

uma expectativa de resultado

Atividade -> resultado esperado

Acompanha uma metodologia, consultorias etc.

Job Stories

Proposta do Alan Klement

(jobs como progresso).
Crítica às user stories:
Job stories
Quando [tal situação emerge],
eu quero [perseguir tal motivação],
para que eu possa [obter tal
progresso].
Use como recurso para:
➔ Manter o foco no resultado
esperado
➔ Dar contexto às motivações e
expectativas do usuário
➔ Não limitar a solução antes de
começar a desenvolvê-la
Histórias de Usuário
“
O objetivo de usar histórias não é escrever histórias
melhores. O objetivo de desenvolver produto não é fazer
produto.

Jeff Patton
Co-autor do Agile Manifesto!
Autor do “User Story Mapping”.
Wireframes e Protótipos

● Versões “toscas” da solução

● Podem ser navegáveis ou
estáticas
● Baixa fidelidade: inspiracional, o
time ainda vai iterar em cima.
● Alta fidelidade: pouca margem
de alteração em relação ao que
será entregue.
Use como recurso para:
➔ Tangibilizar a visão do que será
entregue
➔ Testar e obter feedback de
usuários a um baixo custo

● Começar com baixa fidelidade e

iterar até perder o sentido.
Wireframes

Fonte: https://www.nngroup.com/articles/wireflows/
AGENDA DESTE TÓPICO

1.
2. 3. 4.
Working
Specs Pós-release Lançamento
Backward
Terminamos a
Release. E agora?
Cerimônias mais comuns:

Entregar o que foi realizado - internamente ou para o cliente.

Retrospectiva, tendo em vista a melhoria contínua do time.

Planejar a próxima Release!

O ideal é que pelo menos alguns poucos usuários já tenham acesso.

Quanto mais demorar para obter feedbacks e medir resultados, maior o risco.
Versões Alpha e Beta
Versões Alpha e Beta
Staged Rollouts / Phased Releases

Google Play (Staged Rollouts) e App Store (Phased Releases)

Disponibilizar apenas para alguns usuários, aleatoriamente

Aumentar o percentual de maneira segura

Mesmo princípio de um Beta

O que observar:

As métricas que você esperava impactar estão se mexendo?

Entreviste os usuários impactados.

Se necessário, planeje uma nova iteração em cima do problema.

Cuidado: pode ser muito cedo para tirar conclusões!

Mesmo que atinja as metas, evite o “launch and forget”.

AGENDA DESTE TÓPICO

1.
2. 3. 4.
Working
Specs Pós-release Lançamento
Backward
Qual a melhor forma de
comunicar os clientes?
Idealmente, você tem alguém de Product
Marketing que:

Participou da escrita do Press Release.

Acompanhou com certa periodicidade a evolução da Release no time.

Opinou nos wireframes e protótipos.

Ajudou a definir nome de funcionalidades e a linha criativa dos textos.

Participou da definição de preço das novidades e/ou alocação em um plano de

assinatura existente.

Por isso, vai ser fácil lançar…!

O básico de lançamentos:

Elabore o plano de lançamento com antecedência. Aproveite Press Release e

outros documentos que garantem inspiração, foco e alinhamento.

Tenha um calendário de lançamentos.

Tenha uma linha de comunicação única para todo o lançamento. De preferência

focada no benefício / resultado principal que a melhoria proporciona.

Teste diferentes canais, online e offline, para descobrir o que funciona mais para
o seu público.

Campanhas segmentadas: cada grupo de clientes pode ter motivações

específicas para conhecer / usar a nova funcionalidade.
Novamente, observar:

As métricas que você esperava impactar estão se mexendo?

Entreviste os usuários impactados.

Se necessário, planeje uma nova iteração em cima do problema.

Cuidado: pode ser muito cedo para tirar conclusões!

Mesmo que atinja as metas, evite o “launch and forget”.

Observar também:

Resultados da campanha de lançamento

Canais com melhor performance

Feedbacks em diferentes canais - mídias sociais, Reclame Aqui etc.

Email de
Lançamentos -
Mailchimp:
Email de
Lançamentos -
Amplitude:
O que vimos
nesta aula?
1. Use o “working backward” para garantir alinhamento em torno da
visão e inspirar seu time a resolver o problema.
2. Conheça e treine as principais técnicas de especificação, mas use o
que tiver sentido para o contexto da sua empresa e seu produto.
3. Nunca abandone algo que foi lançado. Acompanhe as métricas e
feedbacks, no mínimo!
4. Não menospreze a importância de uma campanha de lançamento.
REFERÊNCIAS - Livros

Marty Cagan - Inspired: How to Create Tech Products Customers Love

Clayton M. Christensen - Competing Against Luck: The Story of Innovation and

Customer Choice

Jeff Patton - User Story Mapping: Discover the Whole Story, Build the Right
Product

Geoffrey A. Moore - Crossing the Chasm: Marketing and Selling Disruptive

Products to Mainstream Customers.
REFERÊNCIAS - Artigos

Marty Cagan - The Customer Letter

https://svpg.com/the-customer-letter/

Alan Klement - Replacing The User Story With The Job Story
https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27
 @rfarinazz

MUITO
OBRIGADO!