Continuamos a falar sobre as principais qualidades de um gerente de produto bem-sucedido, de acordo com a equipe de produtos Wrike. No sexto (!) Parte desta série, falaremos com Anton Stozhko. Anton trabalha como gerente de produto associado há 1,5 anos, onde se mudou da equipe de Suporte ao Cliente.
- Olá Anton! Sugiro começar imediatamente com uma pergunta-chave: quais são, na sua opinião, as três principais qualidades de um gerente de produtos que deseja ter sucesso em seu papel?
- O ponto mais alto é a capacidade de planejar e priorizar. Plano e prioridade não são tanto o gerenciamento de produtos, mas a cultura pessoal ou mesmo a higiene. O plano é importante porque ajuda a combater o desconhecido, e poucos que o amam e a maioria tenta evitá-lo. Mas se você deseja desenvolver um negócio, precisa lidar com isso. E a prioridade é importante, porque nunca haverá recursos para fazer tudo completamente (boas notícias - isso não é necessário). O principal é fazer a coisa mais importante no devido tempo.
- E como você pode desenvolver essas habilidades? É possível dizer que eles vêm de um senso de responsabilidade pelo que está acontecendo na sua equipe e nos seus negócios?
"Bem, certamente não por tudo o que acontece, mas apenas pelo que está na sua área de responsabilidade." Você pode desenvolvê-los, como todo o resto - através da repetição. Uma pequena ressalva: é difícil aprender a planejar bem até você se tornar um produto. A necessidade desta ou daquela atividade não é particularmente visível, o valor real não é claro. Wrike me sacudiu com força aqui: percebi que não havia tanto tempo pessoal quanto pensei, e a lista de tarefas priorizadas tende ao infinito. Ainda tenho diante de meus olhos uma fila de solicitações no Suporte, onde comecei.
Para desenvolver essas habilidades, você precisa tentar aplicar esses princípios a absolutamente tudo o que acontece. Casos para o dia, planos de férias, respostas a mensagens de três ou quatro canais, planos de equipe para o trimestre. Em seguida, você precisa aprender como transferir habilidades para as atividades de outras pessoas: nas equipes e em seu planejamento, nos gerentes de produto e em sua visão.
Percebi que um ímpeto legal para o planejamento e a priorização dá a capacidade de primeiro imaginar um "estado perfeito". Quando as coisas são feitas, as decisões são tomadas, os recursos são resolvidos, as métricas são alcançadas. Uma vez que o estado ideal se formou na cabeça em um determinado momento, você pode começar a relaxar a bola.
- E como relaxar?
- Fazendo perguntas, é claro. Esta é apenas a segunda habilidade essencial - a capacidade de fazer perguntas a si e aos outros: “O que você precisa para que isso aconteça?”, “O que está faltando?”, “O que é incompreensível para uma pessoa sem um contexto?”. Perguntas grandes e desarticuladas retrocedem em perguntas pequenas e específicas. Mais uma vez, não responda tudo de uma vez. Lembre-se do primeiro princípio.
A importância da capacidade de fazer perguntas provavelmente está escrita em todos os livros sobre o produto, mas há um grande foco na pergunta "Por quê?". Não vou argumentar - a pesquisa com clientes é um tópico útil, mas outras questões não são menos importantes. As partes interessadas geralmente estão interessadas em “o que e quando?”, A equipe está interessada em “por que e em que ordem?”. Todos estão interessados em “o que e por quê?”.
A peculiaridade do trabalho do produto é que, no seu bolso, nem sempre há mais respostas do que perguntas. Mas o desejo de receber respostas é o segredo da luta contra a rotina.
- Em que medida são formuladas as tarefas nas quais você precisa trabalhar como produto de um fornecedor como parte de uma estratégia? Você transmite apenas uma visão geral ou algumas coisas mais específicas? Por exemplo, é a situação típica quando eles se voltam para você: "Queremos que esta parte do produto seja assim". E então você junta uma equipe e diz: "Pessoal, faça desta maneira".
- Eu tenho uma metáfora favorita sobre o martelo e a bigorna. Aqui o produto vive onde se encontra e as faíscas voam. O martelo é um movimento de cima para baixo. Aqui, visão de alto nível, estratégia e OKRs e, às vezes, tarefas muito específicas. Os insights são gerados de diferentes formas, com diferentes graus de importância e sofisticação. Todos esses são desejos. Bigorna é um movimento de baixo para cima. Esta é a base de código, os recursos, o humor das pessoas da equipe, as prioridades atuais e os planos existentes. É uma realidade. Onde os desejos encontram a realidade, é preciso gerenciar ambos.
Portanto, a resposta para a pergunta: "Como isso acontece?" - "De maneiras diferentes!"
Acontece que você desenrola uma idéia de um gerente de topo e passa a entender que há potencialmente um grande valor em algum tipo de fluxo. Minha tarefa é identificar esse valor, entender como integrá-lo ao fluxo de trabalho e verificar se ele não interfere nas tarefas prioritárias existentes.
Acontece que uma tarefa muito específica é executada e precisa ser executada.
A propósito, no sentido profundo, uma tarefa definida diretamente de uma idéia, insight ou estratégia é distinguida apenas pelo grau de aproximação e sofisticação.
- E me diga, por favor, qual é a diferença entre um produto e um produto associado no contexto do Wrike?
- Primeiro de tudo, este é o nível de decisões que você toma. Veja: eu vim e me tornei gerente de produto associado, e meu gerente me diz: "Vamos agendar para que as agências de marketing que usam Wrike se sintam bem" (refiro-me ao recurso "Calendários" no produto Wrike). E eu respondo: “Bem, se os vimos, eles deveriam ser assim. Deve haver filtros, a capacidade de criar um link externo para compartilhamento e muito mais. ” Descrevo os detalhes de um recurso que ainda não existe, mas o próprio recurso é vendido. Para alguma coisa, obtenho aprovação e em algum lugar respondo a perguntas adicionais.
Ao mesmo tempo, como o recurso funcionará e por que é necessário - todos entendem. Portanto, nesta fase, você obtém uma tarefa na forma: "Vamos lá, faça isso". O gerenciamento operacional da equipe fica com você, preenchendo a lista de pendências. Este não é o componente principal do produto, mas um excelente ponto de partida.
Preencha backlog muitos sabem como. Não há nada complicado em escrever como um recurso deve funcionar quando você o cria e depois conversar com os desenvolvedores. Tudo o que se segue é uma questão de avaliação e planejamento.
Tudo o que eu descrevi é o nível inicial. No próximo estágio da tomada de decisão, você já tem outras perguntas. Não "qual recurso será?", Mas "o que devo fazer?" Esta é a pergunta que me fiz quando comecei a trabalhar no Blueprints (nota - um dos novos recursos do produto). Ninguém me disse: "Faça Blueprints e decida o que serão". Me disseram: “Há um problema com o trabalho recorrente. O que vamos fazer?
Depois vem o terceiro nível de tomada de decisão. Aqui eles não mais designam um problema para você, mas dizem: "Achamos que talvez haja um problema em algum lugar aqui". E sua tarefa já está encontrando um problema.
- Ou seja, no terceiro nível, você começa destacando o problema, propondo uma solução e trazendo tudo até o fim?
Sim. E para mim já parece um trabalho de graduação. Quando você fez a pesquisa, entendeu tudo, conversou com todos, fundiu sua visão com a realidade, mostrou tudo a todos, convenceu todos de tudo. Para resumir, em cada estágio você sempre recebe algum tipo de introdução. A questão é como eles são definidos. E a cada novo nível de tomada de decisão, o horizonte do imenso está se tornando mais amplo.
Entendi. Você disse que no nível de projeto, ele já trabalhava no segundo nível de tomada de decisão e no terceiro na solução do problema de integração. Existe um quarto, quinto nível e assim por diante? Ou ainda existe um fim?
- Provavelmente a quarta é quando você tem um grupo de gerentes de produto. O trabalho em uma equipe de scrum deixa de ser sua rotina e você tem uma nova equipe que consiste em produtos. Cada um deles tem algum tipo de visão e problema que eles estão tentando resolver. E sua tarefa se torna um gerenciamento eficaz de desejos com as realidades de cada um desses produtos.
Ou seja, em essência, o dimensionamento vai além: o número de horizontes que precisam ser abraçados aumenta. Isso é possível graças à delegação. E neste quarto nível, você precisa garantir que aqueles que estão no terceiro local venham até você com essas propostas e apresentações, com base nas quais você pode tomar uma decisão ou dar conselhos para que a roda gire.
- bom Vamos voltar à pergunta original. Você já mencionou planos, priorização e capacidade de fazer perguntas. E qual, na sua opinião, é a terceira qualidade para um gerente de produto bem-sucedido?
- Como meu mentor gosta de dizer: "O único recurso do produto são as relações com outras pessoas", ou seja, a comunicação.
- E como parte da habilidade de comunicação, com quais problemas você tem que lidar diariamente?
- No nível diário, existem dois problemas comuns: falta de comunicação e falta de comunicação. As informações não são recebidas em quantidades suficientes ou são transformadas em malignas. Como resultado, movimentos extras são feitos e alguns processos são interrompidos. A correção de ambos é um custo extra.
Esses problemas podem ser relevantes em qualquer nível. Apenas quanto mais alto o nível, mais cara é a correção. Um exemplo dentro de um comando scrum: um funcionário não estava no plano e as informações não foram transmitidas a ele ou o produto foi prescrito de forma tortuosa. Tudo pode acontecer. Como resultado, o sprint tem uma tarefa para a qual nem todas as etapas foram concluídas para que possam ser levadas ao desenvolvimento. Suponha que seu desenvolvimento seja bastante simples: eles o implementam e, em seguida, verifica-se que ele começou a ser feito muito cedo ou não precisava ser feito. O próximo nível de diversão é o gerenciamento de comunicação entre equipes ou departamentos.
- Gostaria de fazer algumas perguntas. Diga-me, por favor, seu histórico inicial é original ou não?
- não. Eu nunca escrevi uma linha de código na minha vida. Bem, talvez no BASIC em uma aula de ciência da computação na 6ª série, 100 anos atrás. No meu trabalho, este não é um fator-chave.
- Muitas pessoas discordam dessa questão. Você acha que ter uma formação técnica o ajudará a se tornar um melhor gerente de produtos?
"Isso ajudará você a enfiar o nariz nos assuntos de seus desenvolvedores." Se isso os ajuda, então isso é uma vantagem. Se isso impedir que você ou você faça seu trabalho com mais rapidez e eficiência, isso é um sinal de menos. De qualquer forma, o produto não é um lobo solitário. Adoro o ditado de Game of Thrones: quando chega o inverno, o lobo solitário morre, mas o bando sobrevive. É sobre o valor do jogo em uma equipe. Não preciso saber JavaScript, mas eles precisam saber como preencher um resumo de compras.
- Se você não entende completamente um tópico, faz perguntas à sua equipe e toma decisões com base nas respostas deles?
- É exatamente isso que está acontecendo. Estou convencido de que estamos fazendo a coisa mais importante agora e sei quanto custa. Devo sempre ter em mente e correlacionar a complexidade com o resultado.
Isso é definido em cada etapa por um sistema peculiar de saldos, no qual você deve verificar se é muito caro executar essa etapa em relação ao valor que sairá dela e se você não perdeu uma etapa da qual pode obter muito valor e ao mesmo tempo fazer é barato. O ponto importante aqui é que eu determino a quantidade de valor obtido - esse é o meu saldo. E quanto custa, os desenvolvedores pesam. Comunicamos e determinamos qual o passo a ser seguido.
- Ou seja, a seguinte situação é possível: você realiza pesquisas e encontra um ponto em que o valor é enorme. Então você vem e fornece o problema ou solução descrito, e os desenvolvedores dizem que o peso é muito grande e incomensurável. Então você pode recusar mais trabalho nessa decisão, certo?
- Em tal situação, toda a esperança é para os desenvolvedores, porque o valor da unidade não pode ser alterado. Mas talvez haja uma chance de alterar o custo unitário.
Geralmente, tudo se resume a como você formula o problema. Você pode dizer: "Precisamos garantir que a subtarefa de repetição possa ser copiada na tarefa de repetição". E você pode ir um pouco do outro lado: "Estamos tentando resolver um problema quando há uma subtarefa e precisamos fazê-lo para que ele seja criado e lembrado com alguma regularidade na tarefa pai".
As tarefas declaradas parecem muito semelhantes. Mas, no primeiro caso, digo aos desenvolvedores que eles precisam reparar o mecanismo existente de tarefas repetitivas e, no segundo caso, não faço essa restrição. E também semântica. Não é "necessário", mas "nós". Funciona bem para encontrar um problema, e como resolvê-lo é a área de responsabilidade da equipe. Essa é a liberdade criativa e a possibilidade de auto-realização.
- E se eles propõem várias soluções para o problema, quem estima o melhor? Timlide?
Eu agradeço. Além disso, se não compreendo qual solução é mais eficaz, isso significa que não fiz as perguntas necessárias à equipe. Aliás, isso me leva a um tópico muito importante - sobre a equipe. É importante colocar a equipe acima da meta.
Em certos casos, é claro, exceções podem ser feitas. Se, por exemplo, for definido um prazo muito rígido, do lado de fora: desenvolvimento urgente para um grande cliente, uma liberação para um parceiro estratégico, com quem você precisará sincronizar a saída de integração e assim por diante. Então nós apenas precisamos nos sentar e fazê-lo.
Mas, na maioria das vezes, você percebe que o prazo final é um pouco menor do que o trem indo para a reunião. Então você precisa escolher o lado da equipe. No Wrike, eu realmente sinto isso, porque é mais caro agitar uma equipe do que trocar um produto.