Roadmap ou OKR?

Um dos artigos mais lidos aqui no blog é “O que é um roadmap?“. Contudo, no início de 2016 eu escrevi sobre como os OKRs estavam substituindo roadmaps na Locaweb. Naquela época, meu entendimento era que, eventualmente, os roadmaps não seriam mais necessários e os OKRs substituiriam roadmaps.

Se esse entendimento é correto, por que meu último artigo no Linkedin foi sobre roadmaps? E por que um dos artigos mais lidos aqui no blog é “O que é um roadmap?“? Roadmaps ainda são úteis? Ou roadmaps estão em extinção, sendo completamente substituídos por OKRs?

roadmap_or_okr_2

Em agosto de 2016, após 11 anos liderando o desenvolvimento e gerenciamento de produtos na Locaweb, decidi mudar para a ContaAzul, uma empresa de Joinville que desenvolve um produto de ERP online, para ajudá-los a escalar sua equipe de desenvolvimento de produtos. Quando cheguei à ContaAzul, percebi que eles também usavam OKRs para toda a empresa, incluindo a equipe de desenvolvimento de produtos. No entanto, além de usar OKR, eles também usam roadmaps e não pareceu possível parar de usar roadmaps e gerenciar todos os esforços de desenvolvimento de produto usando apenas OKRs. Isso me fez refletir se OKR pode realmente substituir roadmaps ou se há circunstâncias em que ambas as ferramentas podem ser usadas em conjunto. Se isso for verdade, quais são essas circunstâncias?

Ao discutir este tópico com pessoas da indústria de desenvolvimento de software, ficou claro para mim que o uso do roadmap ou OKR depende do estágio do ciclo de vida do produto. Eu falei sobre os 4 estágios do ciclo de vida de um produto neste artigo.


lifecycle

4-phases

Conforme descrito no artigo, o ciclo de vida do produto de software tem 4 estágios:

  • Inovação: dos 4 estágios do ciclo de vida de um produto de software, a Inovação é a que provoca a maior quantidade de dúvidas. É também a que mantém a maior quantidade de livros. Qualquer livro sobre inovação e startups é útil quando o seu produto estiver nesta fase. O objetivo principal é criar um produto que atenda problemas e necessidades de um grupo de clientes. Por esta razão, durante esta fase, há apenas um Objetivo, achar o product-market fit e, para medir esse Objetivo, podemos usar os Key Results que demonstram o engajamento e a satisfação do cliente. Na etapa de inovação, devemos usar a estrutura MVP (Minimum Viable Product) de build-measure-learn para alcançar o objetivo de encontrar o product-market fit.
     
  • Crescimento: Na fase de crescimento, quando o produto foi desenvolvido e lançado, devemos nos preocupar com gerir o produto durante o seu crescimento. Uma vez que, durante a fase de inovação, nós construímos um MVP para alcançar nosso Objetivo de encontrar o product-market fit, nosso produto estará bastante incompleto. Por esse motivo devemos ter um roadmap descrevendo quais features vamos construir, qual a motivação para construir cada feature e as métricas que irão nos mostrar que estamos cumprindo a motivação para construir cada feature como descrevi nesse artigo. Motivação é outra palavra para Objetivo e Métricas é o mesmo que Key Results. No estágio de crescimento, devemos usar Roadmaps juntamente com OKR.
     
  • Maturidade: Após o crescimento, vem a maturidade. Nesta fase, nosso produto atingiu seu mercado potencial e conseqüentemente não cresce tão rápido quanto cresceu na fase de crescimento. Quando um produto atinge este estágio, ele possui todos as features necessárias e não há mais necessidade de roadmap. Na fase de Maturidade, devemos usar apenas OKRs para gerenciar o desenvolvimento do produto, pois nesta fase estaremos otimizando o produto para atingir seus Objetivos.
     
  • Fim de vida: Após a maturidade, ou quando o produto é desenvolvido e lançado mas não encontra o product-market fit, vem o cenário conhecido como o fim da vida, ou sunset, de um produto de software. Nesta fase, como na fase de Maturidade, roadmap não é necessário, uma vez que não faz sentido investir em construir quaisquer features adicionais. Se o seu produto atingiu a fase de fim de vida após a fase de maturidade, ele já possui todos as features que precisa ter. Se o seu produto atingiu a fase de fim de vida logo após a fase de Inovação por não ter encontrado o product-market fit, você não deve investir nenhum esforço na construção de quaisquer features adicionais. Na etapa de fim de vida do produto, devemos usar apenas OKRs para gerenciar o desenvolvimento do produto, pois nesta fase o nosso único Objetivo é parar de oferecer o produto.

Por esta razão, fica claro que os OKRs substituem Roadmaps em todas as fases do ciclo de vida do produto, exceto para o estágio de crescimento em que ter um roadmap é muito útil para entender para onde seu produto está indo, ou seja, para entender o futuro do seu produto. No estágio de crescimento, devemos usar Roadmaps e OKRs em conjunto para gerenciar o desenvolvimento do produto.

Uma vez que o estágio de crescimento é a fase mais longa de um produto, normalmente durando anos, os roadmaps serão usados ​​durante um bom período do ciclo de vida do produto e por isso é muito importante entender o que é um roadmap de produtos e como o construir.

A importância da diversidade no sucesso do seu produto

Tenho visto com cada vez mais frequência manifestações sobre diversidade. Não sou muito de assistir TV, mas outro dia acabei vendo um pouco de TV Globo. Peguei o final do Jornal Nacional e o início da novela. No Jornal Nacional uma matéria sobre a PUC de São Paulo inaugurando banheiros unissex, lembrando que PUC = Pontifícia Universidade Católica, ou seja, uma universidade ligada à religião Católica. Em seguida, na novela apareceu uma atriz que estava contando para os pais e familiares que ela nasceu no corpo errado, que ela era um homem que havia nascido num corpo de mulher, ou seja, que ela era transgênero. Em seguida, durante o intervalo, veio a campanha da Globo intitulada “Tudo Começa Pelo Respeito” sobre respeito à identidade de gênero:

Isso é muito bom! Aceitar e respeitar as diferenças é a base para evoluirmos como sociedade e construirmos um futuro cada vez melhor para nós, para nossos filhos e para toda a humanidade.

Quando faltam o respeito e a capacidade de aceitar a diversidade, podem acontecer situações muito ruins, como, por exemplo, pais rejeitando o próprio filho. Fiquei bastante impressionado quando li o relato da Daniela Andrade, consultora sênior da ThoughtWorks, onde ela conta que:

Como fui expulsa da casa dos meus pais, por ser transexual — e aqui eu digo que a primeira grande violência que sofremos é dentro de casa — há muitos anos não tenho parentes com quem contar em momentos de necessidade, todos deram as costas para mim.

Como é possível um pai rejeitar a própria filha? Sou pai e sei como o amor de pai é algo muito intenso, capaz de passar por cima de qualquer problema para podermos sempre ajudar e suportar nossos filhos. Estava conversando outro dia com minha esposa sobre esse relato e sobre a dificuldade das pessoas em aceitarem as diferenças, ao ponto de fazer com que pais rejeitem seus próprios filhos. Foi nesse momento que minha esposa disse uma frase que me marcou. Ela disse que em última instância, todas as pessoas são diferentes. Transgênero, cisgênero, heterosexual, homosexual, bisexual, assexual, negro, branco, amarelo, jovem, adulto, meia-idade, terceira idade, brasileiro, canadense, francês, vietnamita, fluminense, mineiro, paulista, carioca, belo-horizontino, corredor, ciclista, nadador, engenheiro, arquiteto, advogado, quem gosta de música pop, rock, jazz, clássico e assim por diante. Mesmo gêmeos idênticos são diferentes.

Se todas as pessoas são diferentes, aceitar e respeitar as diferenças não é só desejável, é necessário e obrigatório para que possamos viver em sociedade de uma forma mais harmônica e sustentável. São valores que devem ser ensinados para todas as pessoas desde o berço.

E o que diversidade tem a ver com gestão de produtos de software?

Além do importância de aceitar e respeitar as diferenças para ajudar a criar uma sociedade mais harmônica e sustentável, a diversidade irá ajudar a criar produtos de software cada vez melhores por dois motivos:

  1. Diversidade traz novos pontos de vista. Ter um time de desenvolvimento de produtos mais diverso traz novos pontos de vista e novas maneiras de pensar, o que ajudará a desenvolver um produto melhor. Não é à toa que o time de desenvolvimento de produtos é composto de engenheiros de software, designers de experiência do usuário e gestores de produto. Cada um tem visões diferentes do que é um bom produto e essas diferenças, quando bem trabalhadas pelo time, é o que ajuda a criar um produto melhor.
     
  2. Da mesma forma que o grupo de clientes que usa o seu software é diverso, seu time também deveria ser. Normalmente os times de desenvolvimento de produto de software é composto em sua maioria por homens, só que a população do Brasil é mais diversa. Tanto na ContaAzul como na Locaweb, mais 88% do time é composto de homens. Para ilustrar melhor esse ponto, imagine um produto tipicamente feminino, por exemplo, um vestido de festa sendo desenvolvido por um time só de homens. Ficará enviesado, com características mais importantes para os homens sendo mais trabalhadas no vestido. Agora imagine se fosse desenvolvido por um time só de mulheres. Também ficaria enviesado, com apenas o ponto de vista de mulheres. Até mesmo produtos que serão usados por um público menos diverso, como nesse exemplo de um produto feito para o público feminino, se beneficiará de ter um time composto de mulheres e homens.

diversidade_brasil

diversidade_lw

diversidade_ca

Por isso é tão importante para o sucesso do seu produto refletir e conversar sobre o assunto diversidade. Só assim você poderá pensar em questões tão essenciais para o sucesso do seu produto. Como melhorar a diversidade do seu time de desenvolvimento de produto? Como fomentar discussões que trazem diferentes pontos de vista e ajudam a enxergar sob novos ângulos o seu produto e os problemas que ele ajudam a resolver?

Data science, machine learning e gestão de produtos

Nos últimos anos tem aparecido de forma recorrente e abundante os termos data science, machine learning e artificial inteligence. Esses termos são bastante importantes para os gestores de produtos. Não é à toa que dedico 5 capítulos do livro de Gestão de Produtos a assuntos relacionados a dados e métricas.

ds_ml

Como comentei nesse artigo, o gestor de produtos deve ser um data geek, ou seja, uma pessoa que está sempre pensando em como aprender mais com dados. Qual é o comportamento de uma pessoa nos meses e dias antes de cancelar a assinatura de seu produto? E o comportamento de uma pessoa que faz upgrade? Qual é o comportamento de um usuário que se diz satisfeito com seu produto? E do que se diz muito satisfeito? Se seu produto tem várias funcionalidades, qual é a mais popular? Qual gera maior satisfação? Qual é o padrão de uso típico de seu produto? Se aparecer um padrão de uso atípico, o que isso quer dizer? Esses são exemplos de algumas perguntas que o gestor de produtos pode fazer e que terão suas respostas nas métricas do produto. E a cada nova resposta obtida é muito provável que o gestor de produtos vai querer fazer mais perguntas.

Para achar as respostas às suas perguntas, é importante que o gestor de produtos conheça técnicas de data science e saiba como extrair ele mesmo as respostas para suas perguntas, quer seja por meio de ferramentas de extração e visualização de dados, quer seja rodando queries de SQL na base de dados do produto. Se o gestor de produtos não tiver essa independência, e precisar que outras pessoas extraiam os dados para ele, isso poderá atrapalhar a evolução do produto.

À medida que esse aprendizado a partir dos dados for acontecendo, é provável que o gestor de produtos comece a perceber oportunidades para inserir esses aprendizados dentro do produto. Por exemplo, um gestor de produtos de um software de CRM pode perceber, após fazer análises com dados de uso e engajamento do produto, que clientes acabam cancelando menos quando estão utilizando a funcionalidade de geração de propostas comerciais. Uma vez feita essa descoberta, ele pode promover uma mudança em seu produto para tornar mais fácil e imediato o uso dessa funcionalidade e, com isso, diminuir o churn de clientes por deixá-los mais engajados. Essa é uma forma de inserir data science em seu produto.

Machine learning, que nada mais é que uma forma de implementação de artificial inteligence, é quando programamos as máquinas para aprenderem com os dados e, quanto mais dados a máquina tiver em suas mãos, mais ela vai aprender. É uma maneira de inserir data science no produto para torná-lo melhor. Quanto mais você usa um determinado produto, mais dados estão à disposição do time que desenvolve o produto para conhecer seu usuário e como ele usa esse produto. Por exemplo, quanto mais compras você faz em uma loja virtual, mais ela aprende sobre seus hábitos de compra e mais fácil fica para o software da loja fazer recomendações que lhe interessem. O mesmo acontece com as sugestões do Netflix e do Spotify. Nesses casos é comum a loja comparar seu uso com o uso de pessoas que mostram comportamento similar para fazer sugestões do tipo “quem comprou esse item também comprou esses outros itens”.

É por isso que o gestor de produtos e todo o time que desenvolve o produto deve conhecer e saber usar data science, machine learning e artificial inteligence no seu dia a dia. São ferramentas poderosas para o ajudar a aumentar as chances de construir um produto de sucesso.

Saiu a edição atualizada do livro Gestão de Produtos

Essa semana ficou pronta a edição atualizada do meu livro Gestão de Produtos: como aumentar as chances de sucesso do seu software! \o/

gestao_produtos_linkedin_atualizada

Quem comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço contato@casadocodigo.com.br. Quem ainda não comprou, é só visitar o site da editora Casa do Código e pedir já a sua cópia!

A primeira edição deste livro é razoavelmente recente, publicada em outubro de 2015. De lá para cá, são “só” 22 meses. Mesmo assim, senti a necessidade de atualizar o livro, pois continuei aprendendo muita coisa sobre gestão e desenvolvimento de produtos de softwares. Tenho publicado esses aprendizados aqui no blog Guia da Startup, mas senti a necessidade de incorporá-los ao livro para deixá-lo mais completo.

Nesse changelog, registrarei o que mudou desde a edição anterior. Assim, se você já leu o livro, pode ir direto para os novos textos!

  • Ao longo de todo o livro, inclui mais exemplos, tanto da Locaweb como da ContaAzul, para ajudar a ilustrar os conceitos abordados no livro.
     
  • Coloquei uma sessão nova no capítulo Gestor de produtos ou Product Owner?, explicando as diferenças entre BA (Business Analyst), PO (Product Owner) e PM (Product Manager). São papéis similares, mas com aumento de responsabilidades.
     
  • Adicionei um capítulo sobre como gerir gestores de produtos. Nem sempre um bom gestor de produtos se torna um bom gestor de gestores de produtos. Esse capítulo explica o que devem ser os objetivos de um gestor de gestores de produtos.
     
  • Na fase de Inovação, no capítulo Muitas oportunidades, inclui uma seção sobre uma pergunta que ouço com frequência: devo perseguir novas oportunidades, ou é melhor focar o time em implementar melhorias no produto existente?
     
  • Também na fase de Inovação, no capítulo Como obter retorno com seu produto de software, inclui mais uma opção de obter receita paga por alguém interessado em seu software: a venda de serviços de terceiros aos seus usuários.
     
  • Na fase de Crescimento, no capítulo O que é um roadmap?, inclui um seção intitulada OKRs, o futuro dos roadmaps, onde falo sobre OKRs (Objective and Key Results), framework usado por várias empresas (como LinkedIn, Google, Amazon, dentre outras) para ajudar na gestão das iniciativas da empresa como um todo e que são um ótimo complemento aos roadmaps.
     
  • Na fase de Crescimento, no capítulo Como priorizar o roadmap, inclui mais duas técnicas que aprendi recentemente: o Sequenciador de features, criado pelo Paulo Caroli, da ThoughtWorks; e o RICE, método de priorização adotado pelo time de desenvolvimento de produtos da ContaAzul.
     
  • Também na fase de Crescimento, inclui uma seção ao capítulo Crescimento: engajamento e churn intitulada Data science, machine learning e gestão de produtos. Nela explico os conceitos de data science e machine learning, e a sua importância para o sucesso do seu produto de software.
     
  • Inclui o capítulo O que é e como criar a visão e a estratégia do produto? no final da fase de Crescimento. Nele explico o que é e para que serve a visão e a estratégia do produto, ferramentas úteis para as tomadas de decisão sobre qual será o futuro do seu produto. Neste capítulo, apresento algumas técnicas e ferramentas para ajudar na criação da visão e na elaboração da estratégia de seu produto de software.
     
  • No capítulo Engenharia de produtos e gestão de produtos, incluí a seção Não dá mais, precisa reescrever tudo…, falando sobre reescrita de sistemas ou de parte de sistemas. Qualquer pessoa que trabalha com desenvolvimento de software vai se deparar com o momento em que surgirá a discussão da necessidade de reescrita. Qual o papel do gestor de produtos nessa discussão?
     
  • No capítulo Organizando para o foco e para a diversificação, inclui alguns parágrafos nos quais conto sobre as motivações que fizeram o time da Locaweb a não ter times separados de QA e de front-end, e sobre a razão de eu não ter mencionado BAs no capítulo sobre organização de times.
     
  • Inclui o capítulo Como quadruplicar a produtividade na Parte 4 do livro, no qual mostro como quadruplicamos a produtividade do time de desenvolvimento de produtos da Locaweb, sem aumentar a quantidade de pessoas no time e com impacto positivo na qualidade.
     
  • Inclui um capítulo na Parte 5 do livro, intitulado E se pararmos de tratar desenvolvimento de software como projeto?, em que proponho deixarmos de chamar desenvolvimento de software de projeto e passarmos a tratá-lo como produto.
     
  • Na conclusão, inclui uma seção intitulada O que é preciso para ser um bom gestor de produtos de software? para responder essa pergunta que me fizeram algumas vezes.

Relembrando, quem comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço contato@casadocodigo.com.br. Quem ainda não comprou, é só visitar o site da editora Casa do Código e pedir já a sua cópia!

Não dá mais, tem que reescrever tudo…

Já ouvi essa frase várias vezes ao longo da minha carreira. Quem trabalha com desenvolvimento de software sabe que invariavelmente chega um momento em que aparece essa discussão com frases como: Está cada vez mais difícil mexer no código. Se fosse fazer do zero, seria muito mais rápido. Se não reescrevermos, vai ficar cada vez mais lento e perigoso mexer no código.

Na Locaweb tínhamos o produto de Email Marketing, para envio e gerenciamento de campanhas de email marketing, que usava como base de dados o MongoDB, uma base de dados não relacional conhecida por sua capacidade armazenar grandes bases de dados. Contudo, provavelmente devido à nossa pouco experiência em desenvolvimento de software usando esse tipo de base de dados e em administrar bases de dados não relacionais, à medida que a base de dados crescia, o sistema ficava cada vez mais lento. Por isso foi necessário reescrever o produto para usar PostgreSQL. Desenhamos essa reescrita de forma a ser transparente para os clientes, ou seja, o cliente não ia ser migrado de uma base de dados para outra, evitando assim passar por um período de indisponibilidade ou eventual perda de dados. A reescrita foi um sucesso. O processo todo de reescrita, incluindo colocar todos os clientes existentes (mais de 15.000 clientes) na nova base de dados, permitindo desligar a base de dados MongoDB, levou seis meses, um prazo razoável para uma iniciativa desse tamanho. Contudo, durante esses seis meses o time não entregou nada novo para o cliente. Nenhuma nova funcionalidade. Para diminuir a frustração de nossos clientes, decidimos por contratar uma empresa terceirizada para construir aplicativos para iOS e Android em cima das APIs existentes do produto. Com isso conseguimos entregar novas funcionalidades para nossos clientes enquanto o time de produto ficava focado no reescrita. Se essa opção não existisse, teríamos que encontrar outras formas de entregar valor para o usuário que não dependessem do time de engenharia.

Se você trabalha com desenvolvimento de software, tenha certeza que, se ainda não passou por essa situação em sua carreira, certamente passará. O problema de reescrever software é que, ao reescrever software, o time deixa de fazer coisas novas para o usuário do software, como mostrei acima no exemplo do produto de Email Marketing da Locaweb. Ou seja, do ponto de vista de negócio o software não evolui, o cliente não vê evolução, e pode perder o interesse pelo seu produto passando a procurar opções melhores no mercado. Por isso eu gostaria de tecer algumas considerações sobre o tema:

  • Tecnologias novas e melhores irão aparecer sempre. Antigamente desenvolvia-se sistemas com tudo em um código só. Depois foi o conceito de MVC (_model_, _view_, _controller_) separando o código do software em camadas de acordo com sua função. Mais recentemente foi criado o conceito de microserviços, quebrando a aplicação em aplicações pequenas, conectadas com baixo acoplamento, feito preferencialmente via APIs, facilitando a manutenção. Se, a cada nova tecnologia que aparecer, formos reescrever o software, certamente não faremos outra coisa senão reescrever software.
     
  • Reescrever software tem que ter uma motivação clara de negócio, ou seja, deve de alguma forma atender os objetivos estratégicos da empresa que é dona do software e deve atender às necessidades ou resolver um problema dos clientes. Se não houver uma motivação clara de negócio, a recomendação é não reescrever.
     
  • Se reescrever for inevitável (tem certeza?), é importante pensar nessa iniciativa de reescrita do ponto de vista de negócios, ou seja, qual é o impacto dessa reescrita para os clientes e para o dono do software. Entender isso é responsabilidade do gestor de produtos. Algumas perguntas para te ajudar a refletir junto com o time sobre esse impacto:
    • Como será essa reescrita?
    • Enquanto a reescrita estiver acontecendo, vão ser entregues novas funcionalidades?
    • Como será a co-existência do sistema novo com o sistema velho?
    • Quando forem implementadas novas funcionalidades, serão implementadas no sistema novo e no sistema velho, ou só no sistema novo?
    • Quando novos clientes poderão ser instalados no sistema novo?
    • Quando os clientes existentes serão migrados para o sistema novo?
    • Se existir a proposta de fazer um sincronizador para que os dados dos clientes existam simultaneamente no sistema velho e no sistema novo, qual é o custo dessa proposta se comparado com a opção de não fazer esse sincronizador?
    • Se a diferença entre o sistema velho e o sistema novo puder ser percebida pelos clientes, como essa diferença será comunicado?

Pronto, aí estão algumas considerações sobre reescrita de software, um tema muito importante para qualquer gestor de produto.

Novas oportunidades vs melhorias no produto existente

    Essa é uma dúvida bastante frequente. Devo perseguir novas oportunidades? E o que faço com as dores dos clientes atuais? Devo desenvolver um novo produto ou uma nova funcionalidade? Ou devo resolver dores dos clientes atuais desenvolvendo melhorias em meu produto? Como fazer para balancear entre perseguir novas oportunidades e implementar melhorias no produto existente?

    melhorias-ou-oportunidades

    Aqui a solução é simples, pelo menos em teoria. Produto atual é produto atual, novas oportunidades são novas oportunidades. Cada um tem que ser tratada de um jeito. O ideal é que sejam tratadas até mesmo por times diferentes. Só que nem sempre isso é possível. Nesses casos, se quisermos perseguir novas oportunidades, esse time tem que saber separar claramente o trabalho no produto existente vs o trabalho nas novas oportunidades. Por exemplo, 2 semanas para o produto existente, uma para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.

    Atenção: não é time de bugs

    Esse é um ponto importante. A ideia não é separar os times para ter um time fazendo coisas novas e outro corrigindo bugs do produto existente. Isso não funciona, pois vai criar uma separação muito grande entre os dois times. Quem faz coisas novas vai eventualmente acreditar que pode fazer qualquer coisa sem se preocupar tanto com qualidade já que existe um time focado em correção de bugs. Do outro lado, o “time de bugs” vai achar que está fazendo trabalho de faxineiro, limpando as bagunças que outras pessoas fazem.

    Oportunidades vs melhorias

    Antes de investir em uma nova oportunidade é muito importante entender porque está se investindo nessa nova oportunidade. Uma ótima ferramenta para isso é a análise de oportunidades. Sem um claro entendimento e correto engajamento de todos os envolvidos pode-se colocar a oportunidade a perder sem nem mesmo começar a explorá-la.

    Um ponto importante que todos os envolvidos devem entender é que uma nova oportunidade é uma nova oportunidade, ou seja, ela deverá gerar resultados que se somam aos atuais. Esses resultados deveriam ser suficientes para justificar a criação de um novo time para perseguir essa nova oportunidade. No mínimo, dois engenheiros de software. Idealmente, além dos dois engenheiros, seria bom ter um gestor de produtos, um designer de UX e uma pessoa de marketing de produtos dedicadas a essa nova oportunidade. Essa nova oportunidade irá ser um novo produto ou uma nova funcionalidade. Quando esse novo produto ou nova funcionalidade estiver pronto e lançado, quem trabalhou no seu desenvolvimento irá cuidar de seus bugs e melhorias.

    Enquanto isso, o outro time cuida do produto atual, ou seja, de melhorar o produto atual para que ele continue atingindo seus objetivos. Melhorar o produto atual significa sim corrigir bug, mas significa também fazer coisas novas no produto existente. Melhorias para tornar o produto melhor, mais útil e mais usável.

    Caso não seja possível criar um novo time, pode-se fazer compartilhamento do tempo do mesmo time. Algo como uma ou duas semanas para bugs e melhorias do produto atual e uma semana para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.

    Como saber se é uma melhoria ou uma nova oportunidade?

    É responsabilidade do gestor de produtos, junto com o time, entender se esse algo novo que surgiu para ser feito é uma oportunidade ou uma melhoria. Mas como discernir entre melhoria e oportunidade? Especialmente quando o algo novo a fazer for uma nova funcionalidade do produto existente, devemos encarar como nova oportunidade ou melhoria do produto existente?

    Depende do esforço e do retorno envolvidos. Uma nova oportunidade deve ter um retorno alto para fazer sentido persegui-la. Lembre-se que uma nova oportunidade vai eventualmente ter um time só para cuidar dela, então é preciso que o retorno seja suficiente para justificar esse novo time. Se o retorno for incerto, é melhor não tirar energia do produto existente para perseguir essa nova oportunidade. Por outro lado, se houver a perspectiva de um bom retorno, qual o esforço de criar algo para explorar essa oportunidade? E qual será o esforço para manter esse algo? Essas duas perguntas devem orientar a forma de encarar. Se o esforço for baixo, esse algo novo pode ser tratado como uma melhoria e ser desenvolvido pelo time atual. Se o esforço é alto, é recomendável tratá-lo como nova oportunidade e considerar ter um time separado para fazer o desenvolvimento.

Viagem no tempo

Acaba de ser lançada a edição atualizada do meu primeiro livro, o Guia da Startup. A primeira edição deste livro foi escrita em 2012, há mais de 4 anos. Muita coisa aconteceu na indústria de software e no cenário de startups do Brasil e do mundo. Por esse motivo, resolvi escrever uma segunda edição, trazendo algumas dicas novas, atualizando sobre o andamento do ContaCal e com um update das entrevistas publicadas na versão original, e mais algumas entrevistas novas.

Mudei as referências a “produto web” para “produto de software”. Fiz isso pois mobile é agora o novo veículo do software. No mobile, o software pode ser entregue via web ou via app. No futuro, o software será usado em relógios, em carros, em qualquer lugar. Por esse motivo, troquei onde falo “produto web” por “produto de software” ou simplesmente por “produto”. Aliás, isso me motivou até a mudar o subtítulo deste livro. Se você já o leu, talvez isso lhe motive a relê-lo, vendo produto sob este novo prisma.

Ao fazer essa atualização, um dos capítulos que mais mudou foi o capítulo “Produto web, móvel ou social?”. Atualizei o título do arquivo para “Produto web, móvel ou social? Produto para SmartWatches? SmartTVs? Bots?”. Aqui vai o capítulo completo, com direito a uma viagem no tempo!

Produto web, móvel ou social? Produto para SmartWatches? SmartTVs? Bots?

Acredito que, antes de falarmos sobre a situação e a recomendação sobre esses temas, vale mostrar o que escrevi em 2012, na primeira edição do *Guia da Startup*.

Viajando para o passado: web, móvel ou social em 2012?

Não é necessário ser nenhum mago das previsões para perceber duas tendências que estão acontecendo na internet. A primeira delas é que, cada vez mais, as pessoas estão acessando a internet e aplicações web por meio de aparelhos móveis, como iPhone, iPad, celulares e tablets com Android, ou mesmo aparelhos Blackberry ou com Windows Mobile. A segunda é que cada vez mais as pessoas gastam seu tempo online em redes sociais.

Em função disso, é natural surgir uma dúvida quando se pensa em fazer um produto web se, em vez de web, não deveríamos então estar pensando em fazer uma aplicação móvel, ou mesmo uma aplicação social, ou seja, para ser usada dentro das redes sociais.

Para ajudar a responder a essa dúvida, devemos olhar para duas questões: ter números do mercado para entender essas tendências, e conhecer seu usuário e onde ele quer seu problema resolvido.

Aplicações para aparelhos móveis

Antes de mais nada, é preciso confirmar as tendências. A primeira é sobre o uso de aparelhos móveis para acessar a internet. O site StatCounter Global Stats (http://gs.statcounter.com) oferece bons dados sobre acesso web agregados de um conjunto de 15 bilhões de pageviews mensais.

Esses dados oferecem uma visão sobre como as pessoas estão acessando a web. É clara a tendência de aumento de acesso a web por meio de aparelhos móveis, mas ainda está na faixa de 10%:

Evolução global de acesso móvel à web

Evolução global de acesso móvel à web

No Brasil, temos um pouco menos de adoção ao acesso móvel à web:

Evolução de acesso móvel à web no Brasil

Evolução de acesso móvel à web no Brasil

Nos Estados Unidos, a situação também é parecida com a estatística global:

Evolução de acesso móvel à web no Estados Unidos

Evolução de acesso móvel à web no Estados Unidos

Somente por curiosidade, um país onde a adoção de acesso móvel quase se iguala e está próximo de passar o acesso via desktop é a Índia:

Evolução de acesso móvel à web na Índia

Evolução de acesso móvel à web na Índia

Para confirmar esses dados, aqui vão os dados de acesso ao site da Locaweb. Aproximadamente 97,5% dos acessos são feitos a partir de desktop ou notebooks:

[Dados de acesso ao site da Locaweb em Abril/2012

[Dados de acesso ao site da Locaweb em Abril/2012

E no ContaCal, aproximadamente 93% dos acesso são feitos a partir de desktop ou notebook:

Dados de acesso ao site da ContaCal em Abril/2012

Dados de acesso ao site da ContaCal em Abril/2012

Esses gráficos mostram que é importante, sim, pensar em ter um produto web que possa ser acessado de forma móvel. Contudo, o mercado brasileiro, o americano e o mundial ainda não são majoritariamente móveis, nem estão próximos de se tornar majoritariamente móveis nos próximos 3 anos. Se olharmos a evolução da Índia, que está próxima de ter a quantidade de acesso móvel igual ao acesso desktop, essa situação chegou após 3 anos da situação que é vista no resto do mundo.

É difícil saber se o acesso móvel vai substituir ou minimizar o acesso desktop. Pode até acontecer de aparecerem outras formas de interação que ainda não existem hoje. O acesso por meio de aparelhos móveis é uma tendência clara, que deve não só ser observada de perto como também já deve motivar você a agir, ou seja, a pensar em desenvolver versões móveis de seu site ou aplicação web caso você ainda não o tenha feito. Para ajudar nessa tarefa, aqui vão algumas dicas.

De volta para o futuro

Isso tudo foi em 2012. Vindo para o agora, se você acessar o StatCounter Global Stats (http://gs.statcounter.com), verá que os dados evoluíram consideravelmente nos últimos anos. A quantidade de acesso móvel acaba de passar a quantidade de acesso via web:

Evolução global de acesso móvel à web

Evolução global de acesso móvel à web

No Brasil, a tendência é a mesma, apesar de estarmos um pouco atrasados:

Evolução de acesso móvel à web no Brasil

Evolução de acesso móvel à web no Brasil

Nos Estados Unidos, temos já 40% de acesso móvel:

Evolução de acesso móvel à web no Estados Unidos

Evolução de acesso móvel à web no Estados Unidos

E na Índia, o acesso móvel chegou a 80%:

Evolução de acesso móvel à web na Índia

Evolução de acesso móvel à web na Índia

Em julho de 2015, a PewResearch informava que 76% das pessoas que acessavam a internet usavam algum site social, sendo que 72% usavam Facebook. E os gráficos seguintes mostram que, enquanto a quantidade de PCs vendidos cai, a quantidade de aparelhos móveis cresce vertiginosamente.

Vendas de PCs por ano

Vendas de PCs por ano

Vendas de PCs e equipamentos mobile por ano

Vendas de PCs e equipamentos mobile por ano

Além disso, outras possíveis interfaces surgiram, como os SmartWatches, as SmartTVs e os bots. Algumas inclusive surgiram e já morreram, como é o caso do Google Glass.

O que fazer? Devo desenvolver produtos web? Mobile? Social? SmartWatch? SmartTV? Bot? E a Internet das Coisas? As opções aumentaram bastante desde 2012. E posso afirmar com toda a certeza de que elas vão continuar aumentando.

Por isso, você deve mudar o seu foco. Em vez de pensar no meio por onde seu produto vai ser entregue, foque-se no seu usuário.

Entenda seu usuário

Antes de pensar em qual plataforma você vai entregar seu software, você deve dar um passo atrás e relembrar qual o problema ou necessidade que você busca resolver e para quem. As pessoas para quem você resolve um problema ou necessidade com seu produto de software, como eles preferem interagir com seu software? Usando um SmartPhone? Um SmartWatch? Bot? Web?

Você precisa entender aonde faz sentido entregar seu produto de software para que ele possa resolver o problema ou necessidade de seu usuário da melhor forma possível.

Entenda o contexto

Quando um usuário acessa um site ou uma aplicação web de um desktop ou notebook, ele está normalmente sentado, com o computador em uma mesa ou no colo. A tela é grande, com bastante espaço para dispor informações. A interação é feita com mouse ou trackpad e teclado.
Já com um SmartPhone, a pessoa pode estar parada ou em movimento. A tela é pequena, com pouco espaço para disponibilizar informações, e a interação é feita com o dedo em equipamentos touch, ou com um apontador e um teclado pequeno.

Já com um tablet, a pessoa normalmente acessa sentada, com ele no colo ou sendo segurado em uma mão; ou em pé, com ele sendo segurado em uma mão; ou deitado, com ele apoiado nas pernas ou sendo segurado por uma das mãos. A tela é maior, chegando próxima do tamanho de tela dos notebooks menores, tendo assim um espaço razoável para dispor informações. A interação é normalmente feita com os dedos e, em alguns casos mais raros, com um teclado adaptado para tablets.

É importante conhecer esses contextos nos quais cada aparelho é usado para desenvolver uma versão de seu produto de software que seja útil para seu usuário. Por exemplo, se você estiver fazendo um site de um restaurante, no que será acessado por desktop faz sentido colocar o cardápio, matérias de jornal que falam sobre o restaurante e fotos. Já na versão para ser acessada por SmartPhones, você deve pensar no contexto e oferecer as funções mais úteis nessa situação.

Por exemplo, o site no SmartPhone pode ter dois botões grandes: um que ao ser tocado possibilita ligar para o restaurante; e outro que abre o Google Maps mostrando o endereço do restaurante.

Mobile não é “menos” que desktop

É importante também entender que SmartPhones não são menos poderosos que desktops. É comum pensar que, por terem menos capacidade de processamento e de armazenamento, equipamentos móveis são mais “fracos” do que computadores desktop ou notebooks. Sim, isso é verdade na maioria das vezes. Por outro lado, equipamentos móveis são providos de outras funcionalidades que não estão presentes nos equipamentos maiores, como GPS, sensor de movimento, duas câmeras, telefonia celular, conexão com internet em qualquer lugar que tenha rede de telefonia móvel. Isso é muito mais do que um notebook pode entregar.

É importante entender as diferenças e as possibilidades de cada interface para poder tirar o melhor dela na resolução do problema de seus clientes com seu produto de software.

Resumindo

Como vimos aqui, é importante sim estar antenado a essas tendências, mas devemos também entender muito bem nossos usuários, seus problemas e necessidades para oferecer a eles a melhor solução da maneira que for mais conveniente para eles, quer seja pela web, por meio de uma aplicação móvel, aplicação dentro de redes sociais, aplicação para SmartWatch, ou até um bot. Uma estratégia mista acessível por qualquer uma dessas plataformas pode ser a solução mais adequada para seu produto de software resolver o problema de seus usuários.

2ª edição do livro Guia da Startup

Desde de fevereiro está disponível a 2ª edição do livro Guia da Startup. Para conhecer todas as novidades dessa segunda edição, veja o changelog.

Guia da Startup – edição atualizada

Essa semana ficou pronta a edição atualizada do Guia da Startup! \o/

Quem comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço contato@casadocodigo.com.br.

A primeira edição deste livro foi escrita em 2012, há mais de 4 anos. Muita coisa aconteceu na indústria de software e no cenário de startups do Brasil e do mundo. Por esse motivo, resolvi escrever uma segunda edição, trazendo algumas dicas novas, atualizando sobre o andamento do ContaCal e com um update das entrevistas publicadas na versão original, e mais algumas novas.

guia-da-startup-edicao-atualizada-capa

Veja aqui o changelog completo:

  • De produto web para produto de software — Mudei as referências a “produto web” para “produto de software”. Fiz isso pois mobile é agora o novo veículo do software. No mobile, o software pode ser entregue via web ou via app. No futuro, o software será usado em relógios, em carros, em qualquer lugar. Por esse motivo, troquei onde falo “produto web” por “produto de software” ou simplesmente por “produto”. Aliás, isso me motivou até a mudar o subtítulo deste livro. Se você já o leu, talvez isso lhe motive a relê-lo, vendo produto sob este novo prisma. 
     
  • Adição ao capítulo Recebendo feedback — Adicionei a este capítulo uma seção explicando a importância do porquê antes do como. 
     
  • Adição ao capítulo Cuidado ao lançar um produto mínimo — Adicionei a este capítulo um exemplo de experimento de fake feature que fiz no ContaCal e que me poupou muitas horas de desenvolvimento que se mostrariam desnecessárias. 
     
  • Capítulo novo: Dicas básicas (e não tão básicas) de SEO — Para ajudar a atrair tráfego para o site de sua startup, é importante entender de SEO (Search Engine Optimization). Neste capítulo, compartilho um pouco do que aprendi sobre o tema. 
     
  • Capítulo novo: Vá vender! — Essa é a melhor maneira de entender se seu produto resolve o problema dos clientes. Em uma startup, todos têm de vender. Então, o que você está esperando? Vá vender! 
     
  • Capítulo novo: Churn — Um capítulo inteiro dedicado ao churn, quantidade de usuários e clientes que deixaram de ser usuário ou cliente. Neste capítulo, explico também sobre o tão falado churn negativo. Como é possível ter churn negativo? 
     
  • Capítulo novo: Mudança de rumo (pivot) — Aqui conto o caso da Eventials, uma plataforma para transmissão de palestras online, que precisou mudar para sobreviver. Qual era o problema, o que eles fizeram e as 10 formas possíveis de mudança de rumo são os temas deste capítulo. 
     
  • Adição ao capítulo Quanto tempo demora até ter retorno? — Adicionei a este capítulo informações sobre o primeiro mês positivo do ContaCal. 
     
  • Capítulo novo: Cinco anos depois, como está o ContaCal? — Aqui conto como está o ContaCal, se ele está dando retorno financeiro e se atingiu seus objetivos. 
     
  • Entrevistas — Todas as entrevistas foram atualizadas com a situação mais recente das empresas e de seus produtos. Inclui também algumas novas entrevistas:
    • Sonia Tuyama, da empresa Aurum, com mais de 20 anos de mercado, que tem um software não web e que, em um determinado ponto de sua vida, percebeu que precisava fazer uma versão web de seu software.
    • Thiago Lima, fundador da Eventials, que citei em dois capítulos novos.
    • Vinicius Roveda, um dos fundadores da ContaAzul, empresa que escolhi para voltar a viver esse clima tão gostoso de Startup.

Gostou das novidades? Como disse acima, se vc comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço contato@casadocodigo.com.br.

Agora, se vc ainda não comprou sua cópia do Guia da Startup, o que está esperando, adquira sua cópia hoje mesmo!!!

Mais sobre priorização de roadmaps

Como comentei em meu artigo anterior, priorização é uma das principais tarefas de um PO e de um PM, e é o diferencia um PO de um BA. Escrevi um artigo sobre as várias formas de priorização e sobre como dizer não aos inúmeros pedidos que recebemos tanto dos clientes quanto das pessoas de dentro da empresa.

priorizacao

Como o passar do tempo aprendi mais maneiras de se priorizar um roadmap e queria compartilhá-las aqui.

Sequenciador de Funcionalidades

O Sequenciador de Funcionalidades foi criado por Paulo Caroli, da ThoughtWorks, para auxiliar no planejamento de um produto a partir de suas funcionalidades. As regras desse método, como o limite de 3 cards por linha, auxilia na conversa sobre priorização.

O Sequenciador de Funcionalidades ajuda a organizar e visualizar as funcionalidades e sua relação com os entregáveis. O sequenciador organiza as releases do produto além do primeiro entregável. Tipicamente, times utilizando o sequenciador de funcionalidades irão vislumbrar a evolução do produto por meio de um entendimento claro das funcionalidades de cada entregável bem como a ordem dos releases.

secuenciador-2

De acordo com Paulo Caroli, em seu livro Direto ao Ponto, Criando produtos de forma enxuta, o Sequenciador de Funcionalidades funciona da seguinte forma:

Feature é a descrição de uma ação ou interação de um usuário com o produto. Por exemplo: imprimir nota fiscal, consultar extrato detalhado, e convidar amigos do facebook. A descrição de uma feature deve ser o mais simples possível. O usuário está tentando fazer uma coisa. O produto deve ter uma feature para isso. Que feature é essa?

Cada cartão de feature possui uma cor representado o nível de incerteza, e marcações para o nível de esforço e o valor de negócio. Por exemplo, a figura acima mostra features em index cards, nas quais foram adicionadas marcações de $, $$ ou $$$, respectivamente, para valor de negócio alto, muito alto e altíssimo, bem como E, EE, ou EEE, respectivamente, para nível de esforço baixo, médio e alto. O nível de incerteza é representado pela cor do cartão de índice, os quais são verde, amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza, respectivamente.

O nível de incerteza da Feature refere-se ao grau em que a Feature é incerta, a partir do ponto de vista do entendimento de negócio e do entendimento técnico. Isso é indicado pela cor do cartão de índice, os quais são verde, amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza, respectivamente. O entendimento da Feature de acordo com os desafios técnicos, e os requisitos de infraestrutura. Você já fez isso antes? Você sabe como fazê-lo? Um sim bem firme indica elevado nível de entendimento técnico. A clareza do objetivo da Feature, o benefício para o negócio e o que deve ser feito. O que fazer? Uma resposta direta e clara indica um alto nível de concordância.

Esforço da Feature

O nível do trabalho que precisa ser feito para a Feature. O entendimento da equipe de acordo com a dificuldade e o trabalho que vai ser necessário para completar a Feature.

Valor do Negócio da Feature

O valor de negócio, o ROI (Return On Investment) associado a Feature, uma medida do negócio sobre o valor previsto para tal feature. Qual é o retorno no investimento ou a economia que a Feature vai trazer?

As regras do sequenciador de features

Features serão adicionadas a cada onda. A seguir, as seis regras para adicionar features às ondas. Tais regras foram definidas depois de aplicar esta forma de planejamento e priorização inúmeras vezes.

  • Regra 1: Uma onda pode conter no máximo 3 features.
     
  • Regra 2: Uma onda não pode conter mais de uma feature em cartão vermelho.
     
  • Regra 3: Uma onda não pode conter três features, somente em cartões amarelos e vermelho.
     
  • Regra 4: A soma de esforço das features não pode ultrapassar 5 Es.
     
  • Regra 5: A soma de valor das features não pode ser menos de 4 $s.
     
  • Regra 6: Uma onda tem de conter no mínimo 2 features.

A regra 1 limita o número de features que estão sendo trabalhados ao mesmo tempo. Isso evita o acúmulo de features parcialmente completas, aumentando o foco para as poucas features priorizadas por onda. As regras 2 , 3 e 4 evitam um período de trabalho desequilibrado com muita incerteza, ou muito esforço. As regras 5 e 6 garantem o foco constante na entrega de alto valor para o negócio.

Os MVPs no sequenciador de features

Além dos cartões de features (sequenciados), o sequenciador de features mostra claramente o agrupamento de features para cada MVP. Isto é representado por post-its no canto direito sobre a linha que delimita uma onda.

As ondas não terão necessariamente uma relação de um para um com os MVPs. O intuito é de organizar features em ondas para entregar valor o mais rápido possível, entretanto respeitando as dependências entre as features

RICE

Quando cheguei na ContaAzul me deparei com outro método de priorização adotado pelo time de produtos, o RICE.

RICE é a sigla em inglês para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e, ao final, divididos pelo último.

Alcance se refere a quantas pessoas aquela tarefa irá alcançar num determinado período de tempo, que deve ser igual para todas as features que estão sendo comparadas. Impacto estima a quantidade de pessoas que serão impactadas (use o valor 3 para um impacto massivo, 2 para um grande impacto, 1 para médio, 0.5 para pequeno e 0.25 para um impacto mínimo). Confiança aborda o quão confiante você está sobre suas estimativas (escolha entre 100%, para uma alta confiança, 80% para média e 50% para baixa). Em Esforço, coloque quantas pessoas-mês a tarefa levará para ser concluída sendo o mínimo o valor 0,5, ou seja, uma pessoa por meio mês.

O cálculo matemático é bem simples:

RICE = (Alcance x Impacto x Confiança) / Esforço

A melhor ferramenta de priorização

Tanto o índice RICE quanto o sequenciador de funcionalidades são excelentes ferramentas para o gestor de produtos poder ter mais confiança em sua priorização. Contudo, como eu disse no meu primeiro artigo sobre o tema:

…existem várias maneiras de se priorizar um roadmap, todas elas bastante úteis. Ou seja, o que dá para concluir é que, se há tantas maneiras de se priorizar um roadmap e se todas as maneiras de se priorizar podem ser úteis, isso significa que priorização de roadmap não é uma ciência exata.

Temos um anseio de querer achar um método de priorização para justificar nossas escolhas, mas sempre que esse método falhar em um determinado item que temos certeza que seria melhor fazer antes ou depois do que o método diz, acabamos tentados a seguir essa nossa certeza, pondo abaixo o método.

Por isso, por mais que existam várias técnicas e métodos de priorização de roadmap, o melhor método é o bom senso, ou seja, a capacidade do gestor de produtos de analisar as opções disponíveis e, usando-se de sua empatia, priorizar essas opções levando em conta os objetivos da empresa e as necessidades dos usuários.

E por que é preciso incluir o bom senso como mais uma ferramenta de priorização? Porque para priorizar é preciso entender os objetivos dos usuários de seu produto de software e do dono do software. Esse objetivos podem ser conflitantes e, provavelmente, existem mais variáveis do que alcance, impacto, confiança, esforço, retorno, valor, custo, satisfação e necessidade para ajudar a quantificar esses objetivos. Como se não bastasse a grande quantidade de variáveis e os objetivos conflitantes dos usuários do produto de software e do dono de software, há ainda a variável tempo, ou seja, esses objetivos podem mudar ao longo do tempo.

Toda priorização é uma decisão e todo processo decisório é composto de incertezas. As ferramentas acima ajudam a remover um pouco das incertezas. Contudo, com essa grande quantidade de variáveis, é muito difícil, diria até que impossível, remover 100% das incertezas. Por esse motivo, para fazer uma boa priorização, pode ser útil usar uma ou mais dessas ferramentas descritas, mas é importante usar também o instinto, a experiência e o bom senso.

BA, PO e PM

Escrevi em julho de 2014 sobre as diferenças entre gestor de produtos ou product owner, onde comento que gestor de produtos e product owner são dois lados da mesma moeda. Enquanto o papel de gestão de produtos é focada no resultado, ou seja, no software que está sendo feito e nos objetivos desse software, tanto para o dono do software quanto para seu usuário, o papel de product owner é focado no processo pois todas a metodologias ágeis tem seu foco no processo de desenvolvimento de software.

Em um outro artigo, de março de 2016, comento que “BA e PO são papéis muito similares no desenvolvimento de software. Ambos têm o mesmo objetivo: ajudar o time a fazer um software que atenda ao objetivos do dono do software enquanto resolve problemas e necessidades de seus usuários”.

Algum tempo depois…

Esse dois artigos foram escritos baseados em minha experiência na Locaweb, onde tínhamos somente o papel de gestor de produtos, que chamávamos indiscriminadamente de PO ou de PM e em conversas que tive com pessoas de outras empresas onde elas me contavam sobre suas estruturas e divisões de papéis e responsabilidades.

Em agosto de 2016 assumi a gestão da gestão de produtos na ContaAzul e quando aqui cheguei me deparei com business analysts (BAs) e product managers (PMs), um cenário novo para mim. Passei algum tempo conversando com as pessoas para entender papéis e responsabilidades de cada função e as motivações de essa estrutura ter sido criada. Após essas conversas, ficou mais claro para mim a diferença de papéis e responsabilidades de cada uma das funções, diferença essa que tento traduzir na imagem abaixo.

ba-po-pm

Essa imagem mostra alguns pontos importantes:

  • POs fazem o que BAs fazem (especificação) mais a priorização do que precisa ser feito. E os PMs, além de priorização e especificação, são responsáveis pelo desenvolvimento, comunicação e execução da visão e estratégia do produto. Ou seja, existe um aumento de escopo e responsabilidade à medida que se move na carreira de BA para PO e depois para PM.
     
  • Apesar de o PM ter por sua responsabilidade o desenvolvimento, comunicação e execução da visão e estratégia do produto, ele também é responsável pela priorização e pela especificação.
     
  • Pode fazer sentido em algumas empresas ter BAs e PMs, ou POs e PMs, ou mesmo BAs, POs e PMs. Contudo, não pode haver empresas sem alguém fazendo o papel de PM, ou seja, desenvolvendo, comunicando e executando a visão e estratégia do produto.
     
  • Caso haja em uma empresa, além dos PMs, pessoas exercendo função de BA e/ou PO, é possível colocar os PMs como gestores dos BAs e/ou POs. Contudo, isso cria uma carga extra para o PM que, além de gerir o produto, terá que se preocupar com gestão de pessoas.
     
  • Minha preferência é por não ter essa separação de papéis e ter apenas PMs, ou seja, se houver BAs e ou POs numa determinada organização, minha recomendação é por tratar esse papéis como passos intermediários de carreira que vão evoluir para atingir o nível de PM, com aumento de escopo e de responsabilidade. A justificativa para essa minha preferência é que, ao deixar os papéis separados, pode acontecer de o PM fazer pouca ou nenhuma especificação e/ou priorização, delegando essas responsabilidades para BAs e/ou POs. Ao fazer isso, o PM perderá insumo importante para o desenvolvimento da visão e estratégia do seu produto.

Acredito que com essa imagem consegui deixar mais claro as diferenças e similaridades das funções de BAs, POs e PMs.