Três restrições para impor antes de construir
(jordanlord.co.uk)- Ideias de produto devem começar com restrições para reduzir o espaço de exploração e evitar que o resultado fique complexo demais ou sem identidade
- Toda ideia deve caber em uma one pager; se não couber, isso indica que ainda faltam pesquisa, planejamento e prototipagem
- Junto com o produto, é preciso criar uma core tech que consiga sobreviver separadamente e permanecer como um ativo acumulativo, mesmo se houver mudança de direção
- No centro do produto deve existir uma defining constraint que continue visível para o usuário e que defina naturalmente o feel e a identidade do produto
- Se qualquer um dos três critérios não for atendido, a postura correta é não construir, o que é importante para o controle de escopo e para garantir alavancagem no longo prazo
Três restrições para impor antes de construir
- Colocar restrições antes de construir um produto reduz o espaço de exploração e evita que ele evolua para algo complexo demais ou sem identidade
- Ao longo de 10 anos criando vários produtos, produtos complexos demais ou sem identidade acabaram levando ao fracasso, e depois de muito aprendizado isso foi condensado em três critérios
-
Se passar de uma página, não construo
- Toda ideia deve ser organizada em uma one pager, e esse documento funciona como a north star
- A one pager deve ser inegociável, precisa, ambiciosa e ao mesmo tempo sem excessos
- O mesmo documento pode ser usado para se comunicar com investidores, colaboradores, membros da equipe, amigos e família
- Quando surgem conflitos durante a colaboração, algo que não está na one pager não vale a pena discutir; se for realmente importante, o documento deve ser corrigido para refletir isso
- Se você não consegue preencher uma página, não deve inflar o conteúdo à força; isso significa que ainda não está pronto para construir
- Nesse caso, é preciso passar primeiro por pesquisa, planejamento e prototipagem e depois reescrever a one pager
- Se passar de uma página, é complexo demais, então não construo
-
A tecnologia central deve ser separada do produto
- Além do produto em si, é preciso criar a core tech que sustenta esse produto
- 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 há 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 tipo de 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 no nível de grandes empresas; uma biblioteca separada da codebase ou uma metodologia continuamente refinada também podem servir
- A core tech deve ser independente da direção do produto, mas alinhada com a visão de longo prazo da pessoa ou da empresa
- Se a ideia não permite criar uma core tech, não há alavancagem suficiente
-
Uma única restrição decisiva deve definir o produto
- No centro do produto deve haver uma defining constraint sempre visível para o usuário
- Essa restrição deve ser algo com que o usuário se depara e interage continuamente, formando a identidade do produto
- Uma boa restrição cria o feel do produto e se espalha 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 autoassemblagem
- Esse tipo de restrição reduz o espaço de decisão, limita o escopo e ajuda a focar nos problemas realmente importantes
- Quando você não escolhe uma restrição, ou escolhe a errada, o produto tende a crescer demais tentando fazer tudo
- Quando a restrição é bem projetada, o design do produto passa a surgir naturalmente a partir dela
- Essa restrição também deve aparecer em destaque na one pager
Critério final
- Se qualquer uma das três restrições não for atendida, não construo
1 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