You are currently browsing the Guia do Gerente de Produtos 2.0 blog archives for June, 2008


O que há num Nome? Menos do que você imagina…

Ninguém visita seu site? A imagem da empresa está desgastada? Os planos de negócios mudaram? É hora de reformular a marca!

Ou talvez não.

De alguma forma a marca se tornou a culpada pelos problemas da empresa, e, ao ser alterada, resolverá tudo de uma vez. Mas você não pode criar ou consertar uma empresa apenas com um nome, logotipo ou conjunto de cores. Alguém se lembra da reformulação de marca da Webvan? Em tecnologia, tendemos a pensar que somos exceção a todas as regras. O problema é que a maior parte de nós não conhece as regras, o que significa que as marcas não tem o efeito que as empresas de tecnologia esperam.

Qual o problema? Uma verdadeira marca é muito mais que o nome da empresa, sua identidade visual ou o quanto ela anuncia. Uma marca é uma promessa aos clientes que transcende qualquer produto ou serviço específico. As melhores marcas se baseiam em uma fundação de um simples produto ou serviço oferecido de forma consistente. Comida rápida e barata? McDonalds. Cafezinho no meio da tarde? Starbucks. Precisa de ajuda para encontrar a gravada perfeita para seu terno? Nordstroms. Os gadgets tecnologias mais ‘legais’? Apple. Precisa de algo da noite para o dia? FedEx.

Agora, rápido – você sabe por quantos logotipos estas empresas passaram nos últimos cinco anos? Suponho que não, e provavelmente você nem se importe com isso. Este é o poder de marca aplicado da maneira correta, e é por isso que criar uma é bem mais difícil do que as pessoas pensam.

Muitas marcas high-tech começam assim: os poderosos da empresa se reúnem para um brainstorm de marca, definem uma lista de atributos da marca como ‘ágil’ e ‘inovadora’, colocam numa apresentação em PowerPoint, entregam para uma agência, que cobra uma pequena fortuna para criar um nome e um logo que os fundadores gostarão, e assim nasce uma nova marca. Para a maioria das empresas, a experiência com a marca termina aí.

E este é o problema. Grandes marcas são poderosas porque sua relação com as pessoas é emocional, não apenas racional. Mais importante, elas vêm da entrega sistemática de todos os aspectos dos 4Ps, começando com os produtos (ou serviços). Conexões genuínas com os clientes não podem ser apenas algo jogado na missão da empresa. Se seu produto ou serviço não cumpre a promessa da marca, seu nome e logotipo não fazem diferença. Pense na maior parte dos ‘estouros’ da última geração de marcas online, YouTube, Facebook, FlickR, MySpace. Eles não fizeram sucesso porque gastaram milhões em propaganda ou porque tiveram ótimos logotipos. Eles entregaram uma experiência de produto consistente. O mesmo vale para as maiores marcas online que as precederam: Google = busca, Amazon = compra online, eBay = compra e venda de outras pessoas.

Uma marca não é uma coisa única; é o conjunto de todas as formas com que uma empresa atinge seus clientes – na web, em anúncios, em press releases, em vendas, em varejo, e nos próprios produtos – que cria ou reforça uma marca. É por isso que novos logos ou nomes não resolvem os problemas da empresa; eles normalmente não são o problema.

Então se você tem uma marca com aspirações de se tornar uma das grandes, o que você deve fazer?

1. Comece com seu produto / serviço.

Em tecnologia, você não pode ter uma grande marca se seu produto ou serviço também não for grande. Isto não significa que deve ser o produto mais surpreendente do planeta – somente aquilo que é e faz deve ser fácil de entender, consistente em sua apresentação, e atender a uma necessidade que as pessoas se lembrem ou valorizem. É fácil olhar para uma empresa como a NetFlix e dizer, “Todos conhecem o envelope vermelho. É uma marca brilhante.” Mas foi seu serviço bem feito que tornou a marca viável e bem sucedida.

2. Seja consistente.

Depois de ter um bom produto, esta é coisa mais importante que você pode fazer, e fazê-lo não trará dinheiro adicional, apenas disciplina. Qualquer coisa que tenha contato com o cliente é parte da marca e, ou reforça a imagem que você quer transmitir, ou a torna indigna de confiança. Esta é um dos grandes fracassos entre as empresas de tecnologia; elas deixam as cores e o logo consistentes em todo lugar, mas não garantem que todo o resto do conteúdo e do produto suportem a marca.

A recente redução de preço do iPhone da Apple é um exemplo. Estrategicamente, um preço alto no lançamento foi uma decisão de negócios – limitava a distribuição enquanto bugs eram corrigidos, e deu aos early adopters, instantaneamente, um objeto de desejo. Mas quando a Apple reduziu o preço tão rapidamente para, essencialmente, o mesmo telefone, deixou seus clientes fiéis enraivecidos. A Apple fez parecer com que estivesse explorando seus fãs mais fiéis, o que é totalmente inconsistente com a imagem populista de “poder para as pessoas”. Vale ressaltar que a Apple rapidamente procurou solucionar este problema.

3. Observe a experiência completa do cliente.

Tudo aquilo que que aparece para o cliente deve incorporar a marca, para que ocorra um efeito de marca. Da linguagem à identidade visual, a como as pessoas se comportam – ou até como elas se vestem – tudo tem impacto. Uma startup que conheço definiu um atributo chave para sua marca como “liderança” e trabalharam duro para garantir que tudo que fizessem validasse isso. Sua lista de clientes-alvo inicial era a Fortune 100, só para que as marcas de seus clientes pudessem reforçar sua alegação de liderança. Seus funcionários também se vestiam de maneira formal ao visitar clientes. Diziam-lhes que em situações de vendas competitivas, tinham mais classe que os concorrentes, e esta percepção era reforçada por suas roupas. Eles se comportavam como líderes, mesmo quando não eram. É claro que eles tinham produtos que suportavam a marca, mas tudo criava um efeito de marca e um momentum que lhes ajudou a se tornarem líderes imbatíveis em sua categoria.

De novo, a Apple é a rainha na tecnologia de se utilizar toda a experiência do cliente para reforçar sua marca, desde as embalagens elegantes até a falta de documentação, até os ‘gênios’ no Bar dos Gênios das lojas da Apple – o simples fato de terem as lojas – suas propagandas, e, claro, seus produtos consistentemente marcantes.

4. Não subestime o poder das pessoas, fotos e músicas.

Esta é a maneira mais fácil de mover algo do racional para o emocional. Estas propagandas do Mastercard “que não tem preço levaram isso ao extremo. A VW usa músicas brilhantemente em seus comerciais; a BMW fez uma série inteira de filmes curtos. Mas vocês não precisa gastar milhões na TV ou anúncios em filmes para colocar emoção em sua marca. Pessoas se conectam com pessoas. Pense sobre como humanizar a experiência de sua marca – por exemplo, colocando uma foto de um vendedor ou atendente de suporte dizendo “Fale comigo agora!”. Citações de pessoas reais ou clientes são outro exemplo. Ter um cliente real pegando o telefone e ligando para um cliente potencial é um poderoso reforço de marca. E certamente, caso você tenha força de vendas direta, eles são são principais emissários da marca.

5. Separe a marca da empresa dos nomes de produtos e serviços.

Muitas empresas de tecnologia colocam seu investimento em marca atrás de um produto individual, ou nomeiam a empresa com o mesmo nome do produto. Este pode ser um bom começo, mas assegure-se de se adaptar rapidamente conforme seus negócios ou produtos se adaptam. A recomendação é tão simples quanto Oracle Databaes 11, em vez de apenas Oracle 11, ou Yahoo! Search em vez de apenas Yahoo!

Este tipo de estratégia de marca é conhecido como uma estratégia “master brand” e significa 1) você investe no significado da marca de sua empresa, não em seus produtos individualmente 2) como o nome da empresa carrega uma promessa para o cliente, precede o nome de cada produto ou serviço. É a forma mais comum de criar marcas e nomes em produtos de tecnologia, em que os há mudanças muito rapidamente.

Muito freqüentemente as empresas não fazem esta distinção rápido o suficiente. Não apenas isso deixa as coisas confusas para os clientes, mas também pode colocar seu negócio numa posição difícil de mudar. Pense em quantos anos, milhões de dólares e aquisições a Oracle precisou para deixar de ser apenas uma empresa de bancos de dados. E a Netscape, que nunca definiu uma marca além do browser, e assim, quando o browser entrou em declínio, toda a empresa foi vista como estando em declínio. Não cometa este erro.

6. Seja paciente – mantenha-se estável.

Construir uma marca leva muito mais tempo do que você possa querer, mesmo que você adote as melhores técnicas e tudo vá perfeitamente bem. É verdade que algumas marcas alcançam o reconhecimento no mercado de massas mais rapidamente do que outras, mas mesmo as mais rápidas levam anos antes de atingir o conhecimento da massas de clientes.

Quanto mais os elementos da marca da empresa mudarem neste período, menos o cliente conseguirá fixar e entender exatamente do que se trata a empresa. Considere que a cada vez que alguma parte da experiência de marca muda, você está recomeçando seu relacionamento com alguns de seus clientes. E se o objetivo final de uma marca é criar um atalho para a tomada de decisão do cliente, mudanças tiram este potencial.

7. Novas marcas são OK pelas razões certas.

Se sua penetração de marcado está sabidamente associada à bagagem existente de sua marca, então faz sentido optar por uma mudança. Meu exemplo favorito é o XBox da Microsoft. Eles precisavam de uma nova marca para os jogadores que fosse distinta da bagagem da Microsoft porque, vamos encarar, eles não tinham sintonia com os jogadores. O Halo 3 também é apresentado como sua própria marca, e não como Microsoft Halo. Levou uma década para a Microsoft parar de tentar “Microsoft Home” e outras extensões da marca quando finalmente resolveram adotar uma nova. Sem dúvida foi uma batalha com a polícia de marca corporativa, mas, em última análise, era necessário para a linha de produtos e para a marca terem sucesso.

Grandes marcas criam lealdade além do racional – porque um vínculo emocional e uma experiência consistente criam um atalho para a tomada de decisão. Em última análise, as marcas dizem respeito à confiança – que é difícil de conquistar, e fácil de perder. Assim, ao tratar de marcas, pense sobre todos os aspectos de sua marca para que ela ajude sua empresa a alcançar seus objetivos.

Por: By Martina Lauchengco

Pare de juntar requisitos

Se você quer ser um mau Gerente de Produtos, colete requisitos. De que outra forma você irá saber o que colocar no produto se não perguntar aos outros? Entreviste clientes atuais, pergunte quais são seus requisitos e assegure-se de documentá-los. Afinal, é isso que significa ser “focado no cliente” – responder a qualquer pedido dos clientes. Assegure-se de coletar requisitos dos stakeholders internos também. Faça uma lista de funcionalidades solicitadas pela área de suporte, marketing, vendas e pelos executivos da empresa. Se você reunir os requisitos de todas as pessoas corretas, você certamente terá um produto bem sucedido, certo?

Se você quer ser um bom Gerente de Produtos, entenda as necessidades não percebidas e use este insight para orientar os requisitos. Um Gerente de Produtos que apenas “coleta requisitos” não está fazendo nada além de anotar pedidos ou documentar solicitações. Bons Gerentes de Produto agregam valor a seus produtos entendendo os problemas e necessidades por trás dos pedidos.

Normalmente, a coleta de requisitos é uma atividade considerada fundamental em qualquer projeto. Esta mentalidade vem dos projetos tradicionais de tecnologia da informação, em que “o Cliente” que financiava o projeto parecia saber exatamente o que era necessário, e um “analista” documentava os requisitos. Colete os requisitos, documente-os, obtenha aprovação e o produto final irá atender às necessidades do cliente – esta era a teoria.

É claro, esta teoria falha, pois os “clientes” geralmente não sabem exatamente o que querem e raramente conseguem entender ou articular aquilo que realmente precisam. Eles podem ter um imagem precisa das necessidades óbvias, embora freqüentemente não reconheçam os problemas básicos e nem estão em posição de conhecer a melhor solução. Por exemplo, um cliente pode pedir uma pequena mudança num processo de 10 passos, embora alguém em posição de analisar melhor o problema pode perceber uma forma de reduzí-lo para três passos, ou até mesmo eliminar o processo.

Além disso, coletar requisitos de pessoas ou grupos diferentes levará inevitavelmente a requisitos conflitantes. Um tipo de usuário final pode querer uma interface simples, tipo Google, na página inicial, outro pode preferir várias funções de busca avançadas; um departamento interno quer usar a home Page para promover as novidades do produto, enquanto outro quer divulgar outras soluções da empresa. Estes requisitos são impossíveis de serem implementados simultaneamente, então, o mero ato de coletar requisitos não lhe deixa numa situação melhor do que a que você estava antes. Além disso, ao coletar ‘requisitos’ de cada grupo, você gerará frustração para cada um quando eles perceberem que seus ‘requisitos’ não foram, e jamais poderão, ser implementados.

Um Gerente de Produtos – ou qualquer um – que esteja apenas focado em “coletar requisitos” perde o valor maior que seu papel pode trazer. De forma simples, não há valor em um Gerente de Produtos que apenas colete requisitos. O Gerente de Produtos deve agregar valor através de insights e entendimento, tomando decisões sobre as prioridades e o foco. Aqueles que apenas coletam requisitos apenas documentam; o Gerente de Produtos deve:

  • Definir a visão para o produto: Quais clientes e stakeholders internos são importantes para o sucesso do produto?
  • Priorizar as diferentes necessidades dos clientes: Quando as necessidades conflitam, as de quem são as mais importantes?
  • Determinar quais necessidades serão e quais não serão implementadas: Isso se encaixa com a visão e a estratégia do produto?

Bons Gerentes de Produto não simplesmente coletam requisitos— eles entendem as necessidades não atendidas, os problemas existentes, as oportunidades para melhoria, e então eles usam esta informação para determinar os requisites de seu produto.

Esta é uma tradução do conteúdo escrito por Jeff Lash (http://www.jefflash.com/) no How To Be A Good Product Manager (http://www.goodproductmanager.com/)

7 Lições Óbvias do Lançamento de um Produto

Alguns dias atrás, minha startup, HubSpot, lançou um novo aplicativo chamado Press Release Grader. Não é nosso produto principal, mas uma ferramenta gratuita para marketeiros e assessores de imprensa analisar um press release e proverem sugestões.

O lançamento foi excepcionalmente bom para nós (com isso, quero dizer, que a taxa de adesão à comunidade é bem maior do que esperávamos). Eu colocaria algumas estatísticas aqui, mas a ferramenta e suas estatísticas não são o foco do artigo, mas sim as coisas que aprendi ao colocá-la no ar.

Aviso: como mencionado no título, tenho uma leve queda pelo óbvio, e gosto de focar nos fundamentos (o que é uma forma educada de dizer que você provavelmente não irá aprender nenhuma lição muito inovadora aqui!)

7 Lições Óbvias do Lançamento de um Produto

1. Não é cedo demais para lançar: Sua mesmo um fã do mantra “lance cedo, lance freqüentemente”. Mas, mesmo assim às vezes me rendo à mentalidade “deixe-me fazer só mais um pouquinho antes de lançar o produto”. Eu poderia ter lançado o produto algumas semanas antes, e é isso mesmo que eu deveria ter feito!

2. Esteja pronto para iterar: I intentionally cleared my schedule of other major distractions so I could focus on the software and iterate, iterate, iterate. In the days after the release/launch, I iterated like crazy with multiple production updates a day. Not a day should go buy that the software doesn’t get better for the users. Continue this as long as you can (maybe even weeks and months).

3. Disponibilize um mecanismo simples para feedback: Você não precisa de nada muito elaborado. Apenas um lugar para que os usuários cliquem num link, teclem seu feedback e enviem para você. Só isso.

4. Responda ao feedback: Isto remete ao item #2. Você deve estar pronto para consertar os bugs “óbvios” e incluir as melhorias com base no s comentários dos usuários (desde que façam sentido). A mágia da resposta imediata ao usuário é subestimada. Alguns blogs notáveis escreveram sobre o Press Release Grader simplesmente por causa da resposta rápida.

5. Registre o máximo de dados que você puder: Para um produto web, eu sugeriria que, no mínimo, você guarde todos os dados padrão da web (isto pode ser feito com alguma ferramenta análitica web) + quaisquer “inputs” que os usuários estejam provendo.

6. Não desperdice tempo programando relatórios: Embora você deva monitorar e armazenar o máximo de dados de uso do sistema que você possa, não gaste ainda tempo criando relatórios bonitos (ou mesmo feios). Apenas capture os dados. Um mecanismo simples para ter noção do uso do sistema, mas não tente criar todas as maneiras de olhar os dados que você está coletando. É uma distração. Foque naquilo que deixará os clientes felizes. Você pode trabalhar nos relatórios depois.

7. Veja se espalhar, acompanhe de perto: Você deve gastar metade de seu tempo não apenas programando, mas também promovendo. Isto inclui observar por quem o produto está sendo usado pela web, e quem está escrevendo sobre ele. Quando as pessoas escrevem sobre ele, agradeça e ofereça-se para fazer algo a respeito de suas idéias e feedback. Isto funciona mesmo. Mesmo se você tiver o luxo de ter pessoas da área de marketing, RP, etc. observando, mantenha-se envolvido. Nada substitui estar “plugado” na comunidade.

Sobre o ponto #7, aqui vao alguns lugares que eu monitoro para ver o que está sendo dito: Google (principalmente os blogs), Twitter, delicious, StumbleUpon e digg. (Tenho uma boa vontagem pois tenho ferramentas internas que me ajudam com este trabalho).

Que lições você aprendeu ao lançar seu produto para o que o mundo real passasse a utilizá-lo? O que você repetirá, e o que mudará da próxima vez?

Como ter o pior Beta jamais visto

Se você responde pela gerência de produtos, especialmente numa empresa pequena, você pode acabar tocando um programa beta. É uma atividade tática, e fará você se envolver em qualificação de usuários, feedback, administração e possivelmente suporte, mas há o lado bom de um bom programa de testes beta. Ou você pode falhar miseravelmente caso não entenda que há diferentes modalidades de beta, e diferentes motivações e objetivos em cada uma.

Um dos maiores problemas que enfrentei com um teste beta foi que há vários tipos de beta. Demorou bastante para que eu percebesse, então, espero poder resumir o processo de aprendizado para você. Alguns tipos de beta são:

  • Beta Pós-Alfa – este é o que a maior parte das pessoas pensa quando diz “beta”. Um teste final para encontrar bugs, e fazer ajustes finais antes de colocar a versão em produção. Dependendo do tamanho da empresa, do modelo de vendas e outros fatores, você pode ter “release candidates” que resultam do beta, ou várias iterações de código beta.
  • O Beta de Vendas – O pessoal de vendas precisa vender a uma funcionalidade na próxima versão, então oferece como beta para depois fazer a venda.
  • O Beta do Google – Um beta que não termina nunca. O Gmail ainda é beta depois de tantos anos… será?
  • BAN (Beta apenas no nome) – Seu ciclo de desenvolvimento passou do tempo, você não terá tempo para um bom beta, e você não poderá mudar a data de lançamento. Torça para que seu QA seja bom!
  • Ainda falta para o Beta – O oposto do BAN, seu código não está pronto, mas seus beta testers estão, então, você dá algo para eles que seria melhor descrito como Alpha e eles se assustam.

Você nunca deve querer um ‘BAN’ ou um ‘Ainda falta para o Beta’, e a boa notícia é que a Gerência de Produtos controla estas datas, ou deveria. O Beta de Vendas é o pior, pois o pessoal de vendas sempre promete que o usuário trará um bom feedback e será um ótimo participante do programa – não acredite, eles estão mentindo. O que acaba acontecendo é que o pessoal de vendas se esquece de dizer que o produto era beta, o usuário recebe o produto, e ficam ambos confusos ou bravos que o produto não está pronto ainda. Isto certamente é uma receita para o fracasso.

O beta do Google é interessante, pois ter um produto num beta perpétuo é bastante conveniente. Não gosta daquele bug? Desculpe, é beta – não está vendo a imagem no topo do site que diz isso? Isso pode servir para produtos gratuitos ou sustentados por anúncios, mas duvido que um cliente pagante irá aceitar um produto para sempre em beta.

Que outros tipos de beta você conhece?

Desenvolvimento de Software Ágil / baseado em Scrum e Gerência de Produtos

Acho que este é o único blog sobre Gerência de Produtos em toda a blogosfera que ainda não teve pelo menos um post sobre o desenvolvimento de software ágil ou baseado em Scrum. Isto é… até agora!

Nem sei dizer se era uma decisão consciente de algum de nós. Há tantas outras coisas boas e relevantes sobre as quais podíamos escrever como iPhones e iPods, por exemplo.
Mas, sério, acho que nunca escrevemos sobre Ágil antes porque, e falo por todos nós aqui, não é algo tão crítico para a Gerência de Produtos. Pronto, falei!

NOTA: quando eu utilizar “Ágil”, implica uma combinação de metodologias ágeis e Scrum

Se você não está familiarizado com desenvolvimento de software Ágil, ou baseado em Scrum, você pode ler mais em diversos sites na Internet. Um bom ponto de partida, como é de se esperar, é a Wikipedia. Leia sobre ambos, metodologias Ágeis e metodologias Scrum . Embora bem diferentes em diversos aspectos, é importante entender a ambos, Ágil e Scrum, e como são relacionados na prática. De fato, a primeira linha da descrição de Scrum na Wikipedia diz:

Scrum é um processo iterativo incremental de desenvolvimento de software normal mente utilizado com desenvolvimento de software Ágil.

Embora não seja uma definição absoluta, e, claramente, alguns podem querer discutir, vejo Ágil mais como uma cultura ou abordagem ao desenvolvimento de software, enquanto o Scrum é mais verdadeiramente um metodologia, com papéis específicos, práticas, etc. que podem ser implementadas. Em muitos casos, quando as pessoas dizem Ágil, elas querem dizer Scrum também. Como mencionei antes, o Scrum define um conjunto de papéis. Um dos papéis principais no Scrum é o Product Owner. Este papel é definido como:

O Gerente de Produtos representa a voz do cliente. Ele garante que o time de Scrum trabalha com as coisas certas, sob uma ótica de negócios. O Gerente de Produtos escreve histórias de usuário, prioriza-as e coloca-as no backlog do produto.

Este seria o Gerente de Produtos na maior parte das empresas de software. Embora verdade em alto nível, outro elemento chave do Scrum é a reunião diária de Scrum, da qual cada membro do time, incluindo o Product Owner, participa.

Agora imagine se você, como Gerente de Produtos, tivesse que participar de uma reunião todos os dias. Quando sairia do escritório? Quando se encontraria com clientes, parceiros, prospects, etc.?

Um grande erro que muitas pessoas fazem é assumir que o Product Owner precisa ser o Gerente de Produtos. Embora conceituamente isso possa ser verdade, o Gerente de Produtos não pode, e, na minha opinião, não deve, participar destas reuniões diárias. Trabalhei no papel de Gerente de Produtos em duas empresas antes que usavam metodologias de desenvolvimento Ágeis, e acho que participei apenas de uma reunião de Scrum. Ainda assim eu mantinha comunicação freqüente com os times de desenvolvimento, e revisões regulares do produto, etc., mas não estava envolvido com o processo de desenvolvimento como algumas pessoas acham que deveria estar.

Outros papéis tais como o Designer de Produto precisam ser definidos para tomar as decisões do dia-a-dia e atuar como Product Owner, ou, no mínimo, ser um proxy para o Product Owner (caso este seja o Gerente de Produtos), para que o Gerente de Produtos não fica tão ocupado com as reuniões diárias de Scrum.

Tenha em mente, Ágil/Scrum é uma metodologia de DESENVOLVIMENTO. É um ótimo modelo para desenvolvedores e engenheiros e outros membros do time de P&D trabalharem e se comunicarem de forma mais eficiente. Há benefícios muito claros neste modelo. Prove maior visibilidade do status atual do trabalho, de quanto falta para terminar, pode identificar os problemas do desenvolvimento com maior antecedência e pode comunicá-los para fora mais rapidamente. Deve ter impacto mínimo no trabalho de coordenador o produto entre as áreas de marketing, vendas, etc. do Gerente de Produtos.

Aqui vai uma analogia. O time de vendas invariavelmente segue algum tipo de metodologia de vendas. Pode ser venda estratégia, venda de soluções, ou venda conceitual. Pode ser algum outro modelo, ou até mesmo nenhum modelo. Se o time de vendas decide adotar ou mudar a metodologia de vendas, outros times, como Marketing ou Gerência de Produtos devem mudar sua forma de trabalhar? A resposta é NÃO. Então, porque quando estas mudanças deveria ocorrer caso o time de desenvolvimento adote Ágil/Scrum? Nosso trabalho continua o mesmo. Entender o mercado, os clientes, concorrentes, mesclar isso com os objetivos do negócio, etc. definir o que precisa ser construído e acompanhar que todos os estágios de desenvolvimento/lançamento/pós-lançamento que permitem o sucesso do produto.

Se, em alguns anos, alguma metodologia melhor de desenvolvimento surgir, e for adotada pelos times de engenharia, isso mudará o que o Gerente de Produtos faz? NÃO!

Metodologias de desenvolvimento devem ser uma caixa cinzenta para o Gerente de Produtos. Devemos compreendê-las, mas não precisamos ser parte integrante de sua implementação. É uma questão de acoplamento fraco e linhas claras de comunicação. Temos nossos objetivos, e o time de desenvolvimento tem os seus, e, quando precisamos interagir, o fazemos de maneira eficiente e mutuamente conveniente.

Colocando de outra maneira, e perdão pela analogia um pouco inapropriada. Gerencia de Produtos e Desenvolvimento não precisam estar casados para serem eficientes. O relacionamento precisa ser mais como um acordo de “amigos com benefícios”, i.e., os dois saem juntos de acordo com a necessidade.


Switch to our mobile site