This is an expression that we normally say when the family of a skilled or knowledgeable person is often the last to benefit from her expertise.
One of the topics I talk about most with my clients, to the point that I launched a workshop on the subject (link in Portuguese), is the importance of having a clearly defined vision and strategy so that I can define OKRs.
Although I now work alone, I decided early on to use vision, strategy, and OKRs tools to help me daily. To show that here the shoemaker’s family does benefit from his experience, here are the vision and strategic objectives of Gyaco, my consultancy and training company on product management and digital transformation:
Gyaco VisionGyaco strategic objectives
OKRs
As the company is just me, that is, I’m responsible for doing everything in my company (marketing, sales, finance, billing, operations, customer service, and providing the service to my customers), I figured I wouldn’t need OKRs.
However, while helping a client build their OKRs, I decided to try building my own OKR spreadsheet, which is the one below.
Gyaco’s OKRs for 2023Chart with the evolution of Gyaco’s OKRs
I built this spreadsheet during the week of January 23rd, and it was eye-opening. I started the year well, with almost all OKRs in green. The ones that weren’t in green were in yellow, meaning they were close to where I wanted them to be. However, the following week the scenario changed, with yellows increasing and some reds appearing. The following week, between Jan 7th and Jan 15th, was a week off that I took. When I got back from my week off and decided to do the OKRs spreadsheet, I saw that things weren’t the way I wanted, and I put energy into improving that, which we can see in the following week.
Even if you are a one-person company or a few people, OKRs derived from your vision and your strategic objectives are a very useful tool to help you get where you want to be.
Summing up
It is common to happen as in that phrase that says that at the shoemaker’s house, his family always goes barefoot”; that is, the family of a skilled or knowledgeable person is often the last to benefit from her expertise.
At my company, Gyaco, I tried to ensure that the family had shoes; that is, I designed the vision and strategic objectives as soon as I decided to follow this path of being a full-time product coach and advisor.
However, I still wasn’t using one of my favorite tools, OKRs, because I didn’t think a one-person company needed them. After a conversation with a client about this tool, I decided to apply it in my one-person company, which proved to be very useful!
Digital product training, coaching, and advisory
I’ve been helping companies bridge the gap between business and technology through training, 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:
Startup Guide: How startups and established companies can create profitable digital products
Product Management: How to increase the chances of success of your digital product
Essa é uma frase comum que usamos quando queremos dizer que uma pessoa é hábil em determinada coisa, mas não usa essa habilidade a seu favor.
Um dos temas que mais falo com meus clientes, ao ponto de eu ter lançado um workshop sobre o tema, é sobre a importância de ter visão e estratégia claramente definidos, para com isso poder definir os OKRs.
Apesar de agora eu trabalhar sozinho, decidi desde o princípio usar as ferramentas de visão, estratégia e OKRs para me ajudar no dia-a-dia. Para mostrar que aqui na casa de ferreiro o espeto é de ferro, aqui estão a visão e os objetivos estratégicos da Gyaco, minha empresa de consultoria e treinamento em gestão de produtos e transformação digital:
Visão0 GyacoObjetivos estratégicos Gyaco
OKRs
Como a minha empresa hoje sou só eu, ou seja, eu cuido de marketing, vendas, financeiro, cobrança, operações, suporte eprover o serviço aos meus clientes, imaginei que não ia precisar de OKRs.
Contudo, ao ajudar um cliente a construir seus OKRs, resolvi experimentar construir minha própria planilha de OKRs, que é a que está abaixo.
OKRs GyacoGráfico de evolução dos OKRs
Eu construi essa planilha na semana do dia 23 de janeiro, e foi revelador. Comecei o ano bem, com quase todos os OKRs em verde. Os que não estavam em verde estavam em amarelo, ou seja, próximos de onde eu queria que estivessem. Contudo, já na semana seguinte o cenário mudou, com amarelos aumentando, e aparecendo alguns vermelhos. A semana seguinte foi de uma semana off que eu tirei. Quando voltei de minha semana off, e resolvi fazer a planilha de OKRs, vi que as coisas realmente não estavam como eu queria, e coloquei energia em melhorar isso, o que dá pra ver na semana seguinte.
Mesmo se vc for uma empresa de uma pessoa só, ou de poucas pessoas, OKRs vindos de sua visão e seus objetivos estratégicos, são uma ferramenta muito útil para te ajudar a chegar aonde você quer chegar.
Resumindo
É comum acontecer como naquela frase que diz que “em casa de ferreiro, o espeto é de pau”, ou seja, uma pessoa ser hábil em determinada coisa, mas não usar essa habilidade a seu favor.
Na minha empresa, a Gyaco, eu busquei garanti que o espeto fosse de ferro, ou seja, desenhei a visão e os objetivos estratégicos assim que decidi trilhar esse caminho de ser consultor de produtos em tempo integral.
Contudo, eu ainda não estava usando uma das ferramentas que mais gosto, os OKRs, por achar que uma empresa de uma única pessoa não precisa. Após uma conversa com um cliente sobre essa ferramenta, resolvi aplicá-la na minha empresa de uma pessoa, e ela se mostrou muito útil!
Treinamento, aconselhamento e consultoria em gestão de produtos digitais
Tenho ajudado empresas a conectar negócios e tecnologia por meio de treinamento, aconselhamento e consultoria 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:
During my 30+ years leading teams in technology companies, I have seen and felt the effects of some crises and recessions. According to Wikipedia, since 1990, there have been 4 US recessions, the most recent being COVID-19 in early 2020. According to the Recession Probability Model by The Conference Board, a global non-profit research organization about future scenarios, we are on the verge of another recession:
US Recession Probability Model by The Conference Board
Downsizing and layoffs are commonly used tools in times of crisis and recession. They seem to be used more in technology companies, as these types of companies tend to move and adapt faster. Tech companies seek capital from investment funds to accelerate their growth, but when a crisis strikes, they need to readjust very quickly. However, downsizing and layoffs are not exclusive to technology companies. Tyson Foods, one of the largest US meat companies, and Goldman Sachs, a global financial market company, also announced layoffs at the turn of the year.
Even in favorable economic scenarios, crises can happen due to internal reasons. It’s possible that some decisions did not prove right, which can cause a company crisis without any influence from the economic scenario. A well-known example is Enron Corporation, one of the world’s leading energy distribution and communications companies, which earned US$ 101B in 2000 and, in 2001, filed for bankruptcy due to accounting and tax fraud and a debt of US$ 13B. More recently, we have the case of Americanas. This large Brazilian retail company started 2023 in crisis for failing to record a BRL 20B debt in its audited balance sheets.
As I explained in the article “Product Management in a Crisis“, companies must analyze two perspectives when they realize that they are entering a crisis:
preserve cash;
identify and adapt to changes in customer problems and needs.
To preserve cash, we should look at the most common causes. We should aim to preserve or even advance revenue streams while looking at all costs with a magnifying glass. In this cost analysis, the downsizing and layoff tools that we see being applied in many technology companies and non-technology companies, such as the examples I mentioned above (Tyson Foods and Goldman Sachs), come into play.
How to analyze and plan a layoff in a product development team
Throughout my career, I’ve been through some crises and had to make decisions to reduce the team. More recently, as an advisor, I have also been helping some product heads and CEOs with their layoff decisions and planning.
I will not go into the people management aspect of this process here, as there are many good articles on this topic, giving details of what to do and what not to do. In this regard, my recommendation is to use empathy to define the best way to act. If I were fired, how would I want to be treated? If I wasn’t fired and stayed at the company that went through a layoff, how would I react to the layoffs and how would I like to be treated? Always work very closely with the people management team. It is not uncommon to have people on this team with a background in psychology, which can help a lot in this planning.
In this article I will talk about the part of the layoff process related to planning to reduce the product development team. How to decrease the team? Should I just reduce the amount of people in all squads and keep the same amount of squads? Or should I think about dismantling some squads? Here are my recommendations:
If you are the main leader of the product development team, or if you share that leadership with a CTO person, I recommend that you do not design the plan alone. Call your direct reports, share with them the need for a team reduction, and start working together on this plan. It is important that your direct reports participate, as they have more knowledge and, consequently, the ability to go into greater detail in the planning. You may wonder if you have leaders with this degree of maturity, which is a relevant concern. It is usually situations like this that help a professional to mature. So if any of them aren’t mature enough, this may be a good maturing opportunity.
Instead of just making a single reduction plan, design scenarios. If the need is to reduce by 40%, try drawing scenarios with less and more reduction, for example, 10%, 20%, 30%, 40%, and 50%. In these designed scenarios, it is important to make the impacts clear in addition to the reduction achieved. A good way to make impacts clear is with OKRs. In each scenario, which objectives will not be achieved and results will not be reached?
Start by planning reductions of the vacancies. It is common to have open vacancies of two types, new vacancies for new teams that we plan to set up to run new initiatives or to reinforce existing teams and replacement vacancies to replace people who have left. Plan to reduce new vacancies first. Then the replacement ones.
If the reduction or elimination of open positions is not enough for the necessary reduction, you should start thinking about reducing the current teams. A very common mistake that I see some people make is to reduce the size of the teams but maintain the number of teams, hoping to be able to continue running all the current initiatives, to reach all defined OKRs, but with fewer people and, consequently, at a slower pace. This is not a good idea. As we say in Portuguese, this is the famous “short blanket problem”. If you cover your head, you uncover your feet. This is the time to prioritize. Which squads can we not dismantle because they are critical to the product’s operation? Which squads were betting on new initiatives, features, and products that we can pause? Is there any initiative, functionality, or product that is not giving the expected results and does not show that it will generate the expected results?
Design the various reduction scenarios and analyze how many new initiatives are cut in each one that, in times of crisis, can be suspended and how many vital needs for the operation of your product are cut. How do these scenarios impact achieving the product vision and executing the product strategy? Which OKRs will be impacted? Which objectives will not be reached and which key results will not be achieved? This is an important prioritization exercise that, along with the different scenarios, will not only allow you and your direct leaders to see the impact of the reductions on the team, but it is also a great tool for you to present to the CEO and other leaders of the company, showing what different levels of reduction can impact on the company as a whole. In this conversation with the CEO and other leaders of the company, you can decide which is the best – or the least bad – scenario to follow.
Example of analysis and planning of a layoff in a product development team
I will use a hypothetical case to illustrate this example, where I will show the scenery design tool.
The crisis arrived and, after careful analysis of the numbers, you, as the leader of your company’s product development area, reached the conclusion, or received a request from the CEO, that a layoff will be necessary, that is, you will have to reduce the size of the team and will have to make some layoffs. The reduction will need to be 40% of your budget.
You lead a team of 200 people, with a current team of 180 people plus 20 vacancies. Of these 20 vacancies, 10 are new vacancies and 10 are replacement vacancies. The 180 people are divided into 4 product tribes plus 2 structural team tribes as shown below. The 10 new vacancies are to form 2 new squads, the Worf squad in the Star Trek tribe, and the Integrations squad in the Central Systems tribe.
Example of a team with 200 people in 4 product tribes and 2 structural tribes
This team of 200 people is focused on achieving 20 objectives and their key results (OKRs). After conversations with your direct reports, and following the steps described above, you can create the following scenarios.
Example of team reduction scenarios and impact of reductions
I’ve used this scenario table in a few situations in my career, and I’ve recommended it to product heads, engineering heads, and CEOs who do advisory sessions with me. With these scenarios in hand, you can now talk to the CEO and other company leaders to show the impact of the reduction, as well as alternatives for smaller reductions with also smaller impacts on the productivity of the product development team, so that you can evaluate the options.
Having fewer people will cause the team to drop some balls, meaning you have to make a decision on what to stop doing. Some objectives and expected key results should be deprioritized, as we will have to lay off some people and we will have a smaller team. It’s that simple. Less money implies a smaller team, which implies less things that this team can do and, consequently, less objetives can be achieved and key results can be achieved.
Summing up
Crises happen with some frequency. In 2020 we experienced the COVID-19 crisis. By early 2023 we may be heading into a recession. And even without an external crisis, companies may have made decisions that were not right.
When a crisis happens, we have to preserve cash.
One of the ways to preserve cash is to reduce the size of the product development team, that is, to downsize and layoff.
When analyzing and planning the layoff, we must design scenarios that allow us to understand the impact of each scenario on achieving the product vision and executing the product strategy. A good way to make impacts clear is with OKRs. In each scenario, make it clear which OKRs will be impacted.
Digital product training, coaching, and advisory
I’ve been helping companies bridge the gap between business and technology through training, 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:
Startup Guide: How startups and established companies can create profitable digital products
Product Management: How to increase the chances of success of your digital product
Durante meus mais de 30 anos liderando times em empresas de tecnologia, já vi e senti os efeitos de algumas crises e recessões. De acordo com a Wikipedia, desde 1990 foram 4 recessões nos EUA, sendo a mais recente a da COVID-19 no início de 2020. De acordo com o modelo de probabilidade de recessões da The Conference Board, uma organização global sem fins lucrativos de pesquisa sobre cenários futuros, estamos na beira de mais uma recessão:
Modelo de Probabilidade de Recessão nos EUA, da The Conference Board
Downsizing e layoffs são ferramentas comumente utilizadas em momentos de crise e recessão. Elas aparecem mais em empresas de tecnologia, pois essas tendem a se movimentar e se adaptar mais rápido. Empresas de tecnologia buscam capital de fundos de investimento para acelerar seu crescimento mas, quando uma crise aparece, precisam se readequar muito rápido. Contudo, downsizing e layoffs não são exclusividade das empresas de tecnologia. A Tyson Foods, uma das maiores empresas de carnes dos EUA, e a Goldman Sachs, empresa global do mercado financeiro, também anunciaram layoffs nessa virada de ano.
Mesmo em cenários econômicos favoráveis, crises também podem acontecer por motivos internos. Decisões tomadas que não se mostraram acertadas podem causar uma crise em uma empresa, sem qualquer influência do cenário econômico. Um exemplo bastante conhecido é o da Enron Corporation, uma das empresas líderes no mundo em distribuição de energia e comunicações, que faturou U$ 101Bi em 2000 e, em 2001, devido a fraudes contábeis e fiscais e a uma dívida de U$ 13Bi, pediu concordata. Mais recentemente temos o caso da Americanas, grande empresa do varejo brasileiro, que está em crise nesse início de 2023 por deixar de registrar em seus balanços auditados uma dívida de R$ 20Bi.
identificar e adaptar-se às mudanças nos problemas e necessidades dos clientes.
Para a primeira perspectiva, preservar o caixa, devemos olhar para as causas mais comuns. Devemos buscar preservar ou até mesmo avançar os fluxos de receita enquanto analisamos todos os custos com uma lupa. É nessa análise dos custos que entram as ferramentas de downsizing e layoffs que estamos vendo serem aplicadas em muitas empresas de tecnologia e também em empresas não de tecnologia como os exemplos que comentei acima (Tyson Foods e Goldman Sachs).
Como analisar e planejar um layoff em um time de desenvolvimento de produto
Ao longo de minha carreira, já passei por algumas crises e tive que tomar decisões de redução de time. Mais recentemente, como advisor, tenho também ajudado alguns heads de produto e CEOs em suas decisões e planejamentos de layoff.
Não vou entrar aqui na parte de gestão de pessoas desse processo, pois existem muitos artigos bons sobre esse tema, dando detalhes do que fazer e do que não fazer. Nesse aspecto, minha recomendação é usar a empatia para definir a melhor maneira de agir. Se eu fosse demitido, como eu gostaria de ser tratado? Se eu não fosse demitido e ficasse na empresa que passou por um layoff, como eu reagiria às saídas e como eu gostaria de ser tratado? Trabalhe sempre muito próximo do time de gestão de pessoas. Não é incomum ter pessoas nesse time com formação em psicologia, o que pode ajudar bastante nesse planejamento.
Nesse artigo vou falar sobre a parte do processo de layoff relacionado com o planejamento da redução do time de desenvolvimento de produto. Como diminuir o time? Devo somente reduzir a quantidade de pessoas em todos os squads e manter a mesma quantidade de squads? Ou devo pensar em desmontar alguns squads? Aqui vão minhas recomendações:
Se for o principal líder do time de desenvolvimento de produto, ou se dividir essa liderança com uma pessoa CTO, minha recomendação é que você, ou vocês no caso de liderança compartilhada, não desenhe o plano sozinho. Chame seus reportes diretos, compartilhe com eles a necessidade de redução, e comecem a trabalhar juntos nesse planejamento. É importante que seus reportes diretos participem, pois têm mais conhecimento e, consequentemente, capacidade de entrar em maior detalhamento no planejamento. Você pode estar se questionando se você tem líderes que tenham esse grau de maturidade, o que é uma preocupação relevante. Normalmente são situações como essa que ajudam um profissional a amadurecer. Então se algum deles ainda não for maduro o suficiente, talvez essa seja uma boa oportunidade de amadurecimento.
Ao invés de só fazer um único plano de redução, desenhem cenários. Se a necessidade é de reduzir em 40%, experimentem desenhar cenários com menos e mais redução, por exemplo, 10%, 20%, 30%, 40% e 50%. Nesses cenários desenhados, além da redução atingida, é importante deixar claros quais os impactos. Uma boa forma de deixar claro os impactos é com os OKRs. Em cada cenário, quais objetivos deixarão de ser atingidos e quais resultados deixarão de ser alcançados?
Comecem planejando as reduções pelas vagas abertas. É comum termos vagas abertas de dois tipos, as vagas novas, para times novos que planejamos montar para tocar novas iniciativas ou para reforçar times existentes, e vagas de reposição para substituir pessoas que saíram. Planejem reduzir primeiro as vagas novas. Em seguida, as vagas de reposição.
Caso a redução ou eliminação das vagas em aberto não seja o suficiente para a redução necessária, vocês deverão começar a pensar em redução dos times atuais. Um erro bastante comum que vejo algumas pessoas fazerem é reduzir o tamanho dos times mas manter a quantidade de times, na expectativa de conseguir continuar tocando todas as iniciativas atuais, só que com menos pessoas e, consequentemente, de forma mais lenta. Essa não é uma boa ideia, É o famoso problema do cobertor curto, se cobrir a cabeça, descobre os pés. Esse é o momento de priorizar. Quais squads não podemos desmontar por serem críticos para a operação do produto? Quais squads eram apostas em novas iniciativas, funcionalidades e produtos que podemos pausar? Existe alguma iniciativa, funcionalidade ou produto que não está dando os resultados esperados e que não mostra que vai dar os resultados esperados?
Desenhem os vários cenários de redução e analisem o quanto é corte de novas iniciativas que, em momentos de crise, podem ser suspensas, e o quanto é corte de necessidades vitais para a operação do seu produto. O que cada um desses cenários impacta no atingimento da visão de produto e na execução da estratégia de produto? Que OKRs serão impactados? Quais objetivos não serão atingidos e quais resultados-chave não serão alcançados? Esse é um exercício de priorização importante que, junto com os diferentes cenários, vai permitir não só que você e seus líderes diretos vejam o impacto das reduções no time, como também é uma ótima ferramenta para você apresentar para a pessoa CEO e outras lideranças da empresa, mostrando o que diferentes níveis de redução podem impactar na empresa como um todo. Nessa conversa com a pessoa CEO e outras lideranças da empresa você podem tomar a decisão de qual o melhor, ou o menos pior, cenário a seguir.
Exemplo de análise e planejamento de um layoff em um time de desenvolvimento de produto
Vou utilizar um caso hipotético para ilustrar esse exemplo, onde vou mostrar a ferramenta de desenho de cenários.
A crise chegou e, após análise cuidadosa dos números, você, como líder da área de desenvolvimento de produto da sua empresa, chegou a conclusão, ou recebeu um pedido da pessoa CEO, de que será necessário um layoff, ou seja, você terá que diminuir o tamanho do time e terá que fazer algumas demissões. O redução terá de ser de 40% do seu orçamento.
Você lidera um time de 200 pessoas, sendo o time atual de 180 pessoas, mais 20 vagas. Dessas 20 vagas, 10 são novas vagas e 10 são vagas de reposição. As 180 pessoas estão divididas em 4 tribos de produto mais 2 tribos de times estruturais conforme o desenho abaixo. As 10 novas vagas são para formar 2 novos squads, o squad Worf na tribo Star Trek, e o squad Integrações na tribo de Sistemas Centrais.
Exemplo de time com 200 pessoas em 4 tribos de produto e 2 tribos estruturais
Esse time de 200 pessoas está focado em atingir 20 objetivos e seus resultados-chave (OKRs). Após as conversas com seus líderes, e seguindo os passos acima descritos, você poderá criar os seguintes cenários.
Exemplo de cenários de redução de time e impacto das reduções
Já usei essa tabela de cenários em algumas situações em minha carreira, e já a recomendei para heads de produto, de engenharia e CEOs que fazem sessões de advisoring comigo. Com esses cenários em mãos, você pode agora conversar com a pessoa CEO e outros líderes da empresa para mostrar o impacto da redução, bem como alternativas de reduções menores com impactos também menores na produtividade do time de desenvolvimento de produtos para que vocês possam avaliar as opções.
Ter menos pessoas fará com que a equipe deixe cair algumas bolas, ou seja, é preciso tomar uma decisão sobre o que parar de fazer. Alguns objetivos e resultados esperados devem ser despriorizados, pois teremos que demitir algumas pessoas e teremos uma equipe menor. É simples assim. Menos dinheiro implica em equipe menor, o que implica em menos coisas que essa equipe poderá fazer e, consequentemente, menos objetivos poderão ser atingidos e resultados poderão ser alcançados.
Resumindo
Crises acontecem com certa frequência. Em 2020 vivemos a crise da COVID-19. No início de 2023 podemos estar entrando em uma recessão. E mesmo sem crise externa, empresas podem ter tomado decisões que não se mostraram acertadas.
Quando uma crise acontece, temos que preservar caixa.
Uma das formas de preservar caixa é reduzindo o tamanho do time de desenvolvimento de produto, ou seja, fazer downsizing e layoff.
Ao fazer a análise e planejamento do layoff, devemos desenhar cenários que nos permitem entender qual o impacto de cada cenário no atingimento da visão de produto e na execução da estratégia de produto. Uma boa forma de deixar claro os impactos é com os OKRs. Em cada cenário, deixe claro quais OKRs serão impactados.
Treinamento, aconselhamento e consultoria em gestão de produtos digitais
Tenho ajudado empresas a conectar negócios e tecnologia por meio de treinamento, aconselhamento e consultoria 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:
I hope that this year we continue to advance in our learning about how to make digital products and that, with this learning, we manage to make even better products!
To help with this goal, nothing like a retrospective! \o/
I used the FunRetrospectives app, one of the companies I act as a board member, to help me. The app comes with many ready-to-use retrospective templates. And if you still want to adjust it to your needs, it lets you do that. That’s what I did when I created my retrospective with “Learnings & Facts” on one side and “Questions & Concerns” on the other.
2022 was the year I decided to become a full-time product leadership coach. It has been a very fun journey. Some interesting facts and learnings:
I jumped into full-time coaching six months ago. Until Jun/2022, I was doing part-time coaching, a half-day per week time commitment.
My average monthly net income doubled in the six months I’ve been coaching full-time.
I’m also paid with shares by some clients.
Building my brand with articles, talks, classes, and books while I was a full-time exec was very helpful in generating demand. Despite my ugly site (I’m working on a revamp!), I’m already fully booked until Mar/2023.
I’m engaged with small startups, growth-stage companies, and enterprises.
I’m doing discovery coaching, product leadership coaching, and transformation coaching.
I still have a lot of questions:
Am I pricing and charging correctly?
Will I be able to continue to generate good net income, or did I have “beginner’s luck”?
Am I offering the right services?
Am I engaging with the right customers?
Will I miss hands-on experience?
Will I miss having a team?
Will I continue to have learnings that can be useful to other people?
I know the answers and learnings will come over time.
To answer the last question (will I continue to have learnings that can be useful to other people?), this year’s most-read articles list has many new articles that I wrote after starting my full-time coaching career.
The most-read articles can be grouped into three main topics – digital transformation, product leadership, and product discovery:
I’m very happy with my first few months in my new career. Looking forward to building an amazing 2023 with lots of learnings, some answers to my questions above, and more opportunities to help people and companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management.
Digital product training, coaching, and advisory
I’ve been helping companies bridge the gap between business and technology through training, 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:
Startup Guide: How startups and established companies can create profitable digital products
Product Management: How to increase the chances of success of your digital product
Espero que nesse ano a gente continue avançando em nosso apresendizado sobre como fazer produtos digitais e que, com esse aprendizado, consigamos fazer produtos cada vez melhores!
Para ajudar nesse objetivo, nada como uma retrospectiva! \o/
Utilizei o app do FunRetrospectives, uma das empresas da qual sou conelheiro, para me ajudar. O app já vem com muitos modelos de restrospectiva prontos para uso. E, se mesmo assim, você quiser adequar a suas necessidades, ele permite fazer isso. Foi o que fiz, ao criar minha retrospectiva com “Aprendizados & Fatos” de um lado, e “Dúvidas & Preocupações” do outro.
Comecei a ser coach em tempo integral há seis meses. Até jun/2022, eu estava fazendo coaching como um trabalho extra, que me ocupava não mais que meio período por semana.
Minha renda líquida mensal média dobrou nos seis meses em que tenho atuado com coach, treinamento e consultoria de produtos em tempo integral.
Alguns clientes também tem pago com ações.
Construir minha marca com artigos, palestras, aulas e livros enquanto eu era um executivo em tempo integral foi muito útil para gerar demanda. Apesar do meu site feio (estou trabalhando para melhorá-lo!), já estou com sem espaço livre até mar/2023.
Estou trabalhando com startups, empresas em estágio de crescimento e empresas grandes.
Estou fazendo coaching de discovery, de liderança de produto e de transformação.
Ainda tenho muitas dúvidas:
Estou precificando e cobrando corretamente?
Serei capaz de continuar gerando um bom resultado ou tive “sorte de principiante”?
Estou oferecendo os serviços certos?
Estou me envolvendo com os clientes certos?
Vou sentir falta da experiência prática, do trabalho mais hands-on?
Vou sentir falta de ter uma equipe?
Vou continuar tendo aprendizados que podem ser úteis para outras pessoas?
Sei que as respostas e aprendizados virão com o tempo.
Para responder à última pergunta (vou continuar tendo aprendizados que podem ser úteis para outras pessoas?), a lista de artigos mais lidos deste ano tem muitos artigos novos que escrevi depois de iniciar minha carreira de treinador em tempo integral.
Os artigos mais lidos podem ser agrupados em três tópicos principais – transformação digital, liderança de produtos e descoberta de produtos:
Estou muito feliz com meus primeiros meses em minha nova carreira. Ansioso para construir um 2023 incrível com muitos aprendizados, algumas respostas para minhas perguntas acima e mais oportunidades para ajudar pessoas e empresas a conectarem negócios e tecnologia por meio de educação, treinamento e serviços de consultoria em desenvolvimento e gerenciamento de produtos digitais.
Treinamento, aconselhamento e consultoria em gestão de produtos digitais
Tenho ajudado empresas a conectar negócios e tecnologia por meio de treinamento, aconselhamento e consultoria 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:
No capítulo Qual a diferença entre gestão de marketing de produtos e gestão de produtos?, comentei sobre como os 4 Ps do marketing (Produto, Preço, Promoção e Praça) são distribuídos entre gestores de marketing de produtos e gestores de produtos. Essa é uma visão macro de divisão de responsabilidades. Nele, falei também sobre como esses times (marketing e gestão de produtos) devem trabalhar muito próximos para o sucesso dos produtos que eles desenvolvem e administram, sendo que o mesmo acontece em relação aos times de Engenharia e de UX, que, apesar de serem funções distintas, também devem trabalhar muito próximos com a gestão. Outra função que pode ter bastante sobreposição com o gestor de produtos é o gestor de projetos que, em times de desenvolvimento que trabalham com cultura ágil, são chamados de Scrum Master, Agile Coach ou Delivery Manager.
Essa proximidade costuma gerar algumas dúvidas do tipo: “Esta tarefa, quem é o responsável?”, “Esta outra tarefa, quem eu preciso consultar antes de levar ela adiante?” e “Para esta outra aqui, quem precisa estar junto comigo para eu conseguir concluí-la com êxito?”. Muitas vezes, acabam ficando bolas divididas: um acha que é responsável por determinada tarefa e o outro também acha. Ou pior, um acha que o outro é o responsável, e esse outro acha que o primeiro que era, e ninguém a faz.
RASCI
RASCI é uma ferramenta muito útil para ajudar a definir e entender os papéis e responsabilidades de cada pessoa e cada função. É a abreviação das primeiras letras dos possíveis papéis que uma pessoa, área ou função pode ter em uma tarefa:
Responsible (encarregado): é a pessoa responsável pela execução da tarefa, ou seja, quem tem de liderar o esforço de planejar, fazer e concluir a tarefa. Não pode existir mais de um responsável por tarefa. É aquela máxima de que cachorro com dois donos morre de fome.
Accountable (responsável): é a pessoa que responde pela tarefa e que tem o poder de delegar para o responsible a tarefa a ser feita. Responsible e accountable podem ser a mesma pessoa. Também vale a regra de que não pode existir mais de um accountable por tarefa. Se responsible e accountable são duas pessoas diferentes, o accountable pode ser visto como o patrocinador.
Support (suporte): são as pessoas ou equipes que trabalham junto e sob a coordenação do responsible para a execução da tarefa.
Consulted (consultado): são as pessoas ou equipes que não participam da execução da tarefa, mas que precisam ser consultadas antes ou enquanto a tarefa estiver sendo executada, pois elas podem dar inputs relevantes para sua execução.
Informed (informado): são as pessoas ou equipes que não participam da execução da tarefa, nem precisam ser consultadas antes ou enquanto a tarefa estiver sendo executada, mas que precisam ser informadas quando a tarefa for concluída.
A seguir, está um exemplo de uma matriz de responsabilidade RASCI entre engenharia, UX, marketing de produtos e gestão de produtos que usamos na Locaweb:
Matriz de responsabilidade RASCI da Locaweb
COMO USAR
O primeiro passo é fazer a matriz de responsabilidades. Minha recomendação é preencher essa tabela juntando todas as pessoas envolvidas em uma sala, assim pode-se discutir se a divisão de responsabilidade está boa para todos e se tem alguma tarefa faltando. Muito provavelmente, vão surgir algumas “bolas divididas”, mas esse é um ótimo momento para discuti-las e definir quem é o responsável.
Em seguida, deve-se experimentar fazer as tarefas seguindo a matriz responsabilidade por algum tempo, tipo um ou dois meses. Depois, é importante fazer uma retrospectiva para ver se está tudo certo, ou se é necessário algum ajuste.
Daí para a frente, o uso passa a ser automático e as pessoas não precisarão mais se referir à matriz de responsabilidades. A cada 1 ano ou quando surgir alguma dúvida, ou mesmo quando surgir alguma tarefa nova, é bom revisitá-la.
Matriz de poder-interesse
Existem outras áreas que a gestora de produtos se relaciona, mas que não trabalham tão próximas do desenvolvimento de produto. Para entender melhor esse relacionamento uma boa ferramenta é a matriz de poder-interesse.
A matriz de poder-interesse (do inglês Power-Interest Grid) é um conceito desenvolvido pela primeira vez na década de 90 por Aubrey L. Mendelow, e posteriormente explicado no livro, Making Strategy: Mapping Out Strategic Success, de Fran Ackermann e Colin Eden. Com base no poder e no interesse que uma pessoa ou equipe tem em seu produto, você pode classificá-los em 4 categorias principais.
Matriz de poder-interesse
Os atores principais são os que têm grande poder e interesse no seu produto. Você precisa colaborar frequentemente com eles. Os usuários e clientes do seu produto são atores principais, você precisa colaborar com eles para construir o melhor produto que resolva seus problemas e atenda às suas necessidades. Em algumas empresas, provavelmente o fundador mais próximo do produto também é um ator principal. Você deve convidar essas pessoas para qualquer reunião e dinâmica em que decisões estratégicas sejam tomadas. Agende individualmente para apresentar as decisões e pedir seus comentários e contribuições.
As pessoas são aquelas com pouco poder, mas alto interesse em seu produto. Eles não têm o poder de vetar ou alterar decisões, mas têm um profundo interesse em seu produto. Em algumas empresas, podemos pensar no suporte ao cliente, vendas e marketing como exemplos de áreas que desempenham o papel de pessoas. Elas têm grande interesse, mas não têm o poder de mudar seu produto. Você pode se comunicar com eles por e-mail semanal de status e demonstrações de produtos. É importante coletar suas opiniões, mas lembre-se de que eles não têm o poder de mudar suas decisões.
Os definidores de contexto são aqueles com poder de mudar seu produto, mas pouco interesse em seu produto. Exemplos de áreas que podem desempenhar uma função de definidor de contexto são RH e Jurídico. Se o RH não ajudar você a formar a equipe, você não terá uma equipe para construir seu produto. Se o Departamento Jurídico não estiver ciente e alinhado com os aspectos legais de seu produto, ele tem o poder de bloquear ou atrasar seu lançamento. Um CFO e um controlador também são duas funções que têm o poder de mudar decisões que afetam seu produto. É importante manter os definidores de contexto bem informados sobre as decisões do produto. Consulte-os antes de tomar decisões importantes. Mantenha-os informados semanalmente.
A multidão é quem tem baixo poder e pouco interesse. Mesmo que eles tenham pouco poder e interesse, é importante mantê-los informados. Normalmente, uma atualização mensal sobre o andamento do produto é suficiente. Pode ser por e-mail ou em uma reunião geral mensal com demonstrações de produtos como vou comentar mais adiante. Normalmente são as pessoas das áreas de RH, Jurídico, Administrativo e Financeiro que não estão no grupo de definidores de contexto.
É importante observar que cada empresa tem sua própria dinâmica, portanto, uma área ou pessoa que desempenha uma função específica na matriz de poder-interesse de uma determinada empresa pode ter outra função em uma empresa diferente.
Empatia
Essas duas ferramentas são muito úteis para a gestora de produtos poder entender melhor como se relacionar com seus stakeholders e como gerenciar suas expectativas.
Contudo, essas ferramentas ficam mais poderosas quando utilizadas com empatia, ferramenta fundamental para a gestora de produtos poder gerenciar seus stakeholders. Empatia é a capacidade que uma pessoa tem de se colocar no lugar de outra para compreender os suas expectativas. Seus anseios, motivações, necessidades e problemas.
Essa característica é importante para que a gestora de produto entenda os clientes e usuários do produto, saber como estes se relacionam com ele, e que problema esperam resolver ou que necessidade querem ver atendidas. Também ajuda a entender o impacto de seu produto no seu time e nas pessoas de outras áreas. Por fim, mas não menos importante, a gestora de produto também precisa se colocar no lugar dos donos do produto, para entender suas expectativas e os resultados que ele trará para a empresa.
Resumindo
RASCI é uma ferramenta muito útil para ajudar a definir e entender os papéis e responsabilidades de cada pessoa e cada função.
A matriz de poder-interesse, juntamente com RASCI, é uma ótima ferramenta para ajudá-lo a entender melhor e interagir com seus stakeholders.
Mas não se esqueça, a principal ferramenta que uma gestora de produtos precisa para entender melhor e, consequentemente, ter boas a frutíferas interações com seus stakeholders é a empatia.
No próximo capítulo vamos começar um nova parte do livro sobre gestão de portfólio de produtos.
Treinamento, aconselhamento e consultoria em gestão de produtos digitais
Tenho ajudado empresas a conectar negócios e tecnologia por meio de treinamento, aconselhamento e consultoria 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:
In the chapter What is the difference between product marketing and product management? I commented on how marketing 4Ps (Product, Price, Promotion, and Place) are distributed between product marketing and product managers. This is a macro view of the division of responsibilities. In it, I also talked about how these teams (marketing and product management) should work closely together for the success of the products they develop and manage, as do the Engineering and UX teams, which, despite being distinct roles, should also work closely with product management. Another role that may overlap with the product manager is the project manager. Project managers in product development teams with agile culture are called the Scrum Masters, Agile Coaches, or Delivery Managers.
This proximity often raises some questions such as: “Who is responsible for this task?”, “Whom do I need to consult before moving this other task forward?” and “Who needs to be with me so I can complete this other task successfully?” Often, these situations become jump balls: one thinks she is responsible for a particular task, and the other thinks the same. Or worse, one thinks the other is responsible, the other thinks the first one was, and no one does anything.
RASCI
RASCI is a very useful tool to help define and understand the roles and responsibilities of each person and function. It is the abbreviation of the first letters of the possible roles that a person, area, or function can have in a task:
Responsible: the person responsible for executing the task, that is, who has to lead the effort to plan, do and complete the task. There cannot be more than one responsible. Remember the saying that a dog with two owners dies of hunger.
Accountable: the person responsible for the task and who has the power to delegate the task to be done to the responsible. Responsible and accountable can be the same person. The rule also applies that there cannot be more than one accountable per task. If responsible and accountable are two different people, the accountable can be seen as the sponsor.
Support: are the people or teams that work together and under the coordination of the responsible for the execution of the task.
Consulted: the people or teams who do not participate in the execution of the task but who need to be consulted before or while the task is being performed, as they can provide relevant inputs for its execution.
Informed: the people or teams who do not participate in the execution of the task, nor need to be consulted before or while the task is being performed, but who need to be informed when the task is completed.
The following is an example of a RASCI responsibility matrix between engineering, UX, product marketing, and product management that we used at Locaweb:
Locaweb’s RASCI responsibility matrix
HOW TO USE
The first step is to build the responsibility matrix. My recommendation is to fill this table by bringing together all the people involved in a room, so you can discuss whether the division of responsibility is ok for everyone and if a task is missing. Most likely, some “shared responsibilities” will appear, but this is a great time to discuss them and define who is responsible. There can be only one person responsible for any task.
Then, the team should try to do the tasks following the responsibility matrix for some time, like one or two months. Then, it is important to do a retrospective to see if everything is ok, or if any adjustment is needed.
From then on, the use becomes automatic, and people will no longer need to refer to the responsibility matrix. Every year, when a question arises, or even when a new task arises, it is good to revisit it.
Power-Interest Grid
There are other areas that don’t work so closely with product management in building the product. For these areas, a good tool to use is the Power-interest Grig.
The Power-Interest Grid is a concept first developed in the 90s by Aubrey L. Mendelow and later explained in the book “Making Strategy: Mapping Out Strategic Success”, by Fran Ackermann and Colin Eden. Based on the power and interest a person or team has in your product, you can classify them into four main categories.
Power-interest grid
The players are those who have great power and interest in your product. You need to collaborate with them often. The users and customers of your product are players, and you need to collaborate with them to build the best product that solves their problems and meets their needs. In some companies, the closest founder to the product is probably a player. You should invite these people to any meeting where strategic decisions are made. Schedule individually to present the decisions and ask for their comments and contributions.
The subjects are those with little power but high interest in your product. They do not have the power to veto or change decisions, but they have a deep interest in your product. In some companies, we can think of customer support, sales, and marketing as examples of areas that play the role of subjects. They have great interest but do not have the power to change the product. You can communicate with them via weekly status emails and product demos. It is important to collect their opinions, but remember that they do not have the power to change your decisions.
The context setters are those with the power to change your product but little interest in your product. Examples of areas that can play the role of context setters are HR and Legal. If HR doesn’t help you build the team, you won’t have a team to build your product. If Legal is not aware of and aligned with the legal aspects of your product, it has the power to block or delay its launch. A CFO and a controller are also two functions that have the power to change decisions that affect your product. It is important to keep context setters well-informed about product decisions. Consult with them before making important decisions. Keep them informed weekly.
The crowd is the one with low power and little interest. Even if they have little power and interest, it is important to keep them informed. Usually, a monthly update on the progress of the product is sufficient. It can be by email or in a monthly general meeting with product demos – I’ll talk about this and other meetings in another chapter. Usually, people in the HR, Legal, Administrative and Financial areas are not in the context-setting group.
It is important to note that each company has its own dynamics. Therefore, an area or person that plays a specific role in the power-interest grid of a given company may have another role in a different company.
Empathy
These two tools are very useful for the product manager to better understand how to relate to the other areas of the company and how to manage their expectations.
However, those tools are more useful when combined with empathy, a fundamental tool for the product manager to manage her stakeholders. Empathy is the ability of one person to put himself in the place of another to understand his expectations. Their desires, motivations, needs, and problems.
This characteristic is important for the product manager to understand the customers and users of the product, to know how they relate to it, and what problems they expect to solve or what needs they want to be met. It also helps to understand the impact of your product on your team and people in other areas. Last but not least, the product manager also needs to put herself in the shoes of the owner of the product to understand their expectations of the results the product will bring to the company.
Summing up
RASCI is a very useful tool to help define and understand the roles and responsibilities of each person and function.
The Power-Interest Grid and RASCI are great tools to help you better understand and interact with your stakeholders.
But don’t forget, the main tool that a product manager needs to master and, consequently, have improved and fruitful interactions with its stakeholders is empathy.
In the next chapter, we will start a new book section to discuss product portfolio management. Stay tuned!
Digital product training, coaching, and advisory
I’ve been helping companies bridge the gap between business and technology through training, 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:
Startup Guide: How startups and established companies can create profitable digital products
Product Management: How to increase the chances of success of your digital product
If we search on Google for reasons why tech products fail, we will find many articles with many possible reasons explaining product failures. From 3 of these articles, I was able to compile a list of 26 reasons:
Lack of market focus (a.k.a. segmentation).
Excessive pace of product improvement.
Incomplete products.
Too much capital.
Channel mismanagement.
Failure to establish the right competitive barriers.
Using price alone to attract mainstream buyers.
Improper use of advertising.
Misinterpretation of the innovation-adoption process.
Irrelevant market research.
The company can’t support fast growth.
The product falls short of claims and gets bashed.
The new item exists in “product limbo”.
The product defines a new category and requires substantial consumer education.
The product is revolutionary, but there’s no market for it.
Behind many of the reasons and failures above, we can certainly find a common behavior, going straight from problem discovery to solution delivery with little to no solution discovery. When talking with my clients about their product discovery, they normally describe situations like:
We did deep user research, and we found problem X, which users want to get solved to the point that they will pay for a good solution, so we decided to build solution Y, but now that we delievered solution Y we are seeing very low adoption…
This happened because they skipped the solution discovery, going from problem discovery straight to solution delivery. Let me repeat this because this is really, really important:
The most common reason for product failure is going straight from problem discovery to solution delivery.
As I mentioned in a previous article, discovery is a set of tools to help us mitigate product development risks. Discovering a problem is easy. Discovering a solution is hard and requires product managers, designers, and engineers to develop possible solutions. Then they need to assess the solutions to determine if at least one works and, if yes, and more than one works, which one has the greatest chance of success.
Sometimes the solution discovery confirms which product or feature we need to deliver, and the product – or feature – delivery is a success. However, there are other times when the solution discovery shows us that we cannot come up with a solution that has a chance of success, which is good. It is good because it will spare us a lot of time and energy from working on delivering a solution that will fail. We need to invest in solution discovery to avoid product failures.
Solution discovery can be a prototype, but it can also be other things like a landing page, where we draw traffic to understand if there’s demand, or a spreadsheet, where we assess the business viability of a certain solution. As I mentioned earlier, discovery is a set of tools to help us mitigate product development risks. There are many tools for the many types of risks in the product development process.
Last week I was talking to a client who had a very interesting solution idea to a certain problem that she discovered that the majority of her customers had. Still, when she decided to run some numbers, she understood that the solution was not financially viable, i.e., the amount of money she would receive from customers would not be enough to pay all the costs to serve the product. And this was good because she was able to spare all the time and money she would invest in building a solution that would become a failure.
A real-life example – a Locaweb product that never came to life
When I was at Locaweb, the biggest web hosting and internet company in Brazil, around 2010, we discovered that some potential customers didn’t want to use the existing website builders and were looking for web design professionals, but without enough knowledge about how to manage the work with this type of professional. As we had experience building websites, we thought we could manage this relationship with web design professionals for the customer.
We were very excited about the opportunity, and we designed a solution. We were already having some discussions on how to deliver it. However, before delivering, i.e., building the solution, we decided to build a prototype to present it to some potential customers and learn from their reactions and feedback.
When we presented the solution prototype to potential customers, it put a dumper on our excitement. We wanted to be the middle person, making it clear that we would do our best to help the customer get a good website, but we didn’t want to be responsible for any misconduct from web design professionals. We wanted that the system became self-regulated through the common 1 to 5 stars rating. When we built our prototype – a one-week effort – and then presented it to potential customers, almost all wanted us to pay some fine for non-delivery or late fees in case things didn’t go as expected.
We made changes to the prototype to present the product in alternative ways to clarify Locaweb’s and the web designers’ roles and responsibilities, but without success. That’s when we decided to cancel the product development. We were very glad we did it, and we then learned how important it is to make solution discovery before putting energy and resources into delivering a full product.
Solution discovery is a very powerful yet simple and cheap way to increase the success rate of our product development efforts. However, many teams ignore it and go from problem discovery to solution delivery. If we had done so in this Locaweb example I just described, it would most certainly be a big failure. It would generate a lot of headaches for Locaweb, our product development team, and our customers.
Summing up
The most common reason for product failure is going straight from problem discovery to solution delivery.
Discovery is a set of tools to help us mitigate product development risks.
Discovering a problem is easy. Discovering a solution is hard and requires product managers, designers, and engineers to develop possible solutions. Then they need to assess the solutions to determine if at least one works and, if yes, and if more than one works, which one has the greatest chance of success.
Sometimes the solution discovery confirms which product or feature we need to deliver, and the product – or feature – delivery is a success.
Sometimes the solution discovery shows us that we cannot come up with a solution that has a chance of success. This is good since it will spare us a lot of time and energy from working on delivering a solution that will fail. We need to invest in solution discovery to avoid product failures.
Digital product training, coaching, and advisory
I’ve been helping companies bridge the gap between business and technology through training, 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:
Startup Guide: How startups and established companies can create profitable digital products
Product Management: How to increase the chances of success of your digital product
Se pesquisarmos no Google os motivos pelos quais os produtos de tecnologia falham, encontraremos muitos artigos com vários motivos possíveis que explicam as falhas de um produto. A partir de 3 desses artigos, consegui compilar uma lista de 26 motivos:
Falta de foco no mercado (também conhecido como segmentação).
Ritmo acelerado de melhoria do produto.
Produtos Incompletos.
Muito capital.
Má gestão dos canais de vendas.
Falha em estabelecer as barreiras competitivas corretas.
Usando apenas o preço para atrair compradores tradicionais.
Uso indevido de publicidade.
Má interpretação do processo de adoção de inovação.
Pesquisa de mercado irrelevante.
A empresa não pode suportar um crescimento rápido.
O produto fica aquém das necessidades.
O novo item existe no “limbo do produto” (não é nem uma coisa, nem outra).
O produto define uma nova categoria e requer uma educação substancial do consumidor.
O produto é revolucionário, mas não há mercado para ele.
Por trás de muitas dessas falhas e seus motivos listados acima, certamente podemos encontrar um comportamento comum, ir direto da descoberta do problema para a entrega da solução com pouca ou nenhuma descoberta de solução. Ao conversar com meus clientes sobre a descoberta de produtos, eles normalmente descrevem situações como:
Fizemos uma pesquisa profunda com o usuário e encontramos o problema X, que os usuários desejam resolver a ponto de pagar por uma boa solução, então decidimos criar a solução Y, mas agora que entregamos a solução Y, estamos vendo muito baixo adoção…
Isso aconteceu porque eles pularam a descoberta de solução, passando da descoberta do problema direto para a entrega da solução. Deixe-me repetir isso porque isso é muito, muito importante:
O motivo mais comum para a falha do produto é ir direto da descoberta do problema para a entrega da solução.
Como mencionei em um artigo anterior, o discovery é um conjunto de ferramentas para nos ajudar a mitigar os riscos do desenvolvimento de produtos. Descobrir um problema é fácil. Encontrar uma solução é difícil e exige que gestoras de produto, designers e engenheiras pensem em possíveis soluções. Em seguida, eles precisam avaliar as soluções para determinar se pelo menos uma funciona e, se sim, e se mais de uma funciona, qual delas tem a maior chance de sucesso.
Às vezes, a descoberta da solução confirma qual produto ou funcionalidade precisamos entregar, e a entrega do produto – ou funcionalidade – é um sucesso. No entanto, há outros momentos em que a descoberta da solução nos mostra que não seremos capazes de encontrar uma solução com chance de sucesso, e isso é bom. É bom porque nos poupará muito tempo e energia trabalhando na entrega de uma solução que falhará. Precisamos investir na descoberta de soluções para evitar falhas de produto.
A descoberta de solução pode ser um protótipo, mas também pode ser outras coisas como uma landing page, onde atraímos tráfego para entender se há demanda, ou uma planilha, onde avaliamos a viabilidade financeira de determinada solução. Como mencionei anteriormente, a descoberta é um conjunto de ferramentas para nos ajudar a mitigar os riscos de desenvolvimento de produtos, e existem muitos tipos diferentes de ferramentas para os diversos tipos de riscos no processo de desenvolvimento de produtos.
Semana passada estava conversando com uma cliente que teve uma ideia de solução muito interessante para determinado problema que ela descobriu que a maioria de seus clientes tinha, mas quando resolveu rodar alguns números, entendeu que a solução não era viável financeiramente, ou seja, o quantidade de dinheiro que ela receberia dos clientes não seria suficiente para pagar todos os custos de servir o produto. E isso foi bom porque ela conseguiu poupar todo o tempo e dinheiro que investiria na construção de uma solução que se tornaria uma falha.
Um exemplo da vida real – um produto da Locaweb que nunca ganhou vida
Quando eu estava na Locaweb, a maior empresa de hospedagem e internet do Brasil, por volta de 2010, descobrimos que alguns clientes em potencial não queriam usar os construtores de sites existentes e procuravam profissionais de web design, mas sem conhecimento suficiente sobre como gerenciar o trabalho com esse tipo de profissional. Como tínhamos experiência na construção de sites, pensamos que poderíamos administrar esse relacionamento com profissionais de web design para o cliente.
Ficamos muito entusiasmados com a oportunidade e desenhamos uma solução. Já estávamos tendo algumas discussões sobre como desenvolver essa solução. No entanto, antes de pensar no product delivery, ou seja, em construir a solução, decidimos construir um protótipo para apresentar a alguns clientes em potencial e aprender com suas reações e feedback.
Quando apresentamos o protótipo da solução a clientes em potencial, recebemos um balde de água fria. Queríamos ser o intermediário, deixando claro que faríamos o possível para ajudar o cliente a ter um bom site, mas não queríamos ser responsáveis por qualquer má conduta dos profissionais de web design. Queríamos que o sistema se auto-regulasse através daquele tipo de classificação de 1 a 5 estrelas. Quando construímos nosso protótipo – um esforço de uma semana – e o apresentamos a clientes em potencial, quase todos queriam que pagássemos alguma multa por não entrega ou atrasos caso as coisas não saíssem como o esperado.
Fizemos alterações no protótipo para apresentar o produto de formas alternativas para deixar os papéis e responsabilidades da Locaweb e dos web designers mais claras, mas sem sucesso. Foi quando decidimos cancelar o desenvolvimento do produto. Ficamos muito felizes por termos feito isso e aprendemos como é importante fazer a descoberta de soluções antes de colocar energia e recursos na entrega de um produto completo.
A descoberta de soluções é uma maneira muito poderosa, porém simples e barata de aumentar a taxa de sucesso de nossos esforços de desenvolvimento de produtos. No entanto, muitas equipes a ignoram e partem da descoberta do problema direto para a entrega da solução. Se tivéssemos feito isso neste exemplo da Locaweb que acabei de descrever, certamente seria um grande fracasso. Isso geraria muita dor de cabeça para a Locaweb, nossa equipe de desenvolvimento de produtos e nossos clientes.
Resumindo
O motivo mais comum para a falha do produto é ir da descoberta do problema direto para a entrega da solução.
Discovery é um conjunto de ferramentas para nos ajudar a mitigar os riscos de desenvolvimento de produtos.
Descobrir um problema é fácil. Descobrir uma solução é difícil e exige que gestoras de produto, designers e engenheiras desenhem possíveis soluções. Em seguida, eles precisam avaliar as soluções para determinar se pelo menos uma funciona e, se sim, e se mais de uma funcionar, qual delas tem a maior chance de sucesso.
Às vezes, a descoberta da solução confirma qual produto ou funcionalidade precisamos entregar, e a entrega do produto – ou funcionalidade – é um sucesso.
Às vezes, a descoberta da solução nos mostra que não podemos encontrar uma solução que tenha chance de sucesso. Isso é bom, pois nos poupará muito tempo e energia trabalhando na entrega de uma solução que falhará. Precisamos investir na descoberta de soluções para evitar falhas de produto.
Treinamento, aconselhamento e consultoria em gestão de produtos digitais
Tenho ajudado empresas a conectar negócios e tecnologia por meio de treinamento, aconselhamento e consultoria 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:
