O lançamento não é o produto inteiro
Um lançamento demonstra que é possível entregar um produto. A operação diária coloca outras perguntas. Um colega consegue compreender uma situação invulgar? Um cliente consegue recuperar após um passo errado? A equipa consegue alterar conteúdo sem iniciar um projeto de desenvolvimento? São questões de produto, mesmo quando chegam como pedidos de apoio ou tarefas operacionais.
A opinião tem um contexto
Operar um negócio liga diretamente o estúdio às condições de utilização. Um pedido de funcionalidade pode descrever um sintoma em vez da necessidade. A pergunta útil é o que a pessoa tentava fazer, o que aconteceu e por que razão isso importava naquele momento. Compreender o contexto ajuda a distinguir uma melhoria valiosa de mais uma definição ou um ecrã.
As pequenas dificuldades contam
Um produto pode ter uma ideia central forte e ainda assim criar pequenas dificuldades repetidas. Designações pouco claras, introdução duplicada de dados e passagens de informação difíceis exigem atenção de pessoas que têm outro trabalho para fazer. Observar estes detalhes faz parte do desenvolvimento de produto. Uma melhoria discreta num processo frequente pode ser mais útil do que uma adição vistosa de que poucos precisam.
Preparar a versão seguinte
Vemos a criação e a operação como responsabilidades ligadas. A arquitetura deve facilitar alterações quotidianas; o design deve tornar claras as responsabilidades; a próxima versão deve responder ao que realmente acontece. Isto não elimina a incerteza. Reduz a distância entre uma decisão de produto e a realidade que a deve informar.