O Framework Define-Build-Ship: Um Sistema Operacional Completo

O sistema operacional que ninguém documenta

Todo grande product engineer tem um sistema. Ele vive na cabeca deles, na memória muscular, no jeito como automaticamente buscam dados de clientes antes de abrir o editor. Mas quase ninguém documenta isso. Eles simplesmente fazem. E quando você pergunta como eles lançam com tanta consistencia, dão de ombros e dizem algo como "eu só descubro o que importa, construo e lanço."

Isso é o framework define build ship em uma frase. E o sistema operacional que separa product engineers de engenheiros que apenas executam tickets. Três fases. Repetidas continuamente. Cada uma alimenta a próxima.

O framework define build ship da product.engineer é o ciclo repetivel de três fases que product engineers usam para ter responsabilidade sobre resultados de ponta a ponta: defina o problema que vale a pena resolver, construa a menor solução que testa sua hipotese, e lance com medição integrada desde o dia um. Se você esta se perguntando o que um product engineer realmente e, comece por la. Este artigo vai a fundo no sistema operacional que eles rodam.

Eu vi esse padrão se repetir centenas de vezes. Como Sr. Product Engineer na AWS, vivi isso diariamente em produtos de infraestrutura servindo milhoes de desenvolvedores. Como fundador duas vezes, construi empresas inteiras com base nele. E depois de mentorar mais de 12.000 engenheiros e contratar mais de 600, posso te dizer o maior diferencial entre engenheiros que lançam coisas que importam e engenheiros que apenas fecham tickets: os que lançam coisas que importam rodam alguma versão do define build ship, chamem disso ou não.

Esta é a pagina pilar. Vamos a fundo em cada fase. Templates, exemplos reais, recomendações de ferramentas, anti-patterns é o tecido conectivo entre as fases que a maioria das pessoas não percebe.

Por que três fases e não duas (ou cinco)

Você pode pensar que "define, build, ship" e obvio. Todo mundo define algo, constrói e lança. O que há de especial em transformar isso num framework?

A resposta esta no que a maioria dos times realmente faz. Eles pulam fases. Misturam fases. Invertem a ordem.

Veja como o "Define" fica quando você pula ele: um product manager coloca um ticket no Jira do seu sprint que diz "Adicionar exportacao CSV ao dashboard." Sem contexto sobre quem quer, por que querem, o que farão com os dados, ou como você sabera se funcionou. Você constrói a exportacao CSV. Vai pra produção. Ninguém usa. Três semanas desperdicadas.

Veja como o "Ship" fica quando você pula ele: você constrói uma feature linda, mergeia o PR e parte pro próximo item. Sem feature flag. Sem instrumentacao de analytics. Sem métrica de sucesso. Sem follow-up. A feature funciona ou não, e você nunca descobre qual dos dois.

De acordo com um estudo de 2023 da Pendo, 80% das features no produto SaaS medio são raramente ou nunca usadas. Esse número tem sido consistente ao longo de anos de pesquisa deles. Oitenta por cento. Quatro de cada cinco coisas que times de engenharia constroem não importam para os usuários. Isso não é um problema de ferramentas ou de talento. E um problema de processo. Esses times estão construindo sem definir adequadamente, e lançando sem medir adequadamente.

A estrutura de três fases forca disciplina nos pontos exatos onde times perdem valor:

Cinco fases seriam granulares demais. Duas seriam grosseiras demais. Três é a estrutura mínima viável que previne os modos de falha mais comuns.

Fase 1: Define

A fase Define é onde a maioria dos engenheiros falha. Não porque são ruins nisso, mas porque nunca foram treinados para isso. Programas de ciencia da computacao te ensinam a resolver problemas bem definidos. Ninguém te ensina a descobrir quais problemas valem a pena resolver.

O que "define" realmente significa

Definir não é escrever um PRD. Não é criar uma spec. Não é preencher um template de ticket. Definir significa responder quatro perguntas com evidencias:

1. Qual é o problema? (Descrito em termos de dor do usuário ou impacto no negócio, não em termos de features)
2. Quem tem esse problema? (Segmento específico, não "nossos usuários")
3. Como sabemos que isso é real? (Dados, não opinioes)
4. Como o sucesso se parece? (Uma métrica que se move, com um alvo)

Alguém que define bem consegue explicar seu próximo projeto em duas frases e respaldar com números. "Conexoes com Salesforce estão falhando a 19% desde a atualização da API deles, causando $45K/mes em churn de contas enterprise" é uma definição. "Precisamos melhorar a pagina de integrações" não e.

O Template de Define

Aqui esta o template que eu uso. Cabe em uma pagina. Se sua definição precisa de mais de uma pagina, você esta pensando demais.

## Problem Brief
 
**Problema:** [Uma frase descrevendo a dor do usuário ou impacto no negócio]
**Quem:** [Segmento específico de usuários afetados]
**Evidencia:** [2-3 pontos de dados provando que isso é real]
**Impacto:** [Custo quantificado de não fazer nada]
**Solução proposta:** [Uma frase, alto nível]
**Métrica de sucesso:** [O que se move, quanto, em que prazo]
**Nível de confiança:** [Alto/Medio/Baixo com justificativa]
**Time box:** [Tempo máximo que você gastara antes de reavaliar]

Esse template faz algo importante: forca você a quantificar o custo da inacao. A maioria dos engenheiros justifica projetos pelo potencial positivo. Mas o argumento mais poderoso e sempre o custo de não fazer nada. "Estamos perdendo $45K/mes" é mais convincente que "poderiamos ganhar alguns usuários."

Fontes de sinal para a fase Define

De onde vem as definições? Não do backlog do seu product manager. Elas vem de:

Sinais quantitativos:

• Análise de drop-off no funil (onde usuários estão falhando?)
• Picos de taxa de erro (o que quebrou recentemente?)
• Curvas de retencao por cohort (onde usuários param de voltar?)
• Análise de impacto em receita (quais falhas custam dinheiro real?)
• Clustering de tickets de suporte (do que os usuários realmente reclamam?)

Sinais qualitativos:

• Transcricoes de entrevistas com clientes
• Gravacoes de calls de vendas (quais objeções aparecem?)
• Conversas de suporte (que workarounds os usuários estão criando?)
• Forums de comunidade e mencoes em redes sociais
• Lancamentos de features de concorrentes (o que usuários pedem que outros agora tem?)

Os melhores praticantes mantém o que eu chamo de "pipeline de sinais": dashboards, buscas salvas e alertas automatizados que surfam problemas antes de qualquer pessoa pedir. Na PostHog, engenheiros tem acesso direto a gravacoes de sessão. Na Linear, o time inteiro le feedback de clientes num canal compartilhado diariamente. Esses são sistemas deliberados para alimentar a fase Define.

Como a Linear faz o Define

Os engenheiros da Linear não esperam problemas serem entregues a eles. Eles mantém uma lista corrente de "observações," coisas que notam em dados, tickets de suporte, ou no próprio uso do produto. Quando uma observação acumula evidencia suficiente, vira um projeto.

Por exemplo, um engenheiro pode notar que 12% das issues criadas no último mes são duplicatas que são mergeadas depois. Eles calculam o custo em tempo: 5 minutos por duplicata, multiplicado pela base de usuários. Aquela observação acabou de virar uma definição. Sem reuniao. Sem comite de priorização. O engenheiro viu o sinal, quantificou e propos uma solução.

Anti-patterns na fase Define

A solução disfarçada de problema. "Precisamos adicionar suporte a GraphQL" não é uma definição de problema. E uma solução. O problema pode ser "consumidores da API estão fazendo 7 round trips para renderizar uma única pagina, causando load times de 3 segundos." GraphQL pode ser a resposta. Ou talvez um design melhor de endpoint REST seja mais simples e rápido.

A armadilha da métrica de vaidade. "Precisamos aumentar DAU" e abstrato demais para ser acionavel. Quais usuários? Fazendo o que? Por que importa? Alguém que entende as métricas certas vai reformular isso como "precisamos aumentar a retencao na semana 2 para usuários no cohort de colaboração de 34% para 42%, porque esses usuários tem 3x mais lifetime value."

A definição big-bang. Se sua definição leva duas semanas para escrever e requer aprovação de quatro stakeholders, você saiu da fase Define e entrou em planejamento waterfall disfarçado de agilidade. Definicoes devem ser leves. Uma pagina. Um dia para escrever. Se você precisa de mais, quebre o problema em pedacos menores.

Sem time box. Toda definição precisa de um time box. "Vamos gastar duas semanas nisso, depois avaliar se a métrica moveu." Sem time box, projetos derivam. Escopo cresce. Você acaba seis meses dentro de um "projeto de duas semanas" sem nada para mostrar.

Fase 2: Build

A fase Build é onde a maioria dos engenheiros se sente confortavel. Essa é a parte para a qual foram treinados. Mas construir dentro do framework define build ship e diferente de construir num contexto tradicional de engenharia. A diferença é a restrição.

Construindo com restrição

Quando você tem uma definição clara com time box e métrica de sucesso, a fase Build se torna um exercício de priorização implacavel. Você não está construindo a melhor solução possível. Você está construindo a menor solução que testa sua hipotese.

É aqui que a mentalidade de product engineer diverge da mentalidade de engenheiro de software tradicional. Um engenheiro tradicional pode redesenhar toda a arquitetura de autenticacao para resiliência. O engenheiro com mentalidade de produto pergunta: "Qual é a mudança mínima que corrige a taxa de falha de 19% e me permite medir se o onboarding melhorou?"

De acordo com pesquisa do time DORA (agora parte do Google Cloud), times de engenharia de alta performance fazem deploy de código 973 vezes mais frequentemente que os de baixa performance. Essa diferença não vem de escrever código mais rápido. Vem de construir coisas menores e lança-las continuamente. O framework define build ship institucionaliza esse comportamento.

O checklist do Build

Antes de escrever uma linha de código, passe por este checklist:

• Escopo e mínimo. Posso remover algo é ainda testar a hipotese?
• Medição esta integrada. Planejei instrumentacao junto com a feature?
• Rollback esta planejado. Se isso quebrar algo, posso desligar instantaneamente?
• Edge cases estão documentados, não resolvidos. Edge cases conhecidos vão num ticket de follow-up, não neste PR.
• Time box e respeitado. Se estou em 80% do meu time box, lanço o que tenho.

Esse último ponto e crucial. O time box e sagrado. Se você atingiu seu time box é a coisa não esta perfeita, lance mesmo assim (assumindo que funciona). Imperfeito e lançado vence perfeito e parado numa branch.

Construindo em camadas

O padrão mais eficaz que já vi para a fase Build é o que eu chamo de "construção em camadas." Você lança em circulos concentricos de completude:

Camada 1: O teste da hipotese central. Código mínimo viável que válida se a ideia funciona. Sem tratamento de erros para edge cases exoticos. Sem UI bonita. Sem otimização de performance. Apenas: isso resolve o problema para o happy path?

Camada 2: Hardening para produção. Tratamento de erros, logging, feature flags, performance basica. Isso é o que torna a Camada 1 segura para lançar.

Camada 3: Polimento. UI caprichada, tratamento de edge cases, otimização de performance, acessibilidade. Isso acontece depois que você tem dados mostrando que a feature importa.

A maioria dos engenheiros tenta construir todas as três camadas simultaneamente. A abordagem melhor: construa as Camadas 1 e 2, lance, meça, e só invista na Camada 3 se os dados justificarem.

A Stripe faz isso magistralmente. Seus lancamentos de API frequentemente começam como betas apenas por convite com documentação mínima e arestas. Eles coletam dados de uso real. Aprendem. Depois polam e fazem GA da feature. O build inicial e intencionalmente mínimo porque eles sabem que a maioria das suposicoes sobre o que usuários precisam está errada.

Ferramentas para a fase Build

O ferramental certo torna a fase Build mais rápida sem sacrificar qualidade. Aqui esta o que os melhores engenheiros que conheco realmente usam:

O fio condutor: essas ferramentas reduzem a fricção entre "código escrito" e "código na frente de usuários sendo medido." Você deve otimizar para esse tempo de ciclo acima de quase tudo.

Como a Vercel constrói

Os engenheiros da Vercel são donos de features de ponta a ponta, da definição ao deploy. O ciclo e curto: desenvolva localmente com feedback rápido (Turbopack para HMR sub-segundo), cada PR ganha um preview deployment, feature flags controlam visibilidade, e analytics são instrumentados junto com o código da feature.

O resultado: um engenheiro da Vercel pode ir de "tenho uma ideia" a "esta em produção atrás de um flag com analytics" em um único dia para features pequenas. Essa velocidade vem de remover cada pedaco de fricção entre construir e lançar.

Anti-patterns na fase Build

Gold-plating. Construir features que ninguém pediu porque "podem precisar depois." YAGNI existe por uma razao. Construa o que a definição diz. Nada mais.

Construir sem medição. Se você escreve código de feature sem simultaneamente escrever instrumentacao de analytics, você esta acumulando dívida de medição. Você vai lançar a feature e nunca saber se funcionou.

Ignorar o time box. "Só preciso de mais dois dias" é a frase mais perigosa da engenharia. Esses dois dias viram duas semanas. Lance o que você tem. Itere depois.

Construir sozinho numa caverna. Lançar rápido não significa trabalhar isolado. Code review diário, pair programming em problemas dificeis e ciclos rápidos de feedback com um ou dois colegas de confiança mantém qualidade alta sem desacelerar.

Fase 3: Ship

Lançar não é fazer deploy. Essa é a distinção mais importante de todo o framework. Deploy e colocar código em produção. Lançar e colocar uma mudança na frente de usuários, medir seu impacto é fechar o ciclo.

O que "ship" realmente significa

Lançar no framework define build ship tem quatro componentes:

1. Release controlado. Feature flags, rollouts por porcentagem, canary deployments. Nunca va de 0% a 100% em um passo.
2. Monitoramento ativo. Observar taxas de erro, latência e métricas de negócio durante o rollout.
3. Medição. Comparar a métrica de sucesso definida antes e depois.
4. Comunicação. Dizer ao time (e as vezes ao cliente) o que mudou é por que.

Muitos engenheiros tratam o deploy como a linha de chegada. Neste framework, deploy é a linha de partida. A parte interessante começa quando usuários reais interagem com sua mudança e você consegue ver se sua hipotese estava correta.

O checklist do Ship

• Feature flag esta ligada para um cohort pequeno primeiro. Comece com 5-10%, não 100%.
• Alertas estão configurados. Pico de taxa de erro? Você é notificado.
• Baseline da métrica de sucesso esta registrada. Qual era o número antes da sua mudança?
• Plano de rollback esta documentado. Um comando para desligar.
• Comunicação esta preparada. Entrada no changelog, update pro time, notificação ao cliente se relevante.
• Revisão de follow-up esta agendada. Uma data no calendario para olhar os dados.

Esse último item é o que as pessoas pulam. Você lança, celebra, segue em frente. Duas semanas depois, ninguém olhou se a mudança funcionou. O ciclo quebra quando você não fecha o loop.

Medição: A parte que todo mundo pula

Aqui vai uma verdade dura: de acordo com uma pesquisa de 2024 da Harness com mais de 1.000 lideres de engenharia, apenas 25% dos times de engenharia conseguem medir o impacto de negócio de deploys individuais. Três de cada quatro times estão voando cegos. Eles lançam coisas e não fazem ideia se importaram.

Engenheiros que rodam este framework se recusam a operar assim. Todo ship tem uma métrica. Toda métrica tem um alvo. Todo alvo tem uma data de revisão.

O framework de medição funciona assim:

## Ship Review (preencha 1-2 semanas após deploy)
 
**Feature:** [Nome]
**Lançada:** [Data]
**Métrica de sucesso:** [O que você definiu na fase Define]
**Baseline:** [O número antes da sua mudança]
**Atual:** [O número após sua mudança]
**Alvo:** [Como você definiu sucesso]
**Veredito:** [Atingiu / Não atingiu / Inconclusivo]
**Próximo passo:** [Dobrar aposta / Iterar / Matar]

"Matar" é um resultado válido. Se você lançou algo é a métrica não se moveu, isso é informação valiosa. Você aprendeu algo. Agora redirecione essa energia para algo que move a agulha. Se você gastou duas semanas e aprendeu que sua hipotese estava errada, isso é uma licao barata. Se você gastou seis meses, é um desastre.

Como a PostHog lança

A PostHog e talvez o melhor exemplo público da fase Ship bem feita. Toda feature lanca atrás de um feature flag com instrumentacao de analytics desde o dia um. Os engenheiros assistem gravacoes de sessão de usuários interagindo com features novas em questao de horas após o ship.

O elemento cultural os diferencia. Engenheiros da PostHog escrevem "ship reviews" compartilhadas com a empresa inteira: qual era a hipotese, o que construimos, o que os dados mostram é o que faremos em seguida. Não da pra esconder um alvo perdido. Não da pra declarar vitória sem dados.

Isso é o que parece quando uma cultura leva a fase Ship a serio. Não é apenas ferramental. E accountability. Para um panorama completo do que esses engenheiros fazem no dia a dia, leia o que um product engineer faz.

Cadência de ship importa

A frequência com que você completa o ciclo define build ship importa mais que o tamanho de cada ciclo. Um time que completa dez ciclos pequenos por mes aprende dez vezes mais rápido que um time que completa um ciclo grande por mes.

Trata-se da taxa de aprendizado. Cada ciclo completo te ensina algo sobre seus usuários, seu produto e suas suposicoes. Quanto mais rápido você cicla, mais rápido converge em soluções que realmente funcionam. A cadência ideal e de um a dois ciclos completos por semana para features pequenas, é um a dois por mes para iniciativas maiores.

Anti-patterns na fase Ship

Lança e esquece. Fazer deploy e imediatamente partir pro próximo projeto sem configurar medição ou agendar uma revisão.

Rollout de 100% no dia um. Sem feature flag, sem rollout gradual, sem rede de segurança. Se algo der errado, você quebra para todos simultaneamente.

Métricas de vaidade. Medir "page views" ao inves de "taxa de conclusão." Rastrear "cadastros" ao inves de "usuários que atingiram time-to-value." Escolha métricas que digam se você realmente resolveu o problema.

Sem comunicação. Seu time não sabe o que você lançou. Seus stakeholders não sabem por que uma métrica mudou. Ninguém consegue construir em cima do seu trabalho porque não sabem que ele existe.

Conectando as fases do define build ship: O ciclo de feedback

O poder real do framework define build ship não esta em nenhuma fase individual. Esta na conexão entre Ship e Define. Quando você lança e mede, gera novo sinal. Esse sinal alimenta a fase Define do seu próximo ciclo.

Na prática:

1. Você lança a correção de OAuth do Salesforce e mede o resultado.
2. O drop-off de onboarding no passo três diminui de 34% para 28%. Bom, mas não tanto quanto previsto.
3. Você investiga. O drop-off restante são usuários que abandonam porque precisam encontrar suas credenciais do Salesforce primeiro.
4. Nova definição: "Usuários abandonam o onboarding quando pedimos credenciais que não tem em maos. Adicionar um fluxo de 'salvar e continuar depois' para reduzir o drop-off do passo três de 28% para 22%."
5. Novo ciclo começa.

Cada ciclo torna o próximo melhor porque você tem mais dados, mais contexto é uma compreensão mais precisa do problema. Isso são os juros compostos da product engineering. Ao longo de meses, alguém que roda esse ciclo consistentemente vai lançar trabalho mais impactante do que um time de cinco engenheiros trabalhando de um backlog estatico.

Define build ship em diferentes estágios de empresa

O nucleo permanece o mesmo em todo estágio de empresa, mas os inputs e restrições mudam.

Estagio seed (2-10 engenheiros)

Neste estágio, todos vestem o chapeu de builder tenham o título ou não. A fase Define e rápida e informal. O sinal vem de conversas diretas com clientes (porque você só tem 50 clientes). A fase Build e agressiva: você corta todo canto que não é estrutural. A fase Ship e continuous deployment com processo mínimo.

O maior risco neste estágio e pular a fase Define inteiramente e construir o que o cliente mais barulhento pedir. Ter as habilidades certas significa saber como dizer não para os pedidos errados.

Estagio de crescimento (10-50 engenheiros)

Aqui o framework define build ship se torna mais estruturado sem se tornar burocratico. Engenheiros ainda são donos de ciclos de ponta a ponta, mas a fase Define puxa de dados mais ricos (product analytics, NPS, análise de cohort). A fase Build adiciona mais quality gates (code review, testes automatizados, ambientes de staging). A fase Ship adiciona mais formalidade (feature flags, testes A/B, ship reviews).

O maior risco neste estágio e contratar engenheiros tradicionais que esperam specs prontas, e perder a cultura de propriedade que trouxe você até aqui.

Estagio de escala (50-200+ engenheiros)

Em escala, o framework opera dentro dos times ao inves de atraves da organização. Cada time pequeno (3-5 engenheiros) roda seus próprios ciclos define build ship independentemente. Coordenação entre times acontece no nível do Define (alinhar quais problemas resolver) e não no nível do Build (dizer as pessoas como resolver).

A Shopify opera assim. Centenas de engenheiros, mas organizados em pequenos pods autônomos que são donos de superficies de produto de ponta a ponta. Cada pod define, constrói e lança independentemente. A mentalidade de propriedade esta embutida na estrutura do time, não apenas em títulos individuais.

Templates e ferramentas: Seu kit inicial

Aqui esta tudo que você precisa para começar a rodar o framework define build ship amanha.

O Brief de Uma Pagina (Define)

# [Nome da Feature/Correção]
 
## Problema
[Uma frase. Dor do usuário ou impacto no negócio.]
 
## Evidencia
- [Ponto de dados 1]
- [Ponto de dados 2]
- [Citacao de cliente ou referência de ticket de suporte]
 
## Custo da inacao
[O que acontece se não fizermos nada? Quantifique.]
 
## Solução proposta
[Um paragrafo. O que você vai construir?]
 
## Métrica de sucesso
[Nome da métrica]: [Valor atual] → [Valor alvo] dentro de [prazo]
 
## Time box
[X dias/semanas máximo]
 
## Confiança
[Alta/Media/Baixa] porque [justificativa]

O Scope Doc do Build

# Escopo do Build: [Nome da Feature]
 
## No escopo
- [ ] [Entregavel específico 1]
- [ ] [Entregavel específico 2]
- [ ] [Instrumentacao de analytics]
- [ ] [Setup de feature flag]
 
## Explicitamente fora do escopo (por enquanto)
- [ ] [Coisa que você não está construindo ainda]
- [ ] [Edge case que você esta adiando]
 
## Plano de rollback
[Como desligar se as coisas derem errado]
 
## Dependencias
[O que precisa ser verdade para isso funcionar?]

A Ship Review

# Ship Review: [Nome da Feature]
 
## Resumo
Lançamos [o que] em [data] para resolver [problema da fase Define].
 
## Resultados (revisados em [data, 1-2 semanas após ship])
- Métrica de sucesso: [baseline] → [atual] (alvo era [X])
- Métricas secundarias: [qualquer outra coisa que se moveu]
- Efeitos inesperados: [algo surpreendente]
 
## Veredito
[Atingiu / Não atingiu / Inconclusivo]
 
## O que aprendemos
[1-2 frases]
 
## Proxima ação
[Dobrar aposta / Iterar com novo ciclo / Matar e redirecionar esforco]

Stack de ferramentas recomendado

Para alguém rodando ciclos define build ship, aqui esta o stack mínimo de ferramentas:

Ferramentas da fase Define:

• PostHog ou Amplitude para sinal quantitativo
• Intercom ou Plain para sinal qualitativo (conversas de suporte)
• Notion ou Linear para escrever briefs

Ferramentas da fase Build:

• Cursor ou VS Code com Claude para desenvolvimento assistido por AI
• GitHub para controle de versão e code review
• Vercel ou Railway para preview deployments
• LaunchDarkly ou PostHog Feature Flags para rollout controlado

Ferramentas da fase Ship:

• PostHog ou Mixpanel para analytics de features
• Sentry para monitoramento de erros
• Linear ou Notion para ship reviews e retrospectivas
• Slack ou canal do time para comunicação

O princípio chave: nenhuma ferramenta deve adicionar fricção ao ciclo. Se uma ferramenta te desacelera, substitua. Toda ferramenta no seu stack deve servir ao objetivo de aprendizado mais rápido.

Quando o define build ship quebra (e o que fazer)

Aqui estão os cenários onde o framework precisa de adaptação.

Trabalho de plataforma/infraestrutura

Quando você está construindo infraestrutura, seus "usuários" são engenheiros internos e seu "sinal" vem de pesquisas de developer experience, tempos de build e relatórios de incidentes. O framework ainda se aplica: defina o problema (builds estão muito lentos), quantifique (engenheiros perdem 47 minutos por dia esperando CI), construa a menor correção (paralelizar as três suites de testes mais lentas), lance e meça.

Produtos greenfield

Sem dados existentes, "evidencia" vem de entrevistas de customer development, análise de concorrentes e hipoteses educadas. Time boxes devem ser mais curtos (uma semana, não quatro) porque sua confiança e menor e você precisa aprender mais rápido.

Trabalho regulatorio/compliance

As vezes você deve construir algo porque uma regulamentacao exige. O framework ainda se aplica, mas a "evidencia" é a regulamentacao em si é a "métrica de sucesso" e passar uma auditoria. Você ainda se beneficia de disciplina de escopo, time boxes e ship reviews.

O efeito composto

A razao pela qual define build ship funciona é o efeito composto de rodar centenas de ciclos ao longo de meses e anos.

Alguém que completa dois ciclos por semana completou mais de 100 ciclos em um ano. Cada ciclo ensinou algo. Cada ciclo refinou seu instinto sobre quais problemas importam, quais soluções funcionam e quais medicoes revelam a verdade. Depois de três anos, essa pessoa tem mais de 300 ciclos completos de aprendizado. O julgamento dela e qualitativamente diferente de alguém que completou 30 projetos grandes no mesmo período.

É por isso que os melhores engenheiros parecem ter instintos sobrenaturais. Não tem. Eles acumularam mais reps. Sua "intuicao" e reconhecimento de padrões construído sobre centenas de ciclos define build ship. O framework é a academia. As reps são o treino.

A OpenAI opera numa versão disso. Seus engenheiros lançam experimentos constantemente, medem rigorosamente e matam coisas que não funcionam sem sentimentalismo. A evolução rápida do ChatGPT não foi apenas progresso de pesquisa. Foi product engineering: defina o que usuários precisam em seguida, construa a menor versão que testa isso, lance, meça, repita.

Comecando: Seu primeiro ciclo

Se você nunca rodou um ciclo formal de define build ship, aqui esta como começar esta semana:

Dia 1 (Define): Escolha um problema que você já sabe que existe. Um botao que confunde usuários. Uma mensagem de erro que não é útil. Escreva um brief de uma pagina. Quantifique o impacto. Defina uma métrica de sucesso.

Dia 2-3 (Build): Construa a menor correção. Instrumente com analytics. Coloque atrás de um feature flag. Resolva este único problema.

Dia 4 (Ship): Faca deploy. Rollout para 10% dos usuários. Observe as métricas. Se nada quebrou, va para 100%. Poste uma mensagem para seu time sobre o que você lançou é por que.

Dia 5+ (Measure): Verifique sua métrica de sucesso uma semana depois. Moveu? Escreva uma ship review de dois paragrafos.

Você acabou de completar seu primeiro ciclo formal de define build ship. Agora faca de novo. O framework só funciona se você roda-lo continuamente.

Principais conclusoes

• O framework define build ship e um ciclo de tres fases: definir o problema, construir a menor solucao, lançar com medicao.
• 80% das features SaaS sao raramente ou nunca usadas porque times constroem sem definir e lançam sem medir.
• A fase Ship de cada ciclo gera sinal que alimenta a proxima fase Define, criando aprendizado composto ao longo do tempo.
• Times de elite fazem deploy 973x mais frequentemente que times de baixo desempenho construindo coisas menores e lançando continuamente.
• Um ciclo falho com aprendizados claros e mais valioso que uma feature lançada que ninguem mediu.

FAQ

O que é o framework define build ship?

O framework define build ship é um sistema operacional de três fases para ter responsabilidade sobre resultados de ponta a ponta. Na fase Define, você identifica um problema que vale a pena resolver e quantifica seu impacto. Na fase Build, você cria a menor solução que testa sua hipotese dentro de um time box. Na fase Ship, você lanca com medição integrada e fecha o ciclo revisando se funcionou. O ciclo se repete continuamente, com cada fase Ship gerando sinal para a próxima fase Define.

Como define build ship e diferente de agile ou scrum?

Agile e scrum são frameworks de coordenação de times. Eles respondem "como organizamos trabalho entre um grupo?" Define build ship é um sistema operacional individual. Ele responde "como um engenheiro é dono de um resultado do início ao fim?" Você pode rodar define build ship dentro de um time scrum, dentro de um sistema kanban, ou sem processo formal algum. E complementar ao agile, não um substituto.

Preciso ser um engenheiro senior para usar este framework?

Não, mas o escopo dos seus ciclos será menor no início da carreira. Um engenheiro junior pode rodar ciclos define build ship em bug fixes e melhorias pequenas, enquanto um staff engineer roda em iniciativas maiores de produto. O framework escala para qualquer escopo. A disciplina de definir antes de construir e medir depois de lançar e valiosa em todo nível. Se você quer crescer nessa direção, veja nosso guia sobre como se tornar um product engineer.

Como convencer meu gestor a me deixar trabalhar assim?

Comece pequeno. Não peça permissão para reestruturar o processo do time. Apenas comece rodando ciclos pessoais de define build ship no seu trabalho existente. Escreva briefs de uma pagina para sua próxima tarefa. Instrumente sua feature com analytics antes de lançar. Escreva uma ship review e compartilhe os resultados. Quando seu gestor vir você consistentemente entregando resultados mensuraveis, a conversa muda de "posso trabalhar assim?" para "você pode ensinar o time a trabalhar assim?"

E se meu ciclo define build ship mostrar que a feature falhou?

Isso é um sucesso, não uma falha. Você aprendeu que sua hipotese estava errada, de forma barata e rápida. Mate a feature, anote o que aprendeu e comece um novo ciclo. O pior resultado não é uma feature que falhou. O pior resultado é uma feature que pode ter falhado mas ninguém nunca verificou. Ciclos falhados com aprendizados claros são mais valiosos do que features lançadas sem medição.

Leitura relacionada

• What Is a Product Engineer? The Definitive Guide
• What a Product Engineer Actually Does
• Product Engineer Skills: The Complete Breakdown
• Product Engineer Metrics: What to Measure and Why
• How to Become a Product Engineer