Produtos de Software e Startups¶

Esta página reúne o que uma pessoa de tecnologia precisa saber para transformar um problema em um produto de software e fazê-lo dar certo: do conceito de startup à validação de ideias, ao produto mínimo, ao preço, às métricas e à mudança de rumo. É o assunto de perguntas como "como você validaria uma ideia?" ou "o que é MVP?", e conversa com Gestão de projetos (planejamento ágil) e Requisitos (descoberta de produto).

O que é uma startup¶

Definição: startup

Startup é uma instituição humana desenhada para criar um novo produto ou serviço sob condições de extrema incerteza. O que a define não é o tamanho, o setor nem ter investimento externo: é procurar uma solução ainda desconhecida para o problema de um grupo de pessoas e um modelo de negócio repetível e escalável para ela.

Startup é um experimento, não um negócio pronto. Experimenta-se para descobrir se (1) o problema existe, (2) a solução resolve e (3) as pessoas pagam o suficiente. Quando a solução é encontrada e o modelo é estável, a startup passa a ser uma empresa "normal" e a gestão muda.
Crescimento x estilo de vida: startups de crescimento buscam escala rápida e grande retorno (geralmente com investimento); startups de estilo de vida buscam receita suficiente para sustentar os fundadores, com crescimento moderado. As duas são válidas; defina o que você espera (dinheiro, impacto, aprendizado, liberdade).
Dentro de empresas estabelecidas também há startups (intraempreendedorismo): melhorar um produto, criar um produto novo para clientes atuais ou para clientes novos. Inovar não é luxo: o mundo muda e problemas novos aparecem.

Produto de software¶

Definição: produto de software

Qualquer software em que o usuário é reconhecido quando volta (conta, login) e os dados são armazenados pelo sistema. Nesse sentido, quase todo site ou sistema web é um produto, e deve ser tratado como tal, com dono, objetivos e evolução contínua.

Tipos: para consumidor final (receita comum: anúncios, assinatura, comércio), para empresas (B2B: assinatura, licença) e mistos.
Dois objetivos de todo software: atender os objetivos de quem o contratou e resolver o problema ou necessidade de quem vai usá-lo. O desenvolvimento ágil trouxe o cliente para dentro do projeto, mas o que importa é o usuário do cliente.
Web, móvel ou social? Em vez de pensar no meio, pense no usuário e no contexto de uso (sentado, em movimento, com uma mão). Mobile não é "menos" que desktop: é outro contexto. Acompanhe dados atuais de acesso do seu público.

Disciplinas envolvidas e o que terceirizar¶

Um produto de software é multidisciplinar: gestão de produto (descobrir problemas que valem a pena e priorizar), experiência do usuário (UX) (todo o fluxo de interação, não só a aparência), desenvolvimento, administração de sistemas/infraestrutura (monitoramento, backups, escala), marketing e vendas. Você pode terceirizar design, desenvolvimento ou infraestrutura, mas a gestão do produto e o conhecimento do cliente e do problema não podem ser terceirizados. Calcule o custo total, incluindo o custo de oportunidade (o que mais poderia fazer com o dinheiro e o tempo), e combine o tempo de dedicação com família e sócios. Startups com duas ou mais pessoas tendem a avançar mais rápido (Startup Genome Report); uma alternativa é manter o emprego e financiar a startup com ele até que ela exija dedicação integral.

Problema, necessidade e ideia¶

Problema ou necessidade, não tecnologia: uma tecnologia legal que não resolve um problema não é produto. Entenda qual é o problema, quem o tem, por que importa e como resolvem hoje.
Necessidade x desejo: a necessidade é o que a pessoa precisa (conectar-se, comer bem, economizar tempo); o desejo é a forma como ela imagina satisfazê-la. Clientes dizem o que querem; seu trabalho é descobrir o que os aflige. A frase atribuída a Henry Ford ("se eu perguntasse o que queriam, diriam um cavalo mais rápido") ilustra: o problema era chegar mais rápido e com conforto; a solução (o carro) o cliente não imaginava. Pergunte "por quê?" até chegar ao problema real.
Como escolher uma ideia: liste hipóteses, para cada uma crie um teste barato e meça. Exemplo clássico de validação: uma página de captura (landing page) que descreve o produto, com um formulário de interesse, e uma pequena campanha de anúncios para levar tráfego; se ninguém se cadastra, a hipótese cai antes de escrever código (smoke test). Escolha a ideia que mais pessoas demonstram querer e que você consegue atender bem.
Cuidado: problema que não incomoda ninguém (ou incomoda sem disposição de pagar) não sustenta um produto.

Faça rápido: o produto mínimo viável (MVP)¶

Definição: MVP (Minimum Viable Product)

Primeira versão do produto com o mínimo de funcionalidades necessário para testar a hipótese central com usuários reais e aprender. É de mínimo, mas precisa ser viável: resolver o problema com qualidade suficiente (não é "produto ruim").

Por que fazer rápido:

Momento da verdade: só se aprende de verdade quando pessoas usam o produto. Antes disso, tudo são suposições.
Custo do atraso: cada mês sem receita atrasa o retorno do investimento mais do que o mês em si (um atraso de 3 meses na primeira receita pode atrasar em 6 meses o retorno).
Complexidade: quanto mais funcionalidades, mais difícil de entender, usar e manter; a maior parte delas é pouco usada.
Aprendizado: é mais barato errar cedo. A famosa frase "se você não tem vergonha da primeira versão, demorou demais para lançar" resume o conselho (versões iniciais de produtos famosos eram bem simples).

Como fazer rápido:

Escopo mínimo: escolha com muito cuidado que funcionalidades entram; cada uma tem custo de desenvolvimento, de explicação e de manutenção. Cobrança, por exemplo, pode ser parte do mínimo (aprender se pagam).
Práticas ágeis: entregas curtas, TDD/testes automatizados, integração e implantação simples e reversível (CI/CD), ferramentas e componentes prontos, terceirizar o que não é diferencial.
Tempo e orçamento limitados (timeboxing): um produto com 48 horas de desenvolvimento força o foco no essencial.
Cuidado ao lançar o produto mínimo: garanta estabilidade, segurança e atendimento básicos; um MVP que quebra invalida o aprendizado. Funcionalidades demais (o "gráfico do inchaço" de Kathy Sierra) fazem o produto ficar mais complexo e menos usável.

Lançamento, feedback e atração de usuários¶

Pós-lançamento é o momento da verdade: monitore disponibilidade, desempenho, espaço em disco, erros e uso (por exemplo, com APM, SRE); implemente cobrança cedo.
Feedback: ofereça canais fáceis (e-mail, formulário, rede social), responda rápido e com transparência, e meça satisfação com o NPS (Net Promoter Score): $NPS = \%\text{ promotores} - \%\text{ detratores}$ (nota 9-10 vs 0-6 na pergunta "recomendaria a um amigo?").
Não implemente tudo que pedirem: cada sugestão aceita adiciona complexidade. Pergunte qual problema o usuário quer resolver, priorize pelo impacto no objetivo do produto (veja priorização em Requisitos) e diga não com respeito.
Atrair visitantes:

Canal	Características
Pago (anúncios em buscadores e redes)	Retorno quase imediato; custo contínuo; exige acompanhar custo por cliente
Conteúdo e SEO	Conteúdo útil sobre o tema, indexado por buscadores; resultado mais lento e duradouro
Boca a boca / viral	Consequência de um bom produto; dá para incentivar (indicação, compartilhar)
Parcerias e comunidades	Ir onde estão as pessoas com o problema (fóruns, redes, eventos)

Dicas básicas de SEO: conteúdo frequente e original, títulos e descrições distintos por página, URLs legíveis, imagens com texto alternativo e tamanho adequado, site rápido e adaptável a celular, links de qualidade e estrutura clara.

Como ganhar dinheiro¶

Modelo	Como funciona	Observação
Licença / venda do software	O cliente instala e paga pela cópia (mais manutenção anual)	O custo de operação é do cliente; receita lumpy
Assinatura (SaaS)	Mensalidade enquanto usa	Receita recorrente; exige reter clientes (churn)
Anúncios	O usuário usa de graça e anunciantes pagam	Exige grande audiência
Comércio	Vender ou alugar produtos e itens virtuais	Margens e logística
Freemium	Versão gratuita + planos pagos	Veja abaixo

Vá vender: nas fases iniciais todo mundo na startup vende (inclusive quem programa): é o que mais ensina sobre o problema do cliente. Defina meta de contatos e vendas, registre as objeções e aprenda com elas.
Preço: a referência principal é o valor percebido pelo cliente, não o seu custo. Bens de informação têm alto custo fixo de produção e baixo custo variável de reprodução, então o preço se baseia no valor e na disposição a pagar. Pesquise (perguntas diretas, testes de preço, concorrentes), crie planos/versões por faixas de uso e teste mudanças. Exemplo: com preço de R$ 15 e 400 assinantes, a receita é $400 \times 15 = \text{R\$ }6.000/\text{mês}$; um preço maior pode perder tantos clientes que a receita cai. Considere também o custo contínuo da equipe como custo operacional.
Versão gratuita? Faz sentido para atrair usuários, converter parte deles em pagantes e gerar boca a boca, mas custa suporte e infraestrutura. Defina o que é gratuito (limite de uso ou de funcionalidades) e o que leva à conversão.

Métricas: "seja um data geek"¶

Decisões por dados, não por intuição. Meça o que importa para o objetivo, não tudo; sistemas de analytics despejam números demais. Princípios:

Funil: visitantes → cadastros → ativação (primeiro valor) → pagantes → indicam outros. Os "piratas" AARRR (complemento): Acquisition, Activation, Retention, Revenue, Referral. Meça a conversão de cada etapa e alargue o funil atacando a etapa com maior perda.
Assista a seu usuário: observar pessoas usando o produto (teste de usabilidade, gravação de sessões) revela problemas que os números não mostram.
Experimente e meça: formule uma hipótese, mude uma coisa, compare (teste A/B) e decida.
Acompanhe o longo prazo: tendência importa mais que o dia a dia; olhe coortes (grupos de usuários por mês de entrada).

Churn, upsell e valor do cliente¶

Definição: churn

Churn é a taxa de perda de clientes (ou de receita) em um período. É a métrica que mais corrói negócios de assinatura.

\[\text{Churn de clientes} = \frac{\text{clientes que cancelaram no mês}}{\text{clientes no início do mês}} \qquad \text{Churn de receita} = \frac{\text{receita dos clientes que cancelaram}}{\text{receita do mês anterior}}\]

Upsell: o cliente passa para um plano maior (ou compra um aditivo); receita de expansão pode compensar o churn.
Complemento — LTV e CAC: o LTV (lifetime value, receita líquida de um cliente ao longo da vida) deve ser bem maior que o CAC (custo de aquisição de cliente). Regra de bolso: $LTV/CAC \ge 3$. Com churn mensal $c$, a vida média é cerca de $1/c$ meses.
Motores de crescimento (Lean Startup): viral (boca a boca), pago (gasta-se menos para adquirir do que o cliente rende) e engajamento/recorrência (o cliente não consegue viver sem o produto).
O objetivo do produto não é maximizar receita, e sim resolver o problema de forma sustentável; receita é o sinal de que você resolve.

Mudança de rumo (pivot)¶

Definição: pivot

Pivot é uma mudança estruturada de direção quando os dados mostram que a hipótese atual não funciona, mantendo o que se aprendeu. Não é desistir, é "mudar de rumo sem mudar de visão".

Tipos comuns: de captura de valor (mudar a forma de cobrar, por exemplo de assinatura do gerador de conteúdo para cobrar por recursos avançados), de segmento (outro público), de canal de venda, de produto/funcionalidade (focar em uma só parte ou ampliar para mais), de motor de crescimento. Faça um pivô quando várias tentativas de experimentos não mudam os números relevantes (retenção, receita) e antes de acabar o dinheiro.

Quanto tempo até ter retorno¶

O caminho tem fases: descoberta (o produto resolve um problema?), validação (as pessoas pagam?), eficiência (melhorar a aquisição e a retenção) e escala. Mesmo indo rápido, é comum que cada fase leve meses; planeje caixa para esse período e reavalie metas a cada aprendizado.

E se a empresa não é uma startup?¶

Empresas com software não web: a internet permite oferecer o produto como serviço (SaaS), com versão web e assinatura menor que licença + manutenção; já têm clientes, conhecem o problema e podem criar versões web ou móveis aos poucos (mantendo o produto atual).
Empresas de software sob encomenda: podem criar produtos próprios a partir de problemas que conhecem de perto, reaproveitando o conhecimento do domínio (vários produtos conhecidos nasceram assim, de uma necessidade interna).
Empresas que não têm software como atividade principal: todo site e sistema deve ser tratado como produto; é preciso conhecer o usuário para pedir o que importa, contratar de forma ágil, e manter internamente a gestão do produto, a administração de sistemas e o marketing, que não se delegam por inteiro.

Para responder em entrevista¶

Pergunta	Ideias para a resposta
"O que é uma startup?"	Instituição para criar produto sob incerteza extrema; é um experimento em busca de um modelo repetível e escalável
"Como você validaria uma ideia?"	Definir o problema e a hipótese, teste barato (landing page, entrevistas, protótipo) e métrica de sucesso antes de construir
"O que é MVP?"	Versão mínima viável para testar a hipótese com usuários reais e aprender; não é produto ruim
"Como decidir o que entra na primeira versão?"	O que testa a hipótese central; priorização por impacto e esforço (Requisitos)
"O que é churn e como reduzi-lo?"	Perda de clientes/receita por período; reduzir com onboarding, entrega de valor, suporte e análise de causas de cancelamento
"Quando pivotar?"	Quando experimentos repetidos não movem as métricas centrais; mudar uma hipótese (público, preço, canal, produto) mantendo o aprendizado