Category Archives: Leadership

How to turn a feature team into a product team?

Posted on by
Reply

After reading my last article on the differences between a feature team and a product team, one may realize how valuable a product team is and may ask herself what we need to do to turn a feature team into a product team. Well, that’s the topic of this article! \o/

Not all feature teams are ready or willing to turn into a product team

A product team is given a problem to solve and an outcome to achieve. The team has complete autonomy to decide how to solve the problem and achieve the outcome and is incentivized to do so as fast as possible. Ideally, the team has also the autonomy to define what problem to solve and what outcome to achieve.

Product teams have to achieve outcomes, not only deliver products and features. The products and features they deliver are means to generate results for the company that owns the product and to solve a problem or to address a need of the customer. This result for the company can be more revenue, lower costs, increase customer engagement, etc.

Some teams and people are not willing to be concerned about business results. They prefer to be told what to deliver and to work on delivering what was asked. In this case, they should look for places to work where being told what to do is the common practice. However, my understanding is that the number of places working this way is diminishing and soon it will be quite hard to find these places, the same way that today is very difficult to find places where Waterfall is the preferred software development process.

Some teams and people may be willing to be concerned about business results, but they are not equipped with the knowledge needed to understand the business in order to deliver business results. These people need to be educated on how the business works so they can devise ways to impact the business through technology.

The feature team is ready to turn into a product team

Ok, so you believe the feature team is ready to turn into a product team, i.e., the feature team is both willing to turn into a product team and has the necessary business understanding in order to impact it with technology, then it’s time to work on transitioning the feature team into a product team.

This transition should be considered under two perspectives:

  • business people: whenever business people bring new requests to a product team, the business people need to bring these requests in the format of problems to be solved and outcomes to be achieved. They should refrain from bringing solutions or, if bringing a solution, making it clear that it is a solution hypothesis, not a solution implementation request, and the product team has complete autonomy to come up with other solution hypotheses to be tested. It’s ok for people from business to participate in the solution discovery, but the contribution should come in the form of collaboration not mandate.
  • product team: the product team needs to be proactive in impacting the business. Whenever the team is asked to implement a certain solution, the team should ask what is the problem we are trying to solve with this requested solution and what are the outcomes expected. If the person who’s asking (business person, manager, C-level, founder) is not willing to answer, explain to her that if the product teams knows the problem to be solved and the outcome to be achieved, the team may be able to figure out solutions that may be faster to implement.

What if business people say that the team should only implement what was asked?

In some cases, it may happen that the business people are not willing to disclose the problem to be solved and the outcome to be achieved. They may simply say that they know what they are asking and the team must implement it. In this case, my strong recommendation is that the people from the product team look for another place to work unless they are willing to work as a feature team.

A product team is always given problems to solve and outcomes to achieve. The team has complete autonomy to figure out ways to solve the problem and to achieve the outcome as fast as possible. This autonomy is necessary because the product team has the necessary knowledge and experience in technology and digital product development to come up with the best solutions.

Ideally, the product team has also the autonomy to define what problem to solve and what outcome to achieve. That’s the ultimate stage of maturity of a product team. In this stage, the team understands a lot about the business in order to define with some input from business people what problems to focus on and what outcomes to achieve.

Summing up

  • Not all feature teams are ready or willing to turn into product teams. If not ready, we need to educate them on the business so they can devise ways to impact the business through technology. If not willing, probably we need to change the team to have people that want to deliver results to the business.
  • To make the transition, both business people and people in the product team have to collaborate. People from business should refrain from bringing solutions to be implemented and should instead bring problems to be solved and outcomes to be achieved. People from the product team should always ask what’s the problem to be solved and the outcome to be achieved whenever they are asked to implement something.
  • In some cases, it may happen that the business people are not willing to disclose the problem to be solved and the outcome to be achieved. They may simply say that they know what they are asking and the team must implement it. In this case, my strong recommendation is that the people from the product team look for another place to work unless they are willing to work as a feature team.
  • Ideally, the product team has also the autonomy to define what problem to solve and what outcome to achieve. That’s the ultimate stage of maturity of a product team. In this stage, the team understands a lot about the business in order to define with some input from business people what problems to focus on and what outcomes to achieve.
  • This autonomy is necessary because the product team has the necessary knowledge and experience in technology and digital product development to come up with the best solutions.

Digital product education, coaching, and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Como transformar um time de funcionalidades em um time de produto?

Posted on by
Reply

Depois de ler meu último artigo sobre as diferenças entre uma equipe de funcionalidades e uma equipe de produto, podemos perceber o quanto uma equipe de produto é valiosa e nos perguntamos o que precisamos fazer para transformar uma equipe de funcionalidades em uma equipe de produto. Bem, esse é o tema deste artigo! \o/

Nem toda equipe de funcionalidade está preparada ou disposta a se transformar em uma equipe de produto

Uma equipe de produto recebe um problema para resolver e um resultado para alcançar. A equipe tem total autonomia para decidir como resolver o problema e alcançar o resultado e é incentivada a o fazer o mais rápido possível. Idealmente, a equipe também tem autonomia para definir qual problema resolver e qual resultado alcançar.

As equipes de produto precisam alcançar resultados, não apenas entregar produtos e funcionalidades. Os produtos e funcionalidades que eles entregam são meios para gerar resultados para a empresa proprietária do produto e solucionar um problema ou suprir uma necessidade da cliente. Esse resultado para a empresa pode ser mais receita, redução de custos, aumento do engajamento do cliente, etc.

Algumas equipes e pessoas não estão dispostas a se preocupar com os resultados do negócio. Eles preferem que lhes digam o que entregar e trabalham para entregar o que foi pedido. Nesse caso, eles devem procurar por empresas onde receber instruções sobre o que fazer seja a prática comum. Contudo, tenho notado que o número de locais trabalhando dessa forma está diminuindo e em breve será difícil encontrar empresas assim, da mesma forma que hoje é muito difícil encontrar locais onde o Waterfall seja o processo de desenvolvimento de software preferido.

Algumas equipes e pessoas podem estar dispostas a se preocupar com os resultados de negócios, mas não estão equipadas com o conhecimento necessário para entender o negócio. Essas pessoas precisam ser educadas sobre como o negócio funciona para que possam criar maneiras de impactar o negócio por meio da tecnologia.

A equipe de funcionalidades está pronta para se transformar em uma equipe de produto

Ok, então você acredita que o time de funcionalidades está pronto para se tornar um time de produto, ou seja, o time de funcionalidade não só está disposto a se tornar um time de produto como também tem o entendimento de negócio necessário para impactá-lo com tecnologia. Então é hora de trabalhar na transição da equipe de funcionalidades para uma equipe de produto.

Essa transição deve ser considerada sob duas perspectivas:

  • pessoas de negócio: sempre que as pessoas de negócio trazem novas solicitações para uma equipe de produto, elas precisam trazer essas solicitações no formato de problemas a serem resolvidos e resultados a serem alcançados. Devem abster-se de trazer soluções ou, caso tragam uma solução, deixar claro que se trata de uma hipótese de solução, não de uma solicitação de implementação de solução, e o time de produto tem total autonomia para levantar outras hipóteses de solução a serem testadas. É normal que as pessoas da empresa participem da descoberta da solução, mas a contribuição deve vir sempre na forma de colaboração, não de imposição.
  • time de produto: o time de produto precisa ser proativo para impactar o negócio. Sempre que o time for solicitada a implementar uma determinada solução, o time deve perguntar qual é o problema que estamos tentando resolver com essa solução solicitada e quais são os resultados esperados. Se a pessoa que está perguntando (pessoa de negócios, gerente, C-level, founder) não estiver disposta a responder, explique a ela que se o time de produto souber o problema a ser resolvido e o resultado a ser alcançado, o time poderá descobrir soluções que podem ser mais rápidas de implementar.

E se as pessoas de negócios disserem que a equipe só deve implementar o que foi pedido?

Em alguns casos, pode acontecer que as pessoas de negócio não estejam dispostos a dizer qual o problema a ser resolvido e o resultado a ser alcançado. Eles podem simplesmente dizer que sabem o que estão pedindo e que a equipe deve se focar em implementar o que foi pedido. Nesse caso, minha recomendação é que as pessoas do time de produto procurem outro lugar para trabalhar, a menos que estejam dispostos a trabalhar como time de funcionalidades.

Um time de produto sempre recebe problemas para resolver e resultados para alcançar. A equipe tem total autonomia para descobrir formas de resolver o problema e chegar ao resultado o mais rápido possível. Essa autonomia é necessária porque a equipe de produto possui o conhecimento e a experiência em tecnologia e em desenvolvimento de produtos digitais necessários para chegar às melhores soluções.

Idealmente, o time de produto também tem autonomia para definir qual problema resolver e qual resultado alcançar. Esse é o estágio maior de maturidade de um time de produto. Nesta etapa, o time entende muito sobre o negócio para definir, com contribuições das pessoas negócios, em quais problemas focar e quais resultados alcançar.

Resumindo

  • Nem todas os times de funcionalidades estão preparados ou dispostos a se transformar em time de produto. Se não estiver pronto, precisamos educá-los sobre como funciona o negócio para que possam criar maneiras de impactar o negócio por meio da tecnologia. Se não estiver disposto, provavelmente precisamos mudar o time para ter pessoas que queiram entregar resultados para o negócio.
  • Para fazer a transição, tanto as pessoas de negócio quanto as pessoas do time de produto precisam colaborar. As pessoas de negócios devem abster-se de trazer soluções a serem implementadas e devem trazer problemas a serem resolvidos e resultados a serem alcançados. As pessoas do time de produto devem sempre perguntar qual é o problema a ser resolvido e o resultado a ser alcançado sempre que forem solicitadas a implementar algo.
  • Em alguns casos, pode acontecer que as pessoas de negócio não estejam dispostos a dizer qual o problema a ser resolvido e o resultado a ser alcançado. Eles podem simplesmente dizer que sabem o que estão pedindo e que o time deve implementar o que está sendo pedido. Nesse caso, minha recomendação é que as pessoas do time de produto procurem outro lugar para trabalhar, a menos que estejam disposto a trabalhar como time de funcionalidade.
  • Idealmente, o time de produto também tem autonomia para definir qual problema resolver e qual resultado alcançar. Esse é o estágio de maior maturidade de um time de produto. Nesta etapa, o time entende muito sobre o negócio para definir, com contribuições das pessoas de negócio, em quais problemas focar e quais resultados alcançar.
  • Essa autonomia é necessária porque o time de produto possui o conhecimento e a experiência em tecnologia e desenvolvimento de produtos digitais necessários para chegar às melhores soluções.

Educação, treinamento e aconselhamento em gestão de produtos digitais

Tenho ajudado empresas a conectar negócios e tecnologia por meio de educação, treinamento e aconselhamento em gestão e desenvolvimento de produtos digitais. Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Feature Team vs Product Team

Posted on by
Reply

I’ve already written about the difference between solution-implementing teams and problem-solving teams. I’ve also written about the #1 responsibility of a product manager, which is to deliver results as fast as possible.

However, as these are very important topics for any product person, for any product team, and for any company that has or wants to have product teams, I decided to prepare a table to clarify the differences between feature teams and product teams:

Differences between feature teams and product teams (click to enlarge)

So, what do you think? Is there any other feature that should be on this table?

In the article Why “business demands => technology implements” doesn’t work it is clear that Feature Teams will not generate the best results. To succeed in using technology to generate results for the company and for customers, we must have Product Teams.

What to do if you are in a company with a Feature Team? Is it possible to transition to Product Team? How to make this transition? That will be the topic of my next article!

Summing up

  • There are clear differences between a Feature Team and a Product Team. The differences are not only in the definition of what they are, but also in the role of the product manager, in the way prioritization is done, and in the main deliverables.

Digital product education, coaching and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Time de Funcionalidades vs Time de Produtos

Posted on by
Reply

Já escrevi sobre a diferença entre times implementadores de solução e times solucionadores de problemas. Também já escrevi sobre a responsabilidade nº1 de uma gestora de produtos, que é entregar resultados o mais rápido possível.

Contudo, como esses são temas muito importantes para qualquer pessoa de produto, para qualquer time de produto e para qualquer empresa que tenha ou queira ter times de produto, resolvi preparar uma tabela para deixar claras as diferenças entre times de funcionalidades e times de produto:

Diferenças entre Time de Funcionalidades e Time de Produto (clique para aumentar)

E aí, o que achou? Tem mais alguma característica que deveria estar nessa tabela?

No artigo Porque “negócios demanda => tecnologia implementa” não funciona está claro que o Time de Funcionalidades não vai gerar os melhores resultados. Para ter sucesso no uso da tecnologia para gerar resultados para a empresa e para os clientes devemos ter Times de Produto.

O que fazer se você está em uma empresa com Time de Funcionalidades? É possível fazer a transição para Time de Produto? Como fazer essa transição? Esse será o tema do meu próximo artigo!

Resumindo

  • Existem diferenças claras entre um Time de Funcionalidades e um Time de Produto. As diferenças estão não só na definição do que são, mas também na função da pessoa gestora de produtos, na forma como a priorização é feita, e nas principais entregas.

Educação, treinamento e aconselhamento em gestão de produtos digitais

Tenho ajudado empresas a conectar negócios e tecnologia por meio de educação, treinamento e aconselhamento em gestão e desenvolvimento de produtos digitais. Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter:Email

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

We deal with people’s money, we don’t have room for errors

Posted on by
Reply

When I talk about the release early and often behavior of successful product companies during in-company trainings or in-company talks, some people mention that their business is too risky and they don’t have room for errors. For instance, a bank that works with customers’ money, or a hospital that takes care of its patients’ health. They say that error is not acceptable and, for this reason, they cannot launch incomplete products. They have to launch a complete product that has all the minimum required features. Some people even say

“It’s easy for a startup, with no customers, to launch the very minimum (and embarrassing) first version of its product and evolve from there. We are a big company, we have hundreds of thousands of customers, and we cannot afford to make mistakes.”

And they are right, making mistakes in front of thousands of customers is not wise behavior.

Hack: alpha, beta, and go-live terminology

For this reason, I decided to use a hack to foster a digital product culture behavior of releasing early and often. The hack is the use of the alpha, beta, and go-live terminology. I started using this terminology to explain in which stage a product or a feature is. In the alpha stage, the product may not work properly. If it’s in alpha, it should be offered only to customers who understand the issues of using a new product and can cope with these issues without a bigger burden. So this should be a handful of clients, no more than that. At the beta stage, major issues of the product are fixed, but the errors may still occur and the user experience can and will improve. In this phase, it is possible to offer the product or feature to tens of customers. Then, when all known errors are fixed, and the user experience is working properly, then its time to move the product into the go-live stage, where the product can be offered to all prospects and existing clients. This certainly helps sales and customer support teams understand the release cycle of new features and new products.

I use the above slide to present this terminology to the company. Feel free to use it in your company. This slide was created by my dear friend Luis Figueira.

Slide explaining alpha, beta and go-live terminology

Workshop to Create the Vision and Strategy of your Product

Without the clarity of your product vision and strategy, it is very difficult, if not impossible, to manage your product. How do you decide where to put your focus and energy? What to leave for later? How to show stakeholders what you intend to do with the product? How to have arguments to say no to requests for new features in your product?

That’s why I created the Workshop to Create Your Product’s Vision and Strategy. Spaces are very limited and it starts next Monday, so reserve yours now!

Digital product education, coaching and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Lidamos com o dinheiro de nossos clientes, não podemos errar

Posted on by
Reply

Quando falo sobre entregas antecipadas e frequentes, prática comum de times de produto bem-sucedidos, durante treinamentos in-company ou palestras in-company, algumas pessoas mencionam que seus negócios são muito arriscados e não têm espaço para erros. Por exemplo, um banco que trabalha com o dinheiro dos clientes ou um hospital que cuida da saúde de seus pacientes. Dizem que erro não é aceitável e, por isso, não podem lançar um produto incompleto. Eles precisam lançar um produto completo que tenha todos as funcionalidades mínimas necessárias. Algumas pessoas até dizem

“É fácil para uma startup, sem clientes, lançar a primeira versão mínima (e constrangedora) de seu produto e evoluir a partir daí. Somos uma grande empresa, temos centenas de milhares de clientes, não podemos cometer erros.”

E eles estão certos, cometer erros na frente de milhares de clientes não é um comportamento sábio.

Hack: alfa, beta e go-live

Por esse motivo, decidi usar o que chamo de hack para promover e fortalecer a cultura de produtos digitais. Uso a terminologia alfa, beta e go-live para explicar em que estágio um produto ou funcionalidade está. No estágio alfa, o produto pode não funcionar corretamente. Se estiver em alfa, deve ser oferecido apenas para os clientes que entendem os problemas e eventuais erros do uso de um novo produto e podem lidar com esses problemas e erros sem maiores dificuldades. Portanto, a quantidade de clientes na fase alfa será pequena, no máximo uns 5, não mais do que isso. No estágio beta, os principais problemas do produto são corrigidos, mas os erros ainda podem ocorrer e a experiência do usuário pode e vai melhorar. Nesta fase, é possível oferecer o produto ou funcionalidade a dezenas de clientes. Depois, quando todos os erros conhecidos forem corrigidos e a experiência do usuário estiver funcionando corretamente, é hora de mover o produto para o estágio de go-live, onde o produto pode ser oferecido a todos os clientes existentes e em potencial. Isso certamente ajuda as equipes de vendas e de suporte ao cliente a entenderem o ciclo de lançamento de novas funcionalidades e novos produtos e em que estágio está o produto ou a funcionalidade.

Uso o slide abaixo para apresentar essa terminologia para a empresa. Fique à vontade para utilizar na sua empresa. Esse slide foi criado pelo meu bom amigo Luis Figueira:

Slide explicando a terminologia alfa, beta e go-live

Workshop para Criação da Visão e Estratégia do seu Produto

Sem a clareza da visão e da estratégia de seu produto é muito difícil, ou mesmo impossível, gerenciar seu produto. Como decidir onde colocar seu foco e energia? O que deixar para depois? Como mostrar para os stakeholders o que você pretende fazer com o produto? Como ter argumentos para dizer não para pedidos de novas funcionalidades em seu produto?

É por isso que criei o Wotrkshop para Criação da Visão e Estratégia de seu Produto. As vagas são muito limitadas e a próximo turma semana que vem, então garanta já a sua!

Educação, treinamento e aconselhamento em gestão de produtos digitais

Tenho ajudado empresas a conectar negócios e tecnologia por meio de educação, treinamento e aconselhamento em gestão e desenvolvimento de produtos digitais. Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter:Email

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

New product: in-company training

Posted on by
Reply

Now that I’m a full-time product leadership coach, I’ve managed to design a product that I believe will help many companies and their product development teams connect business and technology to generate more and more results for both the company and its customers. It’s in-company training.

It is tailor-made training. The topics that will be covered are defined together to meet the specific needs of each company. Training can range from a 2-hour session to 16 hours of training depending on the content to be covered. Longer sessions can be delivered in full-day face-to-face training sessions or divided into smaller 2 or 3-hour sessions, suitable for remote training.

In-company training at Contmatic

If you believe that this is a product that can be useful for your company, please contact me by email or WhatsApp.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Novo produto: treinamento in-company

Posted on by
1

Agora que sou coach de líderes de produto em tempo integral, consegui tirar da gaveta um produto que acredito que poderá ajudar muitas empresas e seus times de desenvolvimento de produto a conectarem negócios e tecnologia para gerar cada vez mais resultados tanto para a empresa quanto para seus clientes. É o treinamento in-company.

É um treinamento feito sob medida. Os tópicos que serão abordados são definidos em conjunto para atender às necessidades específicas de cada empresa. O treinamento pode variar de uma sessão de 2 horas até 16 horas de treinamento dependendo do conteúdo que será abordado. As sessões mais longas podem ser ministradas em sessões de treinamento presencial de dia inteiro ou divididas em sessões menores de 2 ou 3 horas, indicado para treinamentos remotos.

Treinamento in-company na Contmatic

Se você acredita que esse é um produto que pode ser útil para sua empresa, entre em contato comigo por email ou WhatsApp.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Product Operations

Posted on by
Reply

Product Operations, or POps as some people have called it, is a role that has appeared with some frequency in product development teams, especially in reasonably large teams with 150 or more people, including engineers, designers and product managers.

Definitions

Anyone who knows me knows how important I think some terms are clearly defined, to ensure that we have the same understanding when we are talking about this term. It is the ubiquitous language, a concept created by Eric Evans in his book Domain-Driven Design, which is the set of terms that must be fully understood by both domain experts (system users) and developers (system implementers).

Operations is one of those very broad and generic terms, which can have different meanings and represent different responsibilities, depending on the company, its culture and its context. However, in the different definitions that we can find on Google, we find as a common denominator that:

Operations is the day-to-day management (of the company or an area) and the search for the efficiency of the processes to generate value in that company or area.

Many companies have operations directors and even a person in top management with the title of COO, Chief Operating Officer. And many companies also have specific areas of operations for some company functions. Sales Ops, Marketing Ops, DevOps, Design Ops. All of them aim to help in the day-to-day management of their respective area and, consequently, help it to be more efficient.

Before being an area, it must be a need

Before we think about creating an area of ​​operations, we first need to understand the need that can culminate in the creation of this area. Usually this need appears when the company starts to grow in number of people. The more people a company has, the greater the chances of inefficiencies in the company’s day-to-day activities.

When a product development area (engineering, design and product management) is small, like 5 to 7 people, everything happens within the team. The team itself takes care of all aspects of the product. This team has a lot of autonomy and ability to generate results quickly and continuously. As the team grows, we tend to divide this team into smaller teams, to maintain autonomy and the ability to generate results quickly and constantly. On the other hand, this division of the big team into smaller teams also brings two points that require attention:

  • rework: with autonomous teams it can happen that different teams are working on similar topics, but because they are focused on their objectives, they do not perceive synergies and possible opportunities for efficiency gains.
  • misalignment: no matter how autonomous the teams are, they work within the same company and often focus on the same or complementary customers. Therefore, no matter how autonomous they are, the work of one team will eventually be influenced by the work of other teams. When teams are very autonomous, this influence can take time to be noticed, which will certainly have a negative impact on value creation, usually due to delays or impediments.

Once the problem is detected, solutions can be thought of. Often the solution can be for someone from one team to team up with someone from another team to create a solution to that problem. Once the solution is created and implemented, people continue to work in their original teams, and if there is a need for any improvement or adjustment to the solution, they can come together again to make this adjustment. If this need for improvement or adjustment in the solution becomes frequent, then we can think about dedicating someone to continuously focus on these needs for improvements and adjustments.

To help make these concepts tangible, here are some examples of timescale problems and how we solve these problems:

  • Design system: Locaweb’s product teams were quite independent, as each team took care of a specific product. We had one team taking care of the website hosting product, another one the email product, another one the webshop product, another one the reseller hosting product, and so on. This independence even made it possible for teams to use different programming languages. On the other hand, this independence created certain reworks. One of those reworks that we tackled first was the design of the interfaces for these products. Each product looked like it was made by a different company. That’s when we decided to create Locastyle, a front-end framework for behavior and style, that is, Locaweb’s Design System. It was developed as a side hustle of some design and engineering people and when there was maintenance, or a need to create a new component, these people would get together and make the necessary adjustments. There was no need to create a permanent team to take care of this issue. In Conta Azul, the creation of Mágica happened in the same way, but after it was created, we chose to have a designer person being a team of 1 person from DesignOps. This person, in addition to looking at the design system, also looked at the design processes, along with the head of the area. After some time, this Design Ops team grew to 2 people, with a UX Writer taking care of communication consistency. At Gympass, we set up a Design Ops team with a designer and a front-end that created and maintained Yoga. This team later grew with UX Writer taking care of the tone of voice and translations and Research Ops to coordinate research efforts made by more than one team with the same user. At Lopes there was also an effort, exercised part-time by the people of the design team, to create the Lopes design style guide.
  • Tools: at Locaweb we also saw several opportunities to centralize the development and maintenance of some tools. For example, all teams need authentication and authorization on their products, and several teams wanted to offer APIs for their products. Instead of each team doing its own authentication and authorization and its own API infrastructure, it made more sense to create a centralized one. With that in mind, we created a team of tools that had exactly this objective, to create tools for product teams to be more productive. We put two of our most senior developers on this team. We also created this team in the Azul account, with the name Foundation, but the path was a little different. One of the tribes, the one that took care of the sales registration and invoice issuance functionalities, decided to offer these functionalities as an API as well. So this tribe created the API infrastructure to put the endpoints they needed. This tribe would talk to tech leaders from the other tribes, show them what they were doing and gather feedback. When another tribe, which took care of financial functionality, also decided to make its functionalities accessible via API, we started to think about assembling a team to take care of this API infrastructure, and other needs of the product teams, in a centralized way, and we called this Foundation team.
  • Ideas portal: at a certain point, the Conta Azul GPMs started to bring to our weekly meeting the need to collect customer suggestions in a more structured way. Instead of each GPM collecting these suggestions independently, we decided to do it more centrally, since the customer was the same, regardless of which part of the product he was using. Then came the idea of ​​building an Ideas Portal exclusively for Conta Azul customers. Our purpose was to create something simple that only Conta Azul customers could access, make suggestions, view, comment and vote on other customers’ suggestions. The head product design person decided to take this initiative, looking for a market solution. With the help of a designer, he adjusted the layout and, with the help of a developer, made the integration with the customer authentication system of Conta Azul. Once the solution was implemented, maintenance was minimal, and no one dedicated was needed. When there was a need for some maintenance, someone would dedicate a few hours to that maintenance. I imagine that in a larger team, the construction and maintenance of an ideas portal like this could be taken care of by a Product Ops team, or even a Design Ops team. As well as a system for NPS research.
  • Data: at Locaweb, access to some business-related data was exclusive to the BI team, which was required to generate reports and insights and, obviously, had a prioritization queue. To avoid this bottleneck, since Conta Azul I have been working with teams in a culture of data democratization, that is, giving access to data to more people in the company so that everyone can generate their reports and insights from the data. At Conta Azul we implemented Metabase as a tool that allows for this democratization of data. I remember that when I had access to the Metabase of Conta Azul for the first time, I spent about 10 days going to sleep at 3:00 am, having fun building dashboards! We did the same at Gympass and Lopes. The implementation of this tool, connecting it to the company’s databases and maintaining it, giving access to people from the product development team and the entire company, and helping people to get to know and take better advantage of it has always been a responsibility of one of the structural teams that we had in these companies, the data team.
  • Quarterly OKRs: at Lopes we were organized into teams focused on each of the actors in our marketplace. We had a team focused on the end customer, another team focused on who is selling the property and a third team focused on who does the intermediation, the brokers. We also had the marketing team, focused on generating demand, and the central systems team, focused on the systems used internally. At the end of each quarter, these teams defined their OKRs for the next quarter. Although all teams work with the same focus of helping people to conquer their place, connecting them to the most appropriate property through the best broker, each team ended up looking at its main focus. So once the teams finished defining their OKRs, I would review and find overlaps and complementarities, align with the teams on those findings, and change the teams’ OKRs to take advantage of those overlaps and complementarities. it’s an alignment job, part of a product head person’s job description. We are talking here about 5 teams with an average of 3 to 5 goals per quarter, each with 3 to 5 key results, that is, 20 goals and 80 key results. Of course, with the number of teams greater and, consequently, the number of OKRs also greater, the need for coordination will be greater and may require someone dedicated more time to this alignment, which can be a Product Operations assignment.

It is worth mentioning some important points in relation to the examples above:

  • the initiatives were created and run by people with leadership experience and the ability to see the big picture, that is, senior people.
  • another important point to highlight is that, before thinking about creating a new area, we thought about how to solve the problem in question with the current teams, shifting a little effort from day to day to solve the problem.
  • only when the recurring need for maintenance and improvement of the initiative became clear, did we think about creating an area with this focus.
  • every new area should start with one or at most two people.
  • as this/these person/people is/are) showing results, reducing the rework of the teams and helping in their alignment, it may make sense to grow the area by adding more people.
  • with the evolution of this area, it may make sense to have a structure and mindset closer to those of a product development team, with product managers, engineers, and designers. In this case, the product manager will be creating products to solve problems and meet the needs of the product development teams.

Summing up

  • Product Operations, or POps as some people have called it, is a role that has appeared with some frequency in product development teams, especially in reasonably large teams with 150 or more people, including engineers, designers and product managers.
  • Operations is the day-to-day management (of the company or an area) and the search for the efficiency of the processes to generate value in that company or area.As the company grows, it ends up being subdivided into smaller areas and teams so that these areas can have autonomy and the ability to generate results quickly and constantly.
  • This division into smaller teams also brings up two points that require attention, rework and misalignment.
  • The solution to these points of attention may be the temporary effort of one or more people to create and implement solutions to these problems.
  • These solutions may eventually require more constant attention and maintenance, which may lead to the need to create a team (Design Ops, Tools/Foundation, Product Ops, etc.)

New dates for the Workshop to Create the Vision and Strategy of your Product

Without the clarity of your product vision and strategy, it is very difficult, if not impossible, to manage your product. How do you decide where to put your focus and energy? What to leave for later? How to show stakeholders what you intend to do with the product? How to have arguments to say no to requests for new features in your product?

That’s why I’m opening new dates for my Wotrkshop to Create Your Product’s Vision and Strategy. Spaces are very limited, so reserve yours now!

Digital product education, coaching and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Product Operations

Posted on by
Reply

Product Operations, ou POps como algumas pessoas tem chamado, é uma função que tem aparecido com certa frequência em times de desenvolvimento de produto, principalmente nos times razoavelmente grandes com 150 ou mais pessoas, dentre engenheiras, designers e gestoras de produto.

Definições

Quem me conhece sabe como acho importante alguns termos estarem claramente definidos, para garantir que temos o mesmo entendimento quando estamos falando desse termo. É a linguagem ubíqua, conceito criado por Eric Evans em seu livro Domain-Driven Design, que é o conjunto de termos que devem ser plenamente entendidos tanto por especialistas no domínio (usuários do sistema) como por desenvolvedores (implementadores do sistema).

Operações é um daqueles termos bem amplos e genéricos, que pode ter diferentes significados e representar diferentes responsabilidades, a depender da empresa, sua cultura e seu contexto. Contudo, nas diferentes definições que podemos encontrar no Google, encontramos como denominador comum que:

Operações é a gestão do dia-a-dia (da empresa ou de uma área) e a busca da eficiência dos processos de geração de valor dessa empresa ou área.

Muitas empresas têm diretoria de operações e até mesmo uma pessoa na alta gestão com o título de COO, Chief Operating Officer. E muitas empresas têm também áreas de operações específicas para algumas funções da empresa. Sales Ops, Marketing Ops, DevOps, Design Ops. Todas elas têm por objetivo ajudar na gestão do dia-a-dia de sua respectiva área e, consequentemente, ajudá-la a ser mais eficiente.

Antes de ser uma área, deve ser uma necessidade

Antes de pensarmos em criar uma área de operações, precisamos primeiro entender a necessidade que pode culminar na criação dessa área. Normalmente essa necessidade aparece quando a empresa começa a crescer em quantidade de pessoas. Quanto mais pessoas tem uma empresa, maiores são as chances de haver ineficiências no dia-a-dia dessa empresa.

Quando uma área de desenvolvimento de produtos (engenharia, design e gestão de produtos) é pequena, tipo 5 a 7 pessoas, tudo acontece dentro do time. O próprio time cuida de todos os aspectos do produto. Esse time tem bastante autonomia e capacidade para gerar resultados rápida e continuamente. À medida que o time cresce, costumamos dividir esse time em times menores, para manter a autonomia e a capacidade de gerar resultados rápida e constantemente. Por outro lado, essa divisão do time grande em times menores também traz dois pontos que requerem atenção:

  • retrabalho: com times autônomos pode acontecer de times diferentes estarem trabalhando em temas similares, mas por estarem focados em seus objetivos, não percebem as sinergias e eventuais as oportunidades de ganho de eficiência.
  • desalinhamento: por mais autônomos que sejam os times, eles trabalham dentro da mesma empresa e, muitas vezes, focados no mesmo cliente ou em clientes complementares. Por isso, por mais autônomos que sejam, o trabalho de um time vai eventualmente ser influenciado pelo trabalho dos outros times. Quando os times são muito autônomos, essa influência pode demorar para ser percebida, o que certamente vai impactar negativamente na geração de valor, normalmente devido a atrasos ou impedimentos.

Uma vez detectado o problema, pode-se pensar em soluções. Muitas vezes a solução pode ser alguém de algum time se juntar com alguém de outro time para criar uma solução para aquele problema. Uma vez criada e implementada a solução, as pessoas continuam trabalhando em seus times de origem e, se houver necessidade de alguma melhoria ou ajuste na solução, elas podem se juntar novamente para fazer esse ajuste. Caso essa necessidade de melhoria ou ajuste na solução passa a ser frequente, aí sim podemos pensar em dedicar alguém para focar continuamente nessas necessidades de melhorias e ajustes.

Para ajudar a tangibilizar esses conceitos, aqui vão alguns exemplos, de problemas de escala de time e como resolvemos esses problemas:

  • Design system: os times de produto da Locaweb eram bastante independentes, uma vez que cada time cuidava de um produto específico. Tínhamos um time cuidando do produto de hospedagem de sites, outro do produto de email, outro do produto de loja virtual, outro do produto de revenda de hospedagem e assim por diante. Essa independência possibilitava inclusive que os times utilizassem linguagens de programação diferentes. Por outro lado, essa independência criava certos retrabalhos. Um desses retrabalhos que resolvemos primeiro foi o design das interfaces desses produtos. Cada produto parecia que era feito por uma empresa diferente. Foi aí que decidimos criar o Locastyle, framework front-end de comportamento e estilo, ou seja, o Design System da Locaweb. Ele foi desenvolvido como um side hustle de algumas pessoas de design e de engenharia e quando havia manutenção, ou necessidade de criar algum novo componente, essas pessoas se juntavam e fazia os ajustes necessários. Não houve necessidade de criar um time permanente para cuidar desse tema. Na Conta Azul aconteceu da mesma forma a criação do Mágica, mas depois de criado, optamos por ter uma pessoa designer sendo um time de 1 pessoa de DesignOps. Essa pessoa, além de olhar para o design system, olhava também para os processos de design, junto com o head da área. Depois de algum tempo, esse time de Design Ops cresceu para 2 pessoas, com uma UX Writer cuidando da consistência de comunicação. No Gympass, montamos um time de Design Ops com um designer e um front-end que criaram e mantinham o Yoga. Esse time depois cresceu com UX Writer cuidando o tom de voz e traduções e Research Ops para coordenar esforços de pesquisa feitos por mais de um time com o mesmo usuário. Na Lopes tb houve um esforço, exercido part-time pelas pessoas do time de design, em criar o guia de estilo de design da Lopes.
  • Ferramentas: também na Locaweb enxergávamos várias oportunidades de centralizar o desenvolvimento e manutenção de algumas ferramentas. Por exemplo, todos os times precisam de autenticação e autorização em seus produtos, e vários times queriam oferecer APIs de seus produtos. Ao invés de cada time fazer sua própria autenticação e autorização e sua própria infra de APIs, fazia mais sentido criar uma centralizada. Pensando nisso criamos um time de ferramentas que tinha exatamente esse objetivo, de criar ferramentas para os times de produto serem mais produtivos. Colocamos nesse time dois de nossos desenvolvedores mais sêniores. Também criamos esse time na conta Azul, com o nome de Foundation, mas o caminho foi um pouco diferente. Uma das tribos, a que cuidava das funcionalidades de registro de venda e de emissão de NF, decidiu oferecer essas funcionalidades também como API. Então essa tribo criou a infra de API para colocar os endpoints que precisava. Essa tribo conversava com líderes técnicos das outras tribos, mostrando o que estava fazendo e colhendo feedback. Quando uma outra tribo, que cuidava das funcionalidade financeiras, decidiu também colocar sua funcionalidades acessíveis via API, começamos a pensar em montar um time para cuidar dessa infra de API, e de outras necessidades dos times de produto, de maneira centralizada, e chamamos esse time de Foundation.
  • Portal de ideias: em um certo ponto os GPMs da Conta Azul começaram a trazer em nossa reunião semanal a necessidade de colher sugestões de clientes de forma mais estruturada. Ao invés de cada GPM colher essas sugestões de forma independente, decidimos fazer isso de forma mais centralizada, uma vez que o cliente era o mesmo, independente de qual parte do produto ele estivesse utilizando. Surgiu então a ideia de construir um Portal de Ideias exclusivo para clientes da Conta Azul. Nosso propósito era criar algo simples que somente clientes do Conta Azul pudessem acessar, fazer sugestões, ver, comentar e votar nas sugestões de outros clientes. A pessoa head product design decidiu tocar essa iniciativa, buscou uma solução de mercado. Com ajuda de uma pessoa designer, ajustou o layout e, com a ajuda de uma pessoa desenvolvedora, fez a integração com o sistema de autenticação de clientes da Conta Azul. Uma vez a solução implementada, a manutenção era mínima, e não precisava de ninguém dedicado. Quando havia necessidade de alguma manutenção, alguém dedicava algumas horas para essa manutenção. Imagino que em um time maior, a construção e manutenção de um portal de ideias como esse poderia ser cuidado por um time de Product Ops, ou mesmo de Design Ops. Assim como um sistema para pesquisa de NPS.
  • Dados: na época da Locaweb o acesso a alguns dados era exclusividade do time de BI, que era demandado para gerar relatórios e insights e, obviamente, tinha uma fila de priorização. Para evitar essa gargalo, desde a época da Conta Azul tenho trabalhado com os times em uma cultura de democratização dos dados, ou seja, dar acesso aos dados para mais pessoas da empresa para que todos possam gerar seus relatórios e insights a partir dos dados. Na Conta Azul implementamos o Metabase como ferramenta que permite essa democratização dos dados. Lembro que quando tive acesso ao Metabase da Conta Azul pela primeira vez, passei uns 10 dias indo dormir às 3:00 da manhã, me divertindo construindo dashboards! Fizemos o mesmo no Gympass e na Lopes. A implementação dessa ferramenta, conectando-a as bases de dados da empresa e a manutenção dela, dando acesso às pessoas do time de desenvolvimento de produto e da empresa toda, ajudando as pessoas a conhecerem e a tirar melhor proveito sempre foi uma responsabilidade de um dos times estruturais que tínhamos nessas empresa, o time de dados.
  • OKRs trimestrais: na Lopes nós nos organizávamos em times focados em cada um dos atores de nosso marketplace. Tínhamos time focado no cliente final, outro focado em quem está vendendo o imóvel e um terceiro focado em quem faz a intermediação, os corretores. Também tínhamos o time de marketing, com foco na geração de demanda, e o de sistemas centrais, focado nos sistemas utilizados internamente. A cada final de trimestre esses times definiam seus OKRs para o próximo trimestre. Apesar de todos os times trabalharem com o mesmo foco de ajudar as pessoas a conquistarem o seu lugar, conectando-as ao imóvel mais apropriado através do melhor corretor, cada time acabava olhando para o seu foco principal. Por isso, assim que os times terminavam de definir seus OKRs, eu fazia uma revisão e encontrava sobreposições e complementaridades, alinhava com os times sobre esses achados, e mudava os OKRs dos times para que tirássemos proveito dessas sobreposições e complementaridades. é um trabalho de alinhamento, parte do job description de uma pessoa head de produto. Estamos falando aqui de 5 times com uma média de 3 a 5 objetivos por trimestre, cada um com uns 3 a 5 key results, ou seja, uns 20 objetivos e uns 80 key results. Com certeza, com o número de times maior e, consequentemente, a quantidade de OKRs também maior, a necessidade de coordenação será maior e pode requerer alguém dedicado por mais tempo a esse alinhamento, o que pode ser uma atribuição de Product Operations.

Vale ressaltar alguns pontos importantes em relação aos exemplos acima:

  • as iniciativas foram criadas e tocadas por pessoas com experiência em liderança e capacidade de enxergar o todo, ou seja, pessoas sêniores.
  • outro ponto importante a destacar é que, antes de pensar em criar uma nova área, pensamos em como resolver o problema em questão com os times atuais, deslocando um pouco de esforço do dia-a-dia para resolver o problema.
  • somente quando ficou claro a necessidade recorrente de manutenção e melhoria da iniciativa, pensamos em criar uma área com esse foco.
  • toda nova área deve começar com uma ou, no máximo, duas pessoas.
  • à medida que essa(s) pessoa(s) vai(ão) mostrando resultados, diminuindo o retrabalho dos times e ajudando no seu alinhamento, pode fazer sentido crescer a área colocando mais pessoas.
  • com a evolução dessa área, pode fazer sentido uma estrutura e um mindset mais próximos dos de um time de desenvolvimento de produto, com pessoas gestora de produto, pessoas engenheiras e designers. Nesse caso, a pessoa gestora de produtos estará criando produtos produtos para resolver problemas e atender necessidades dos times de desenvolvimento de produto.

Resumindo

  • Product Operations, ou POps como algumas pessoas tem chamado, é uma função que tem aparecido com certa frequência em times de desenvolvimento de produto, principalmente nos times razoavelmente grandes com 150 ou mais pessoas, dentre engenheiras, designers e gestoras de produto.
  • Operações é a gestão do dia-a-dia (da empresa ou de uma área) e a busca da eficiência dos processos de geração de valor dessa empresa ou área.
  • A medida que a empresa cresce, ela acaba se subdividindo em áreas e times menores para que essas áreas possam ter autonomia e a capacidade de gerar resultados rápida e constantemente.
  • Essa divisão em times menores também traz dois pontos que requerem atenção, retrabalho e desalinhamento.
  • A solução para esses pontos de atenção pode ser o esforço temporário de uma ou mais pessoas para criar e implementar soluções para esses problemas.
  • Essas soluções podem eventualmente requerer atenção e manutenção mais constante, o que pode originar a necessidade de criação de um time (Design Ops, Tools/Foundation, Product Ops, etc.)

Nova turma do Workshop para Criação da Visão e Estratégia do seu Produto

Sem a clareza da visão e da estratégia de seu produto é muito difícil, ou mesmo impossível, gerenciar seu produto. Como decidir onde colocar seu foco e energia? O que deixar para depois? Como mostrar para os stakeholders o que você pretende fazer com o produto? Como ter argumentos para dizer não para pedidos de novas funcionalidades em seu produto?

É por isso que estou abrindo a segunda turma do meu  Wotrkshop para Criação da Visão e Estratégia de seu Produto. As vagas são muito limitadas, então garanta já a sua!

Educação, treinamento e aconselhamento em gestão de produtos digitais

Tenho ajudado empresas a conectar negócios e tecnologia por meio de educação, treinamento e aconselhamento em gestão e desenvolvimento de produtos digitais. Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter:Email

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente: