3 restrições para considerar antes de construir
(jordanlord.co.uk)- Ideias de produto devem começar definindo restrições para reduzir o espaço de exploração e evitar resultados complexos demais ou sem identidade
- Toda ideia deve caber em um one pager; se não couber, é sinal de que ainda faltam pesquisa, planejamento e prototipagem
- Junto com o produto, é preciso criar uma core tech capaz de sobreviver separadamente, deixando um ativo acumulado que continue valendo mesmo com mudanças de direção
- No centro do produto deve existir uma defining constraint sempre visível ao usuário, que naturalmente define o feel e a identidade do produto
- Se qualquer um dos três critérios não for atendido, a postura de não construir é importante para controlar o escopo e garantir alavancagem no longo prazo
Três restrições para impor antes de construir
- Definir restrições antes de criar um produto reduz o espaço de exploração e evita que ele acabe virando algo complexo demais ou sem identidade
- Ao longo de 10 anos criando vários produtos, produtos complexos demais ou sem identidade levaram ao fracasso, e após esses erros e tentativas o aprendizado foi condensado em três critérios
-
Se passar de uma página, não vale construir
- Toda ideia deve ser organizada em um one pager, e esse documento serve como north star
- O one pager deve ser inegociável, preciso, ambicioso e sem excessos
- O mesmo documento pode ser usado para se comunicar com investidores, contribuidores, colegas de equipe, amigos e familiares
- Quando surgem conflitos durante a colaboração, o que não está no one pager não vale a briga; se for realmente importante, o documento deve ser corrigido para refletir isso
- Se nem uma página foi preenchida, não é caso de inflar o conteúdo à força, mas de reconhecer que ainda não está pronto para ser construído
- Nesse caso, é preciso passar primeiro por pesquisa, planejamento e prototipagem, e depois reescrever o one pager
- Se passar de uma página, é complexo demais, então não vale construir
-
A tecnologia central deve ser separada do produto
- Separadamente do produto em si, é preciso criar a core tech que o sustenta
- A core tech pode ser uma metodologia, tecnologia, ferramenta ou até um produto separado, e deve conseguir sobreviver mesmo sem o produto atual
- Essa separação evita ficar preso a um único produto e permite que o acúmulo continue mesmo quando houver mudança de direção
- Produtos mudam de direção com frequência, mas a core tech permanece como um ativo duradouro e cumulativo
- No longo prazo, esse esforço acumulado pode gerar ganhos não lineares
- Como exemplos, são citados o git de Linus Torvalds, o HCL da HashiCorp e o Kubernetes do Google
- Isso não exige necessariamente recursos de empresas gigantes; pode ser uma biblioteca separada da codebase ou uma metodologia continuamente refinada
- A core tech deve ser independente da direção do produto, mas alinhada à visão de longo prazo da pessoa ou da empresa
- Se a ideia não viabiliza uma core tech, a alavancagem não é suficiente
-
Uma única restrição decisiva deve definir o produto
- No centro do produto deve haver uma defining constraint sempre visível ao usuário
- Essa restrição deve ser um elemento com o qual o usuário se depara e interage continuamente, formando a identidade do produto
- Uma boa restrição cria o feel do produto e se infiltra por toda a experiência do usuário
- No Minecraft, tudo é composto por blocos; na IKEA, a identidade aparece diretamente na restrição de móveis flat-pack para auto montagem
- Esse tipo de restrição reduz o espaço de decisão, limita o escopo e ajuda a focar nos problemas realmente importantes
- Não escolher uma restrição, ou escolher a errada, faz o produto caminhar para algo inchado que tenta fazer tudo
- Quando a restrição é bem desenhada, o design do produto passa a surgir naturalmente a partir dela
- Essa restrição também deve ficar na frente do one pager
Critério final
- Se qualquer uma das três restrições não for atendida, não vale construir
2 comentários
Comentários no Hacker News
Eu vinha chamando isso de product primitives
Coisas como os blocks do Notion, messages/conversations do Telegram, frames/layers do Figma, tweets do Twitter, cells/sheets do Excel, tools/layers do Photoshop e commands de CLI
Na minha visão, bom design de produto surge quando o número dessas primitives é bem pequeno
Produtos ruins ou não sabem quais são suas primitives, ou têm primitives demais, a ponto de cada elemento do produto parecer solto, seguindo por conta própria
Aí o usuário precisa aprender um monte de conceitos de alto nível diferentes, o que gera confusão, intimidação e dificuldade para ensinar
Idealmente, uma, duas ou três primitives centrais já bastam
A complexidade e o poder de um app vêm de escolher primitives profundas e combináveis
Como o block do Notion, a cell do Excel, o command da CLI ou o block do Minecraft, unidades pequenas que permitem fazer muita coisa
Isso parece parecido com a Alexandrian Pattern Language, mas na prática talvez esteja mais próximo dos Centers de que Alexander falou depois, do que de patterns
Pelo que entendo, a indústria de software abraçou bastante os patterns dele, mas no fim da vida Alexander passou a ver o Center como a unidade fundamental dos sistemas
Coisas como um pátio iluminado, um assento junto à janela ou uma lareira: pontos focais de utilidade local e coesão
Um center forte é naturalmente combinável, resolve tensões locais, é composto de centers menores e serve como bloco de construção para formar centers maiores
Quando um produto vira algo confuso e inchado, em geral não é por má intenção
As necessidades dos usuários até podem ser encontradas empiricamente com alguma facilidade, mas a verdadeira estrutura central capaz de absorvê-las com elegância é muito sutil e difícil de descobrir
Por isso, o caminho mais fácil quase sempre acaba sendo encaixar uma interface própria e rígida para cada necessidade que aparece na frente
Encontrar a primitive central que absorve essas necessidades de forma natural exige um trabalho arquitetural profundo
Talvez seja por isso que acabamos sempre construindo faster horses
Eu costumava chamar isso de concept count
Em geral é melhor minimizar o número de conceitos centrais que compõem o produto, e às vezes isso também era chamado de nouns and verbs do produto
Essa filosofia parece simplificada demais
O Tana tem basicamente só duas primitives, bullets e supertags, mas mesmo tarefas muito simples ficam complexas a ponto de exigir tutoriais de horas
Já o Google Maps tem várias primitives, mas em 90% dos casos de uso o UX é bem sólido
Eu usava um critério parecido ao olhar para linguagens de programação
Mesmo quando a linguagem era grande, se fosse conceitualmente pequena, depois de aprender o resto vinha com a experiência acumulada; já linguagens conceitualmente grandes tinham uma barreira de entrada muito maior
O caso em que senti isso mais fortemente foi perl
Tem que ser pequeno, mas não pequeno demais
Um exemplo clássico é shell script (POSIX shell, bash), que tentou modelar até scripting como command para evitar introduzir novos conceitos, e o resultado foi, como todos sabem, uma mistura quente, lenta e caótica
Gostei das três restrições, mas acho que o documento de 1 página deveria variar conforme a complexidade do projeto
Para projetos pequenos ou médios, uma página talvez baste, mas se for software de controle de voo para Marte, talvez seja preciso um one-pager com links para inúmeras subespecificações antes de começar a implementação
Separar tecnologia e produto é realmente muito sensato
Olhando para o Skype, por exemplo, havia a tecnologia de comunicação P2P no backend e o aplicativo de chamadas no frontend, e os fundadores espertos colocaram essas duas coisas em empresas separadas
Assim, mesmo depois de o Skype, o app de frontend, ser vendido para a Microsoft, a empresa com o IP central e a tecnologia P2P de backend pôde continuar existindo separadamente
Colocar uma única restrição no centro também faz sentido, mas às vezes me parece melhor ter várias restrições ou uma lista de prioridades
Se o princípio máximo for difícil de monetizar, tratá-lo como um dogma imutável pode empurrar o negócio para a falência
Se houver na equipe uma ideia de pivot forte para uma direção muito mais fácil de vender, isso pode abrir um caminho de sobrevivência mesmo que fique bem diferente do plano original
O Twitter também é um caso em que o public status update surgiu como um projeto paralelo, quando a empresa originalmente pretendia fazer outra coisa
Este texto resumiu muito bem como eu costumava construir negócios junto com meu antigo orientador de pesquisa
Nós começávamos primeiro pelos dois itens de trás, isto é, a tecnologia central e as restrições
A tecnologia central era um sampler que permitia um hierarchical Bayesian graph model arbitrário para sparse data, e a restrição era que ele precisava ser computável com CPU-bound
O que mais demorou foi perceber que o produto final precisava ser separado da tecnologia de base
Eu ouvi conselhos parecidos de várias pessoas antes de começar, mas algumas lições só ficam de verdade quando você passa por elas
A ideia do one-pager é realmente muito boa
Se você não consegue dedicar tempo nem para descrever claramente as restrições em uma página, vai acabar descobrindo essas restrições tarde demais, no meio da execução e no desespero
E aí isso deixa de ser um bug e vira um defeito no nível de estávamos construindo a coisa errada
Não consigo provar isso com dados, mas pela minha experiência projetos que colocavam todos, conceitualmente, na mesma página davam certo com muito mais frequência
Mesmo um documento curto e de alto nível já ajuda muito se deixar claro o que estamos fazendo e o que não estamos fazendo
Em contrapartida, projetos tocados no improviso acabavam decepcionando todo mundo, até as pessoas que nunca tinham expressado claramente o que pensavam
Eu queria que o autor tivesse mostrado um exemplo completo em que as restrições realmente funcionam
Principalmente no terceiro item, não consigo visualizar muito bem como isso fica na prática
No fim, parece que você mesmo precisa inventar alguma coisa
Acho boa uma ideia como everything's a file do Linux
Um conceito forte desses já pode levar bem longe
Restrições são subestimadas
As soluções mais elegantes normalmente não surgem de uma liberdade infinita, e sim de construir dentro de restrições claras
E isso também se conecta ao item 1
O próprio processo de escrever o one-pager ajuda a definir essas restrições
Parece que o principal motivo de o Google ter o Kubernetes é neutralizar concorrentes
Se fosse um solo SaaS, a restrição que eu acrescentaria seria: consigo encontrar um usuário beta esta semana?
Mesmo que tempo, escopo e tecnologia pareçam ótimos no one-pager, se ninguém entrar o projeto morre ali mesmo
Então, ao colocar desde o início uma restrição de distribuição/go-to-market, eu acabava validando o público antes de aprofundar demais as funcionalidades
Tenho a impressão de que dizer que a tecnologia central deve ser separável do produto pode incentivar abstração precoce demais e abuso de design patterns
Claro, faz sentido separar responsabilidades e dividir com clareza a camada de domínio de coisas como persistence/network/UI
Ainda assim, a camada de domínio inevitavelmente acaba muito fortemente amarrada ao produto
Não vejo como evitar isso
Talvez a ideia seja que exista uma camada externa que atraia compradores, enquanto aquilo que realmente faz tudo funcionar por dentro não é assunto de quem compra
Pode haver alguns conceitos servindo de interface entre essas duas camadas, mas a evolução interna deveria ficar separada da camada de produto voltada para fora
Estou desenhando agora uma reforma de cozinha, e me ocorreu que essas três restrições podem ser bem úteis também para trabalhos de design mais gerais, não só software
Vou tentar aplicar isso imediatamente
Talvez seja simples demais, mas fica mais interessante quando se pensa em espaço e fluxo
Dá para pensar no fluxo de pessoas, de luz, de comida e nas transições, o que é bem interessante
Acho que gostei do conteúdo porque combina com meus valores e preferências
(praticamente só para marcar presença)