O planos para os meus 3 primeiros meses de produto

15 de dezembro de 2019 • um papo de 3min sobre produto

Recebi o desafio (e põe desafio aqui rs) de introduzir o mindset de produto do zero em uma startup. Então estruturei um plano de 3 meses para conseguir aprender bem rápido e entender como deveria ser o inicio dessa equipe de produto. A ideia era pivotar o máximo possível sem dar a sensação de "começar do zero".

Como estamos hoje

Atualmente o nosso processo de desenvolvimento da aplicação acontece em 3 etapas:

  • Ideação
  • Especificação
  • Desenvolvimento

Um problema que comumente tem acontecido é a dificuldade de conclusão das tarefas. Nos últimos ciclos tivemos diversas tasks que pararam nos 70% e se arrastaram assim por diversos ciclos.

O que podemos testar aqui?

  • MVP do MVP

    Utilizar esses 70% para ja testar a proposta de valor. Para isso o propósito da task precisa ser claro desde o início do processo. "O que estamos melhorando com isso?" deve ser claro para todos os envolvidos do processo, assim garantiremos que já nos 10% de conclusão temos o valor necessário atrelado e, caso ocorra esse gargalo no processo, isso não impacte negativamente no produto.

    Frameworks sugeridos:

    • Metrificar o avanço em cada daily
  • Medir as causas

    A task foi interrompida pois outra coisa "importante" surgiu? Sabemos pouco sobre os outros 30% da task? A task se tornou maior do que o planejado? O que era importante antes hoje não é mais?

    Medindo as causas desses bloqueios ciclicamente e propondo soluções para os próximos passos tendemos a melhorar o nosso fluxo de trabalho.

    Frameworks sugeridos:

    • Trello + Cohort
    • Categorizar as causas
    • Tendência do Lead Time
    • CFD

Outros pontos importantes sobre o processo atual

Partimos das ideias, as assumimos verdades e desenvolvemos. Sabemos pouco sobre como isso vai solucionar o problema, não atrelamos o desenvolvimento ao problema e também não medimos o impacto pós deploy.

tristevida

Dois mindsets podem ser agregados ao nosso processo para trazer mais certeza durante ele

Discovery

  • Board de ideias

    Um documento de problemas a serem resolvidos.

    Li recentemente um case do RD sobre como criaram um "board comunitário" de feedbacks que poderia funcionar bem para gente na criação do board de discovery:

  • Interações

    Ciclos de descoberta dentro do board.

    • Quais os problemas mais recorrentes?
    • O que está mais atrelado aos OKRs da empresa?
    • Que áreas são beneficiadas?
    • Que oportunidades temos aqui?

    E design sprints para validar possíveis soluções.

    • Mockups
    • Pesquisas
    • Apresentações
  • Feedbacks públicos

    Feedbacks para os envolvidos com a descrição da task e todas as equipes envolvidas com o produto. Esses feedbacks são tanto do problema, quanto das validações e do que foi aprendido.

    Desses feedbacks surgem efetivamente as tasks para o backlog de desenvolvimento.

Métricas do produto

  • KPIs sobre as soluções

    Como saber se a solução implementada realmente resolve o problema inicial? Definindo, desde o momento de discovery, as KPIs que queremos medir e mensurá-las (e também otimiza-las) após o lançamento.

    É legal definir também significados para esses dados. O que significa um bom resultado? Uma task a ser revista? Um mau resultado? Em qual delta de tempo? Esses significados podem ser visto:

    Do ponto de vista do usuário

    • Diminuir a taxa de tickets do suporte sobre determinado assunto em X% no período
    • Aumentar o LTV em X% nos próximos Z meses.

    Do nosso ponto de vista

    • Diminuir o CAC de clientes com Z ticket médio em X%
    • Aumentar a curva de cohort de clientes performance em X%
  • KPIs de produto

    Será que estamos evoluindo no ponto de vista de negócio? Como estava o nosso produto com relação ao Benchmark no último trimestre em relação a hoje?

    A interação constante nas métricas globais (que vão além do faturamento) também é uma forma de deixar todos os envolvidos com a solução engajados com a evolução e também comprometidos com com os déficits.

    Posso sinalizar a implementação dos Casos como um bom exemplo. Melhoramos a comunicação do cliente com a mesa, agregamos valor de engenharia... Mas diminuímos consideravelmente a performance do suporte.

    Quais outros casos assim acontecem e não percebemos por terem uma escala menor ou um impacto menos geométrico? Analisar variáveis globais e fazer comparativos periódicos pode nos ajudar a ver.

me conta o que achou:

hey,
duvido você
compartilhar

twitterlinkedinemailcopiar link

all
design/produto
front-enddados
música/back-end