Porque você sempre deve falar com seu usuário final
Porque você sempre deve falar com seu usuário final Em diversos projetos e produtos aqui em nossa empresa encontramos dificuldades para convencer os nossos clientes da necessidade de validar as suas hipóteses de negócio com o usuário final e, assim, conseguir abrir um diálogo contínuo com quem realmente usa o seu produto. As questões que… Continuar lendo Porque você sempre deve falar com seu usuário final
Porque você sempre deve falar com seu usuário final
Em diversos projetos e produtos aqui em nossa empresa encontramos dificuldades para convencer os nossos clientes da necessidade de validar as suas hipóteses de negócio com o usuário final e, assim, conseguir abrir um diálogo contínuo com quem realmente usa o seu produto. As questões que normalmente são colocadas variam desde: “não podemos vazar informações confidenciais do projeto até que ele esteja pronto”, até “não podemos fazer isso por questão de contrato”, entre outras.
A ideia desse texto é tentar mudar essa mentalidade e explicar os benefícios que conseguimos obter quando estabelecemos um contato contínuo com o nosso cliente/usuário final. Em primeiro lugar, é importante deixar claro que existem algumas regras para a conversa com usuários finais do nosso produto. De acordo com Marty Cagan, são elas:
Proteger a marca: nenhuma ação, conversa ou interação que tivermos com o usuário final deve ter algum impacto negativo na marca. Nos casos em que a marca não deve ser revelada, é recomendável criar um nome fictício para conseguir estabelecer o mesmo diálogo.
Proteger o usuário/cliente: em hipótese nenhuma devemos expor o nosso usuário/cliente a uma situação que seja danosa para ele, como por exemplo pedir acesso a informações pessoais sem explicar como elas serão usadas ou pedir pagamento de qualquer forma sem que seja possível devolver um produto ou serviço relacionado. Em linhas gerais, não se deve fazer promessas ou ludibriar o cliente com a finalidade de validar a hipótese.
Proteger os funcionários: Em muitos casos, durante o processo de interação com o usuário final, os funcionários da empresa que representamos podem ser impactados. Imagine, por exemplo, um call-center tendo que responder perguntas que não faz ideia do que se trata, ou uma equipe comercial que não sabe responder a feedbacks obtidos nessas conversas.
Proteger a receita: nenhum experimento deve ter impacto negativo na receita atual da empresa. Considerando essas quatro leis gerais, conseguimos definir os limites dos nossos experimentos, o que evita dores de cabeça posteriores. Dito isso, vamos refutar uma pequena lista de argumentos usados para não falarmos com os usuários finais:
“Não é permitido por política da empresa”
Nenhuma política empresarial deveria impedir donos de produtos de falarem com os seus usuários. É mais fácil entender que nem todos da empresa possam acessar diretamente o usuário final, mas o product owner tem o dever e direito de fazer isso, uma vez que respeite as regras acima. Isso porque faz parte do seu trabalho validar todas as hipóteses da maneira mais empírica possível, e isso envolve o contato direto com o usuário final.
“Já temos um fale conosco ou um canal para isso”
Na maioria dos casos, esse tipo de feedback vai parar em áreas distantes do product owner, ou seja, não está sendo ouvido ou está sendo ouvido por pessoas que têm pouco impacto na direção final do produto. Em linhas gerais, o product owner tem que ser a principal pessoal a receber e interfacear com os usuários finais.
“Faremos testes de usabilidade em ambientes controlados”
Testes de usabilidade são uma parte importantíssima do processo de desenvolvimento e melhoria de um produto, mas nem de longe deveria ser a única fase em que você interage com o seu usuário final. Em muitos casos, na etapa de descoberta de novas funcionalidades para serem implementadas no produto, o diálogo vai ser pouco (ou quase nada) calcado em usabilidade, mas muito mais em pesquisas no geral.
“Nós já entendemos o usuário final”
Se você ouvir esse argumento de algum cliente, o problema é maior do que apenas conseguir falar com o seu usuário final. De qualquer forma, por mais que o usuário final seja entendido, ele muda com o tempo e é importante que o product owner acompanhe essas mudancas comportamentais. Só assim o PO consegue enxergar oportunidades de evolução para o produto.
“Eu sou o usuário final”
De novo, se você ouvir esse argumento o seu problema é maior. Mesmo assim, por mais imerso que você esteja no seu produto, é muito importante assumir que outros usuários não serão exatamente iguais a você e que podem ter necessidades, problemas e casos de uso diferentes dos seus. Só isso já justifica a abertura de um diálogo com o seu usuário final, mas é importante lembrar também que quanto mais imerso você está no produto, menos detalhes você consegue perceber.
“Nós já fizemos focus groups”
Não estamos propondo focus groups, mas a abertura de um diálogo contínuo com o seu usuário final. Ou seja, não basta chamar um grupo de pessoas em apenas um determinado momento para pedir opiniões, sugestões e críticas. É preciso ter um feedback contínuo do usuário final. Quando não for possível diariamente, que seja semanalmente ou no menor período possível.
Nosso objetivo é estabelecer um diálogo contínuo com o nosso cliente/usuário final d
e forma que toda e qualquer hipótese que seja levantada em relação ao produto consiga ser qualitativamente validada. Isso é feito por meio da criação de um “Customer Council”, um grupo dos top 30 usuários do seu produto que você pode acessar continuamente para ter um diálogo franco e aberto sobre como resolver os problemas do produto e do usuário final.
A meta é experimentar nossas hipóteses, ideias e soluções em usuários reais de forma contínua. Construir, aprender, ajustar e iterar. E iterar no produto dentro da própria empresa sem validar com clientes finais faz com que o produto fique direcionado com a sua visão. Ou com a visão do seu time.
E você quer que o produto fique direcionado com a visão de pessoas que vão utilizá-lo. Você quer resolver problemas e necessidades de pessoas reais. Qualidade aqui não é só um produto com zeros bugs com uma boa interface. Qualidade é um produto que possui proposta de valor. De que adianta um produto com zero bugs que ninguém usa?
E se quisermos construir um produto de qualidade, que resolva o problema e necessidades reais precisamos “entrar” dentro da cabeça de nossos usuários ou clientes. E a única forma de fazer isso é falar com pessoas. Why so fear?
Fonte: EcommerceBrasil
