Gestão de produtos internos: Qual a melhor forma para desenvolver um sistema interno?

A gestão de produtos internos gera uma discussão comum entre empresas que possuem desenvolvedores internos, especificamente startups, seja se devem ter uma equipe, um squad, ou emprestar desenvolvedores para o desenvolvimento de produtos internos. Algumas startups não sabem o que é a gestão de produtos internos e acreditam que devem sempre usar software de prateleira para resolver problemas quando possível e outras acreditam que devem desenvolver um sistema interno do zero. Então, devo desenvolver internamente ou terceirizar?

vamos percorrer as estratégias das diferentes empresas e a matriz de eficiência da gestão de produtos internos para saber qual é a melhor forma de desenvolver um sistema interno.

O que é a gestão de produtos internos?

A gestão de produtos internos é uma categoria do gerenciamento de produtos com foco no desenvolvimento e suporte de sistemas internos.

Seu objetivo é garantir que os funcionários tenham todas as ferramentas para realizar seu trabalho com eficiência. Os Gerentes de Produto Internos precisam cortar custos (tempo do desenvolvedor, dinheiro, etc) e maximizar a eficiência operacional (entrega de produtos internos mais rápido, dimensionamento de operações, aumento das taxas de conversão, aumento do NPS, redução do churn, redução do burn e outros).

Qual é a melhor forma para desenvolver um sistema interno?

Os gerentes de produtos internos enfrentam o problema de escolher entre:

1. Desenvolvimento interno (código proprietário): codificando 100% da solução usando seus desenvolvedores.
2. Assinar software de prateleira: empresas SaaS como Zendesk para suporte ao cliente, HubSpot para vendas e Slack para comunicação interna.
3. Contratando uma agência: as agências também codificarão a solução sob medida para você, mas usarão seus engenheiros e cobrarão uma taxa de serviço.

Mais recentemente, uma nova opção foi introduzida às empresas:

4. Desenvolvimento low-code: seus engenheiros poderão codificar ferramentas internas mais rapidamente (Ex: Retool e Jestor).
5. Desenvolvimento no-code: qualquer pessoa da sua equipe poderá construir produtos internos e automação para sua empresa (Ex: Jestor e Zapier).

Prós e contras do desenvolvimento de produtos internos

Existem muitos prós e contras do desenvolvimento de sistemas internos e muitas maneiras de testar essas diferentes estratégias, nós criamos uma pontuação simples para classificá-las:

	Consumo de desenvolvedores internos	Custo de manutenção	Customização	Controle sobre o código	Tempo para entregar a solução	Atualizações automáticas
Desenvolvimento interno (código proprietário)	Alto	Alto	Alto	Alto	Alto	Zero/Baixo
Software de prateleira	Zero/Baixo	Zero/Baixo	Zero/Baixo	Zero/Baixo	Zero/Baixo	Alto
Contratar uma agência	Zero/Baixo	Alto	Alto	Médio	Alto	Zero/Baixo
Desenvolvimento Low-code	Médio	Médio	Alto	Médio	Médio	Alto
Desenvolvimento No-code	Zero/Baixo	Zero/Baixo	Alto	Zero/Baixo	Zero/Baixo	Alto

Estamos usando o -1, 0 e 1 para avaliar diferentes opções para os prós e contras do desenvolvimento interno, mas você pode personalizá-lo por item. Por exemplo, “ter os custos de manutenção é extremamente importante para mim”, – você pode alterar a ponderação aqui para 10.

-1	0	1
Vermelho	Amarelo	Verde	Pontuação
4	0	2	-1
2	0	4	3
3	1	2	0
0	4	2	3
1	0	5	5

Considerando todos os tópicos e fatores a serem ponderados, quando classificados, as melhores para as piores estratégias para os gerentes de produtos internos seriam:

1. Desenvolvimento No-code.
2. Desenvolvimento Low-code.
3. Software de prateleira.
4. Contratar uma agência.
5. Desenvolvimento interno (código proprietário).

No-code/Low-code vs Desenvolvimento interno

Codificar seu próprio sistema interno é uma estratégia muito difundida, muito mais popular do que o no-code, por exemplo. Se no-code é tão bom, então por que tantas empresas ainda optam por desenvolver internamente do zero? Há algumas razões:

1. No-code e low-code são novidades: o desenvolvimento No-code e Low-code são novas soluções para o desenvolvimento de produtos internos, é comum encontrar empresas que nem sabem que são opções de desenvolvimento.
2. Estigma do MVP: No passado, as ferramentas no-code eram usadas principalmente para MVPs, mas hoje em dia, as novas ferramentas evoluíram para se tornar sua solução final. Eles são altamente escaláveis e robustas. Mas alguns desenvolvedores ainda têm uma visão preconceituosa em relação a essas ferramentas, – provavelmente causadas por experiências ruins no passado.
3. Possuir o código-fonte: O desenvolvimento de produtos internos pode ser uma abordagem altamente estratégica. Você tem controle total sobre o código, pode até vender essa solução para outras empresas. AWS e GCP eram produtos/serviços internos que se tornaram fluxos de receita extremamente lucrativos.

A estratégia padrão para as maiores empresas do mundo é desenvolver internamente: Amazon, Apple, Facebook e Microsoft. Se as empresas mais bem-sucedidas do mundo fazem isso, devo fazer também? Não. A relação causal é invertida sob este raciocínio: eles precisam desenvolver seu próprio sistema interno porque são enormes, não são enormes porque fizeram isso. Eles controlam grandes quantidades de dados e precisam de desempenho extremo. Eles também não confiam em seus “pares” (o Google nunca usaria a AWS para executar todas as suas pesquisas).

Há uma grande história sobre a Uber construir seu próprio “Slack”. Eles gastaram uma quantidade enorme de horas construindo isso. Hoje em dia, eles usam o Slack. Em um mundo ideal com recursos e tempo infinitos, todas as empresas deveriam construir todos os seus sistemas internas. No entanto, tudo tem um custo de oportunidade. O tempo que você gasta construindo é o tempo que você não investe em seu core business.

Quando é eficiente dividir desenvolvedores para desenvolver produtos internos?

Estamos levando em consideração 4 variáveis diferentes: eficiência, tipo de profissional, estratégia e tipo de produto.

	Produto principal	Otimização de processos internos	Execução
Desenvolvedores	Código proprietário	Ferramentas Low-code	Ferramentas No-code
Builders	Código proprietário	Ferramentas No-code	Ferramentas No-code
Membros	Código proprietário	Ferramentas No-code	Ferramentas No-code

• Desenvolvedores: Engenheiros.

• Builders: Product Managers and people that dominate processes.

• Members: Gerentes de Produto e pessoas que dominam os processos.

• Produto principal: o serviço ou produto que você vende ao seu cliente. Geralmente são as ferramentas voltadas para o cliente criadas por sua equipe. Ex: aplicativo iOS do Uber.

• Otimização de processos internos: construção de sistema interno. Ferramentas que serão utilizadas internamente, o principal objetivo aqui é a eficiência. Ex: aplicativo de mensagens internas do Uber.

• Eficiência: tempo, custo de oportunidade e dinheiro.

Desenvolver internamente ou terceirizar?

A melhor estratégia é uma combinação de desenvolvimento internamente e ferramentas no-code. Desenvolver internamente apenas para construir o produto principal (alavancando todo o seu talento de desenvolvimento para o crescimento do negócio) e ferramentas no-code para construção (desenvolvimento rápido e escalável completamente personalizável por gerentes de produto, COOs, fundadores e membros).