Skip to main content

Categoria: Produto

É novo em um time, que tal usar a matriz RACI?

gabimiza Deixe um comentário

É novo em um time e não entendeu ainda o que você é responsável por entregar e o que cabe a outras pessoas? Que tal usar a matriz RACI e levar clareza para o contexto? 

Sempre quando entramos em uma empresa existe um desconforto inicial, por isso é importante alinhar o que cabe a cada um. Em uma situação recente, sugeri de criarmos a matriz RACI para as funções que existem no time (Product Manager, Product Owner, Business Analyst, Scrum Master e Tech Lead). A seguir explico um pouco como essa ferramenta funciona e suas vantagens em utilizar. No final, deixo também um link de uma planilha modelo para você aplicar aí no seu dia a dia (ah, não esquece de duplicar para o seu Google Drive antes de utilizar)🚀

Utilizada tanto na gestão de projetos quanto na dinâmica de times, essa ferramenta é essencial para delimitar e formalizar as funções de cada profissional envolvido no processo. Imagine ter em um único lugar as informações cruciais para a execução das tarefas, de forma concisa e didática, facilitando a comunicação dentro do seu time? Pois é, essa ferramenta serve exatamente para isso! 🚀

O que é a matriz RACI?

A Matriz RACI propõe 4 atribuições, representadas pelas letras do acrônimo:

🔸 R – Responsible (responsável)

🔸 A – Accountable (autoridade)

🔸 C – Consulted (consultado)

🔸 I – Informed (informado)

Cada letra reflete um papel vital desempenhado por cada membro da equipe. 

É importante ressaltar que não existe certo e errado para as tarefas e suas classificações, cada empresa tem um jeito de operar, mas claro que existem recomendações, como por exemplo: a gestão do backlog ser uma responsabilidade do Product Owner e em uma mudança no produto ele deve ser autoridade, ou seja, vai ser quem bate o martelo final.

Quais as vantagens em usar?

Destaco também algumas vantagens em utilizar a Matriz RACI:

1️⃣ Melhora na comunicação

2️⃣ Alinhamento de expectativas

3️⃣ Redução do risco de retrabalho

4️⃣ Redução da sobrecarga de trabalho

5️⃣ Maior autonomia dos colaboradores

Link para o template (não esquece de duplicar para o seu Google Drive antes de utilizar):

https://docs.google.com/spreadsheets/d/1lecBX1Q9xYtyhk4VQURnojxOhY3N50gU/edit?usp=sharing&ouid=114501598657194175582&rtpof=true&sd=true

E aí, curtiu essa técnica, já usou? Me conta aí nos comentários  ✨ 

Comecei na área de produtos agora, por onde começar?

gabimiza Deixe um comentário

As vezes algumas pessoas me procuram pois começam a atuar como PO, PM, ou analista de produtos e se sentem perdidas no meio de tanta coisa para aprender, separei algumas dicas que costumo passar:

1️⃣Comece pelo começo, parece besteira, mas não é. São muitos conteúdos, vídeos, podcasts, livros, artigos, etc. por isso, priorize o que é básico para a função, procure estudar sobre: 

  • Área de negócio da empresa e o produto onde está atuando;
  • Gestão do backlog;
  • Como escrever boas histórias de usuário;
  • Técnicas de priorização de itens;
  • Discovery e refinamento;
  • Framework ágil, sugiro o Scrum para começar.

2️⃣Além disso, sempre sugiro que sigam em redes sociais, outros profissionais que são referências na área e que dão dicas sobre o assunto. Siga também  comunidades que abordem o tema (exemplo: mulheres agilistas, mulheres de produto, product gurus, product oversee).

3️⃣Se ainda estiver insegura, procure uma mentoria, existem programas anuais gratuitos nas comunidades que citei anteriormente, também recomendo a Mentorellas. Ter alguém para guiar no começo ajuda bastante a ter foco.

4️⃣E não se desespere, dê tempo ao tempo, aos poucos o conhecimento aprendido poderá ser aplicado no seu dia a dia.

Acredito que seguindo esses passos, você conseguirá ser mais efetivo na evolução de sua carreira. 

E aí, curtiu esse conteúdo? Que tal compartilhar com alguém que está vivendo esse momento?  🙌🏻

Os estágios de evolução do Product Owner

gabimiza Deixe um comentário

Já parou para pensar que existem estágios de evolução para a função do Product Owner, ou o PO? Veja abaixo quais são e me conta o que achou.

A evolução

Os estágios são incrementais ou seja, é a soma do anterior com o atual, as características e habilidades são acrescentadas. Esses estágios foram concebidos com base na experiência e percepção dos profissionais que atuam com Scrum em diferentes partes do mundo.

O escritor

Comumente acontece em adoções iniciais do Scrum, que passam a usar o padrão de história de usuário. Por possuir baixa influência sobre o negócio, precisa do marketing, comercial, gerente de produtos, etc para responder perguntas. É comum verificar atrasos e desperdícios nos times que atuam dessa forma.

O proxy

Possui forte habilidade de comunicação e com isso tem maior conexão com a área de negócio. Em alguns casos, pode influenciar na prioridade do itens de backlog. Ainda encontra dificuldades em esclarecer as dúvidas do time, pois recebe as demandas e nos melhores cenários, trabalha no detalhamento dela ganhando um pouco mais de propriedade.

O representante de negócios

Neste estágio o PO geralmente é alguém que representa o negócio, uma clara evolução do proxy. Este perfil conta com um domínio e acesso muito mais abrangente ao negócio, mas ainda falta a autonomia necessária para a efetiva gestão do produto. Existe uma colaboração mais ampla. entre TI e negócio.

O patrocinador

Possui influência e voz ativa para tomar decisões (dada pela área de negócio), tanto no produto quanto na gestão financeira. Auxilia no andamento do fluxo de trabalho, menos interrupções são causadas por falta de entendimento e de decisões de negócio. Proporciona uma certa segurança para a tomada de decisões do time.

O empreendedor

Totalmente responsável pelo orçamento do produto e pelas funcionalidades. Seu trabalho é criar Valor de Negócio para os clientes. Pode delegar algumas atividades de baixo valor agregado para outros profissionais, tais como: escrever histórias, critérios de aceite e etc. 

Conclusão:

É importante lembrar que por definição, um Product Owner não deveria ser somente um escritor de história de usuário e critérios de aceite, e muito menos o proxy entre negócio e desenvolvimento. Porém, isso ainda é visto em empresas, devido a gestão, cultura, perfil, etc.

Você deve se perguntar, mas e o Product Manager (PM)? Para mim é a mesma coisa e vai depender da empresa. Em algumas delas, onde o scrum não é adotado, tem o papel do PM que nada mais é, ou deveria ser, o mesmo que o PO empreendedor. Em outras que usam scrum, ou agilidade em larga escala, ele fica um nível acima cuidando de vários produtos a nível estratégico e também é responsável por guiar as entregas dos POs e times.

Fontes:

scrum.org

metodoagil.com

cafecomscrum.com

O equilíbrio das habilidades do product manager – skills de produto e skills gerais

gabimiza Deixe um comentário

Lendo um pouco mais sobre características ideais para um product manager, me deparei com o artigo do Roman Pichler, disponível no Medium. Destaco a questão de que devem ser profissionais T-shapped, com habilidades no produto e habilidades gerais, de liderança, estratégias e técnicas. 

As habilidades específicas do produto, podem ser de único produto ou portfólio. Isso demanda um conhecimento profundo das necessidades dos usuários, competidores, modelo de negócio e tendências do mercado, além do conhecimento das features, jornadas, objetivos, proposta de valor etc, do próprio produto. As skills específicas do produto são cruciais mas, por mais importantes que sejam, não são suficientes.

As habilidades gerais (estratégicas e técnicas), te ajudam a resolver desafios na gestão de produtos bem como te permite mais flexibilidade para atuar em diversas áreas de negócios. Alguns exemplos: análise de dados e feedbacks fornecidos; construção de KPIs ou OKRs; segmentação de mercado, proposição de valor do produto, validação de estratégia, priorização de backlog, etc. 

Fonte: https://medium.com/agileinsider/the-t-shaped-product-manager-c3e4587e5b84

Qual a principal diferença entre POC e MVP?

gabimiza Deixe um comentário

Esses dias me perguntaram qual seria a principal diferença entre POC e MVP, respondi que o MVP (Minimum Viable Product) seria uma versão utilizável do produto com um número mínimo de funcionalidades, enquanto o POC (Proof of Concept) estaria em um estágio anterior, sendo uma prova de conceito interna da equipe, para o verificar a viabilidade técnica. 

Resolvi pesquisar melhor sobre o assunto para me aprofundar e separei algumas coisas interessantes:

  • A POC mitiga os riscos técnicos, já o MVP mitiga os riscos de negócio;
  • Startups normalmente começam com a POC para convencer os stakeholders sobre o real valor da solução a ser desenvolvida;
  • A melhor forma de criar uma POC é no estilo de hackathon;
  • Algumas vantagens do MVP são ter feedback dos usuários (early-adopters) antes do produto oficialmente lançado, reduzir custos/tempo e atrair investidores;
  • Alguns benefícios da POC são atrair investidores iniciais, descobrir se as pessoas precisam do seu produto e escolher a tecnologia mais adequada antes do desenvolvimento;
  • Existe ainda a prototipação, que também é rápida como a POC e permite visualizar como o usuário final irá interagir com o produto, entendendo seus fluxos e recursos necessários.
  • Não necessariamente é preciso passar por todos esses passos, cabe avaliar em qual o momento você se encontra, tanto a nível de produto como na equipe e empresa.

Fontes:

https://www.plainconcepts.com/mvp-poc-differences-use-cases/ 

https://thinkingthrough.substack.com/p/what-we-get-wrong-about-proof-of 

https://keytotech.com/2020/05/15/poc-prototype-mvp-difference/ 

https://spdload.com/blog/poc-vs-prototype-vs-mvp/