UX and product management

Posted on 08/30/2022 by Joca

The next area I want to comment on is the UX area which, along with product engineering and product management, forms the core product development team.

What is UX?

User Experience
The “user experience” encompasses all aspects of end user interaction with the company, its services and its products. Source: Nielsen Norman Group The definition of user experience, 2015.

This is a fairly simple definition, but it does cover all aspects of UX. Software developers tend to think that UX is the interface of the digital product, both from the point of view of planning user interaction with the product and from a visual point of view. Yes, UX is that, but not only that. UX is also concerned about what this product causes for those who use it.

According to ISO 9241-210, entitled Ergonomics of Human-System Interaction, which provides guidance on human-system interaction throughout the life cycle of interactive systems:

User Experience
User experience is “a person’s perceptions and responses that result from the use or anticipated use of a product, system, or service.” According to the ISO definition, user experience includes all user emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors, and achievements that occur before, during, and after use. ISO also lists three factors that influence the user experience: the system, the user, and the context of use. Source: Wikipedia.

UX in Product Development Process

In the product development process, UX is responsible for thoroughly understanding the user and the problem to be solved for that user. The following figure illustrates well the role of UX as well as product engineering and product management in the development process.

In the product discovery, UX has a central role. The first step is to understand the user, the person who will use the digital product. For this, UX uses a tool called persona, which represents a group of users with similar behavior patterns, attitudes and motivations in terms of purchasing decision, use of technologies or products, lifestyle, etc.

Personas are used to:

Know and understand customers and users of products and services;
Bring the user to the project focus;
Make design decisions more humane and less abstract.

In the chapter Growth: What is and how to create the product vision and strategy? I described the process of creating personas, as they are very useful tools in creating your product vision. Remember Maria, the cool girl and Michelle, the busy?

Then, based on a lot of research to fully understand the problems and needs of these personas, UX builds the prototype that will begin to materialize the product idea. This prototype should be used in conversations with customers and users to validate if the idea makes sense, as well as conversations with the product engineering team so that they can already understand what lies ahead and whether technology is available to do so.

It is very different to hear a product or feature description. For example: imagine someone telling you that “you will see a screen with login and password, and an enter button. You will also see a link if you have forgotten your password”. It’s not easy to picture this without a real image. The first version can be a paper or whiteboard drawing:

The prototype is also very important as a communication tool with product engineering. Showing the prototype makes it easier for engineers to evaluate the difficulty of implementing each feature.

When I made ContaCal, as my drawing skills are not the best, I chose to use PowerPoint as my tool for drawing the prototype:

Once the basic features are agreed upon, this prototype can be made on a computer. The first version of the prototype made on the computer is usually only in black and white, with only the contours of the elements, and no images. This version is often called wireframe:

The next step is the UX team preparing a usable prototype (or wireframe), that is, one that already has the interacting behavior for you (product manager and UX analyst) to show customers and users so that they can test and interact. Next, the UX visual designer begins to put color and shape on these screens to make them the version the users will actually see.

With a prototype in hand, usability testing can be done to identify usability issues or validate interface solutions. To do this test, users are invited to perform certain tasks on the prototype. During the test, you can observe user behavior when performing a set of proposed tasks, and identify the difficulties and motivations behind some of their decisions when interacting with the product. The user is encouraged to verbalize his actions, opinions, and feelings so that we know the mental model created by him.
This prototype will guide the engineering team in developing the product. It is the specification of the product, but remember that it is not written in stone. For this reason, the UX team doesn’t deliver the prototype to you and the engineering team, and then they go do something else. The UX person who designed the prototype should continue with the product manager and engineering team as it is being built to adjust the prototype (if necessary), discover improvements, and bring the engineering team closer to the user’s needs.

What else do UX people do?

Another point where UX people actively participate is in defining and tracking metrics. As I said in the Growth: what is a roadmap? chapter, every item in a roadmap must have its motivation and its metrics. The UX designer should know very well what this motivation is when she designs the prototype and should work closely with the product manager and engineering team to define which metrics to follow to measure if the motivation has been hit.

The UX person also talks a lot with the user. She will be your primary companion in these conversations and interactions with the user, and will always be focused on what is best for the user. Your role will always be to bring the rest of the context, that is, besides being good for the user, it needs to be good for the company that owns the digital product you are developing.

It must also create interaction patterns. Every time a new feature is developed, you shouldn’t be drawing it from scratch. It is important to have an interaction and design pattern library. At Locaweb, we created Locaweb Style, with our interaction patterns, and published it as open source.

What is the relationship between UX and product management?

As I mentioned in the previous chapter, the fact that the product manager is responsible for defining the product to be made can give the impression that UX reports to product management. This is an incorrect view, and if the areas see it with this reporting structure, the chances of the product failing increase because people who feel subordinate have less commitment to the outcome. UX and product management, as well as software engineering, should be viewed as a team, with no reporting relationship and functioning as collaborating partners to produce the best product possible.

UX will always feather their own nest focusing on the user’s side, and will always want to do what is best for them from both function (interaction) and form (visual) points of view. And that’s good! If the UX team is a good team, they will always be feathering their own nest to make the most perfect product from the user’s point of view, just as the engineering team will be feathering their own nest to the technical side, always proposing to rewrite the product and each feature since they just found a better technical solution. It will be up to the product manager to defend the interests of the company that owns the software and finds and proposes a balance between these needs.

Oh, and there’s one more thing!

Like product engineers, some UX designers turn out to be great product managers. It’s important to be able to figure out when a designer is looking for “something else to do” and give him that career choice. At Locaweb we have great product managers who were UX designers. In some cases, they ended up becoming product managers of the product for which they were responsible for UX. On the other hand, there are also some UX designers who try product management and don’t like it.

This situation is less common because, unlike the product engineer, the UX designer is normally used to talking a lot with the user and other product-related areas, so product management work is not so foreign to him. Even so, you have to leave the door open for him to be able to become a UX designer again, without prejudice to his career.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

Startup Guide: How startups and established companies can create profitable digital products
Product Management: How to increase the chances of success of your digital product
Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

UX e Gestão de Produtos

Posted on 08/30/2022 by Joca

A próxima área que quero comentar é a área de UX que, junto com engenharia e gestão de produtos, forma o core team de desenvolvimento de produtos.

O que é UX?

Experiência do Usuário
A “experiência do usuário” engloba todos os aspectos da interação do usuário final com a empresa, seus serviços e seus produtos. Fonte: Nielsen Norman Group – The Dinifition of User Experience – 2015.

Essa é uma definição bastante simples, mas ela realmente contempla todos os aspectos de UX. Quem trabalha com software tem a tendência de achar que UX é a interface do software, tanto do ponto de vista do planejamento da interação do usuário com o software quanto do ponto de vista visual. Sim, UX é isso, mas não é só isso. UX também se preocupa com o que esse software causa para quem o usa.

De acordo com a ISO 9241-210, intitulada Ergonomia da interação humano-sistema, que fornece orientações sobre a interação humano-sistema durante todo o ciclo de vida de sistemas interativos:

Experiência do Usuário
Experiência do usuário são “as percepções de uma pessoa e as respostas que resultam do uso ou uso antecipado de um produto, sistema ou serviço.” De acordo com a definição ISO, experiência do usuário inclui todas as emoções dos usuários, crenças, preferências, percepções, respostas físicas e psicológicas, comportamentos e realizações que ocorrem antes, durante e após o uso. A ISO também lista três fatores que influenciam a experiência do usuário: o sistema, o usuário e o contexto de uso. Fonte: Wikipedia.

UX no Processo de Desenvolvimento de Produtos

No processo de desenvolvimento de produtos, UX é o responsável por entender a fundo o usuário e o problema que se deseja resolver para esse usuário. A figura a seguir ilustra bem o papel de UX bem como o de engenharia de produtos e o de gestão de produtos, no processo de desenvolvimento.

Na fase de concepção do produto, UX tem um papel central. O primeiro passo é entender o usuário, a pessoa que vai usar o produto de software. Para isso, UX utiliza uma ferramenta chamada persona, que representa um grupo de usuários com padrões de comportamento, atitudes e motivações similares em termos de decisão de compra, de uso de tecnologias ou produtos, de estilo de vida etc.

As personas são usadas para:

Conhecer e entender clientes e usuários de produtos e serviços;
Trazer o usuário para o foco do projeto;
Tornar as decisões de design mais humanas e menos abstratas.

No capítulo Crescimento: o que é e como criar a visão e a estratégia do produto? descrevi o processo de criação das personas, por serem ferramentas muito úteis na criação de sua visão de produto. Lembra da Maria, a descolada e da Michelle, a ocupada?

Baseado em muita pesquisa para entender a fundo os problemas e necessidades dessas personas, o UX constrói o protótipo que começará a materializar a ideia do produto. Esse protótipo deverá ser usado nas conversas com clientes e usuários, para validar se a ideia faz sentido, como também nas conversas com o time de engenharia de produtos, para que eles já possam entender o que vem pela frente e se há tecnologia disponível para fazer.

É muito diferente ouvir a descrição de um produto ou funcionalidade com, por exemplo: “Você vai ver uma tela com login e senha, e um botão de entrar. Também verá um link caso você tenha esquecido sua senha”; e ver a tela onde essa funcionalidade acontece. A primeira versão pode ser um desenho em papel ou em quadro branco:

O protótipo também é muito importante como ferramenta de comunicação com a engenharia de produtos. Mostrando o protótipo, fica mais fácil para os engenheiros avaliarem a dificuldade de implementação de cada funcionalidade.

Quando fiz o ContaCal, como minhas habilidades de desenho não são as melhores, optei por usar o PowerPoint como minha ferramenta para desenhar o protótipo:

Depois de acordadas as funcionalidades básicas, esse protótipo pode ser feito em computador. A primeira versão do protótipo feita no computador é normalmente só em preto e branco, só com os contornos dos elementos. Essa versão é muitas vezes chamada de wireframe:

O próximo passo é o time de UX preparar um protótipo (ou wireframe) navegável, ou seja, um que já tenha o comportamento de interação para que vocês (gestor de produtos e analista de UX) possam mostrar para clientes e usuários, para que eles possam testar e interagir. Em seguida, o designer visual de UX começa a colocar cor e forma nessas telas, para transformá-las na versão que os usuários de fato verão.

Com um protótipo em mãos, é possível fazer testes de usabilidade para identificar problemas de usabilidade ou validar soluções de interface. Para fazer esse teste, convidam-se usuários para executar determinadas tarefas em seu protótipo. Durante o teste, é possível observar o comportamento do usuário ao realizar um conjunto de tarefas propostas, além de identificar as dificuldades e os motivos para algumas de suas decisões, ao interagir com o produto. O usuário é incentivado a verbalizar suas ações, opiniões e sensações para que, dessa forma, conheçamos o modelo mental criado por ele.

Esse protótipo servirá de guia para o time de engenharia desenvolver o produto. É a especificação do produto; mas lembre- se de que ela não é escrita em pedra. Por esse motivo, o time de UX não entrega o protótipo para você e para o time de engenharia, e depois vai fazer outra coisa. A pessoa de UX que desenhou o protótipo deve continuar junto com o gestor de produtos e com o time de engenharia enquanto ele estiver sendo desenvolvido para ajustar o protótipo (se necessário), descobrir melhorias e aproximar o time de engenharia das necessidades do usuário.

O que mais o pessoal de UX faz?

Outro ponto em que o pessoal de UX participa ativamente é na definição e acompanhamento das métricas. Como disse no capítulo Crescimento: o que é um roadmap?, todo item de um roadmap deve ter sua motivação e sua métrica. O designer de UX deve saber muito bem qual é essa motivação quando ele vai desenhar o protótipo, e deve trabalhar junto com o gestor de produtos e com o time de engenharia para definir qual(is) métrica(s) acompanhar para medir se a motivação foi atingida.

O profissional de UX também conversa muito com o usuário. Ele será seu principal companheiro nessas conversas e interações com o usuário, e vai estar sempre focado no que é melhor para o usuário. Seu papel será sempre colocar o resto do contexto, isto é, além de ser bom para o usuário, precisa ser bom para a empresa que é dona do software que vocês estão desenvolvendo.

Ele também deve criar padrões de interação. Não dá para, toda vez que for desenvolvida uma nova funcionalidade, desenhar do zero. É importante ter um padrão pronto. Na Locaweb, criamos o Locaweb Style, com nossos padrões de interação, e o publicamos como open source (http://opensource.locaweb.com.br/locawebstyle).

Qual é a relação entre UX e gestão de produtos?

Como comentei no capítulo anterior, o fato de o gestor de produtos ser responsável por definir o produto a ser feito, pode dar a impressão de que UX está subordinada à gestão. Essa é uma visão incorreta e, se as áreas entenderem como certa, as chances de o produto fracassar aumentam, pois pessoas que se sentem subordinadas têm menor comprometimento com o resultado. UX e gestão de produtos, assim como a engenharia de software, devem ser vistos como um time, sem relação de subordinação e funcionando como parceiros que colaboram para produzir o melhor produto possível.

O UX sempre “puxará a sardinha” para o lado do usuário, e sempre vai querer fazer o que for melhor para este tanto do ponto de vista de função (interação) quanto do ponto de vista de forma (visual). E isso é bom! Se o time de UX for um time bom, ele sempre estará “puxando essa sardinha”, da mesma forma que o time de engenharia estará “puxando a sardinha” para o lado técnico, propondo sempre o trabalho de reescrita. Caberá ao gestor de produtos defender os interesses da empresa, que é dona do software, e encontrar e propor um balanço entre essas necessidades.

Ah, e tem mais um ponto!

Assim como os engenheiros de produtos, alguns designers de UX acabam se tornando ótimos gestores de produtos. É importante ser capaz de perceber quando um designer está procurando “outra coisa para fazer” e dar a ele essa opção de carreira. Na Locaweb temos ótimos gestores de produtos que eram designer de UX. Em alguns casos acabaram se tornando gestor de produtos do próprio produto dos quais eram responsáveis por UX. Por outro lado, também existem alguns designers de UX que experimentam a gestão de produtos e não gostam.

Essa situação é menos comum de acontecer pois, diferentemente do engenheiro de produto, o designer de UX normalmente está acostumado a conversar bastante com o usuário e com as outras áreas relacionadas ao produto, por isso o trabalho de gestão de produtos não lhe é tão estranho. Mesmo assim, é preciso deixar a porta aberta para ele poder voltar a ser designer de UX, sem nenhum prejuízo para a sua carreira.

Product leadership advisor

Gestão de produtos digitais

Este artigo é mais um capítulo do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

Another example of an MVD – Minimum Viable Discovery

Posted on 04/19/2022 by Joca

Lopes is the biggest real estate company in Brazil, where I’m leading the digital transformation efforts. A new hire who came from an e-commerce site mentioned that app push notifications generated more leads and had greater conversion rates than SMS and email marketing. We got interested in testing this hypothesis, but always with the MVD – Minimum Viable Discovery mindset that I explained earlier.

How could we test this hypothesis as fast and cheaply as possible? Building an entire native app with all the features of our existing website would take months. Even if we scoped it down a lot, with the minimum to deliver some value to the user, it still would take many weeks.

Since our website is responsive, we devise a simple solution to test the hypothesis. We decided to create a webview app, a simpler solution than building a native app, eve if we scoped it to a minimum.

By the way, this is how Facebook and Linkedin launched their first mobile apps as well. Only when they the results generated by a mobile app, and proved that a native version would bring even more results, they decided to invest in building their native apps.

Here’s Lopes’ mobile app:

With this mobile app we were able to confirm that push notification generated more leads and had greater conversion rates than SMS and email marketing. We launched this app in early 2021.

I already heard that MVP doesn’t scale, it is just to test a solution hypothesis and then, if the solution hypothesis, we should work on delivering the solution in a scalable manner. As with everything related to product management, it depends! In our case, untill now we haven’t had the need to build a native version of this mobile app. The webview version is working quite fine for our needs and users seem to be ok with it as well. Maybe in the future we’ll have the need to build a native app but, at least for now, after more than one year that we launched our webview mobile app, there’s still no need to build the native mobile app.

You cantry Lopes App for Android or iOS.

Summing up

MVD – Minimal Viable Discovery mindset is essential to deliver results as fast as possible. For instance, why building a native mobile app to test some hypothesis if a webview is enough to test it?

The “MVP doesn’t scale” affirmation is not necessarily true. As everything related to product management, it depends. In our case, after more than a year after launching the MVP we created to test our Discovery Solution hypothesis, our webview app, we haven’t had the need to build a native app.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Digital Product Management Books

Startup Guide: How startups and established companies can create profitable digital products
Product Management: How to increase the chances of success of your digital product
Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

Outro exemplo de um MVD – Minimum Viable Discovery (Descoberta Mínima Viável)

Posted on 04/19/2022 by Joca

A Lopes é a maior imobiliária do Brasil, onde lidero os esforços de transformação digital. Uma nova pessoa que se juntou a gente e que veio de um site de comércio eletrônico mencionou que as notificações push do aplicativo geravam mais leads e tinham maiores taxas de conversão do que SMS e email marketing. Ficamos interessados em testar essa hipótese, mas sempre com a mentalidade MVD – Minimum Viable Discovery que expliquei anteriormente.

Como poderíamos testar essa hipótese o mais rápido e barato possível? Construir um aplicativo nativo com todos os recursos do nosso site existente levaria meses. Mesmo que reduzíssemos muito o escopo, com o mínimo para entregar algum valor ao usuário, ainda levaria muitas semanas.

Como nosso site é responsivo, criamos uma solução simples para testar a hipótese. Decidimos criar um aplicativo webview, uma solução mais simples do que construir um aplicativo nativo, mesmo que o limitássemos o escopo ao mínimo.

Aliás, foi assim que o Facebook e o Linkedin também lançaram seus primeiros aplicativos móveis. Somente quando perceberam os resultados gerados por um app, e comprovaram que uma versão nativa traria ainda mais resultados, decidiram investir na construção de seus aplicativos nativos.

Aqui está o aplicativo móvel de Lopes:

Com este aplicativo móvel pudemos confirmar que a notificação push gerou mais leads e teve maiores taxas de conversão do que SMS e email marketing. Lançamos este aplicativo no início de 2021.

Já ouvi dizer que MVP não escala, é só para testar uma hipótese de solução e então, se a hipótese de solução for comprovada, devemos trabalhar para entregar a solução de forma escalável. Como em tudo relacionado ao gestão de produtos, depende! No nosso caso, até agora não tivemos a necessidade de construir uma versão nativa deste aplicativo móvel. A versão webview está funcionando muito bem para nossas necessidades e os usuários parecem estar ok com isso também. Talvez no futuro tenhamos a necessidade de construir um aplicativo nativo mas, pelo menos por enquanto, depois de mais de um ano que lançamos nosso aplicativo móvel, webview ainda não há necessidade de construir o aplicativo móvel nativo.

Você pode experimentar o Lopes App para Android ou iOS.

Resumindo

A mentalidade MVD – Minimal Viable Discovery é essencial para entregar resultados o mais rápido possível. Por exemplo, por que construir um aplicativo móvel nativo para testar alguma hipótese se uma visualização da web é suficiente para testá-la?

A afirmação “MVP não escala” não é necessariamente verdadeira. Como tudo relacionado à gestão de produtos, depende. No nosso caso, mais de um ano após o lançamento do MVP que criamos para testar nossa hipótese de Discovery Solution, nosso aplicativo webview, não tivemos a necessidade de construir um aplicativo nativo.

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenho ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
Gestão de produtos: Como aumentar as chances de sucesso do seu software.
Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.

The 2 sides of Product Discovery

Posted on 01/31/2022 by Joca

By the end of 2021, I had the opportunity to re-record the classes I gave at Cursos PM3 on the fundamentals of product management. It was a good opportunity to review and expand the content based on the new experience acquired in recent years. One topic that I decided to expand on was the role of product management, design (UX), and engineering in discovery/delivery.

Discovery is normally led by product management and UX with some support from someone from engineering. It is when we focus on identifying and understanding the problem of users and test possible ways to solve this problem while checking if this possible solution will positively impact the business’s strategic objectives.

Delivery is normally led by product engineering with some support from the product manager and product designer. It is when we focus on delivering the solution we tested that showed the best indicators of its ability to solve our users’ problems while helping the company achieve its business strategic objectives.

These two tasks are not sequential, i.e., we should not wait until discovery is completed to a certain level in order to start delivery. Ideally, we should be constantly discovering and delivering and, in order to do that, we need to break down problems into their smaller sub-problems and test the most simple solution hypothesis to each of these smaller sub-problems.

The two sides of discovery

When we discuss discovery and delivery, we normally leave out of discussion or, at most, discuss very lightly the fact that discovery has two sides or two perspectives:

Problem discovery: this is when we are trying to understand the problem (or need) of our customer, how this problem is connected to our company business strategic objectives, the motivation the customer has to want this problem solved, when, where, how and why this problem occurs, if there are solutions to this problem and what our customer thinks about these solutions. It’s all about the problem and it’s mainly led by the product manager and product designer.

Solution discovery: when we start to gain some understanding of the problem to be solved, we need to discover possible solutions for this problem. This is when we generate and test solution ideas and hypotheses in the simplest way possible with prototypes, proof of concept, and other similar low-code or no-code techniques. This helps everyone in the product development team to understand better how to maximize the value to be delivered during the delivery while minimizing the risk and time of this delivery. For this reason, during solution discovery, the entire product development team (product managers, designers, and engineers) should get involved equally.

Problem discovery, solution discovery, and delivery

Simoultaneous tasks

As I mentioned earlier we should not wait until a task is completed to a certain level in order to start another task. They should be carried out simultaneously and the learnings and results from one task are a valuable input to the other task. During Problem Discovery, the product manager and designer are more involved. During solution Discovery, everyone should get involved. During Delivery, engineering is more involved. The image below tries to make these concepts more tangible:

One interesting tool to help during both problem discovery and solution discovery is Teresa Torres’ Opportunity Tree (as far as I know we are not related (= ):

Opportunity Solution Tree (source: ProductTalk)

Using this tool we can make clear to everyone, especially to ourselves and our team:

what is the desired outcome, normally some objective aligned with the company’s strategic objectives?
what are the opportunities (problems or needs) that when tackled can help us get closer to the desired outcome?
what are the solution hypotheses that can help us tackle each opportunity?
what are the experiments, preferably the simplest and easiest ones, that will help us test the solution hypothesis?

From the description above it is easy to see that desired outcome and opportunities are problem discovery-related while solution hypothesis and experiments are solution discovery-related.

Opportunity Solution Tree clearly shows the problem discovery and solution discovery tasks.

So there you go, whenever you work on product discovery, remember its two sides, problem discovery, and solution discovery. It will make it easier for you and your team to understand what is the focus of each task.

Digital Product Management Books

Startup Guide: How startups and established companies can create profitable digital products
Product Management: How to increase the chances of success of your digital product
Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Os dois lados do Product Discovery

Posted on 01/31/2022 by Joca

No final de 2021 tive a oportunidade de regravar as aulas que dei nos Cursos PM3 sobre os fundamentos da gestão de produtos. Foi uma boa oportunidade para rever e expandir o conteúdo com base na minha experiência adquirida nos últimos anos. Um tópico que decidi expandir um foi sobre o papel da gestão de produtos, product design (UX) e engenharia no discovery / delivery.

Discovery é normalmente liderado pela gestora de produtos e pela designer de produto com algum suporte de alguém da engenharia. É quando nos concentramos em identificar e entender o problema dos usuários e testar possíveis formas de resolver esse problema, ao mesmo tempo em que verificamos se essa possível solução impactará positivamente os objetivos estratégicos do negócio.

O delivery é normalmente liderado pela engenharia de produto com algum suporte da gestora de produto e da designer de produto. É quando focamos em entregar a solução que testamos que apresentou os melhores indicadores de sua capacidade de resolver o problema de nossos usuários enquanto ajudamos a empresa a atingir seus objetivos estratégicos de negócios.

Essas duas tarefas não são excludentes, ou seja, não devemos esperar até que o discovery seja concluído para iniciar o delivery. Idealmente, devemos estar constantemente descobrindo e entregando e, para isso, precisamos decompor os problemas em seus subproblemas menores e devemos testar as hipóteses de solução mais simples para cada um desses subproblemas menores.

Os dois lados do discovery

Quando falam os sobre discovery e delivery e normalmente deixamos de lado ou, no máximo, discutimos muito levemente sobre o fato de que a descoberta tem dois lados, ou duas perspectivas:

Descoberta do problema: quando estamos tentando entender o problema (ou necessidade) do nosso cliente, como esse problema está conectado aos objetivos estratégicos de negócios da nossa empresa, a motivação que o cliente tem para querer que esse problema seja resolvido, quando, onde, como e por que esse problema ocorre, se existem soluções para esse problema e o que nosso cliente pensa sobre essas soluções. O problema é o foco e essa tarefa é liderada principalmente pela gestora de produto e pelo designer de produto.

Descoberta da solução: quando começamos a entender o problema a ser resolvido, precisamos descobrir possíveis soluções para esse problema. É quando geramos e testamos ideias e hipóteses de solução da maneira mais simples possível com protótipos, provas de conceito e outras técnicas semelhantes de low-code ou no-code. Isso ajuda todos na equipe de desenvolvimento de produtos a entender melhor como maximizar o valor a ser entregue durante o delivery, minimizando o risco e o tempo desse delivery. Por esse motivo, durante a descoberta da solução, toda a equipe de desenvolvimento de produto (gestora de produto, designer de produto e engenheiras) deve se envolver igualmente.

Descoberta de problemas, descoberta de soluções e delivery

Tarefas Simultâneas

Como mencionei anteriormente, não devemos esperar até que uma tarefa seja concluída para iniciar outra tarefa. Elas devem ser realizados simultaneamente e os aprendizados e resultados de uma tarefa são valiosos insumos para a outra. Durante a descoberta de problemas, a gestora de produto e a product designer estão mais envolvidos. Durante a descoberta da solução, todos devem se envolver, gestora de produto, product designer e engenheiras de produto. Durante o delivery, a engenharia está mais envolvida. A imagem abaixo tenta tangibilizar esses conceitos:

Uma ferramenta interessante para ajudar tanto na descoberta de problemas quanto na descoberta de soluções é a Árvore de Oportunidades de Teresa Torres (até onde sei não somos parentes (= ):

Árvore de oportunidades e soluções (fonte: ProductTalk)

Usando esta ferramenta podemos deixar claro para todos, especialmente para nós mesmos e nossa equipe:

qual é o resultado desejado (desired outcome), normalmente algum objetivo alinhado com os objetivos estratégicos da empresa,
quais são as oportunidades (problemas ou necessidades) que quando trabalhadas podem nos ajudar a chegar mais perto do resultado desejado.
quais são as hipóteses de solução que podem nos ajudar a enfrentar cada oportunidade.
quais são os experimentos, provavelmente os mais simples e fáceis, que nos ajudarão a testar a hipótese da solução.

A partir da descrição acima, é fácil ver que o resultado desejado e as oportunidades estão relacionados à descoberta do problema, enquanto as hipóteses de solução e os experimentos estão relacionados à descoberta da solução.

A Árvore de Oportunidades e Soluções mostra claramente as tarefas de descoberta de problemas e de descoberta de soluções.

Pronto, de agora em diante, sempre que trabalhar em product discovery, lembre-se de seus dois lados, descoberta de problemas e descoberta de soluções. Isso tornará mais fácil para você e sua equipe entender qual é o foco de cada tarefa.

Gestão de produtos digitais

Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
Gestão de produtos: Como aumentar as chances de sucesso do seu software.
Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

UX and product management

Posted on 02/11/2020 by Joca

I spoke previously about the relationship between Engineering and Product Management.

The next area I want to comment on is the UX area which, along with product engineering and product management, forms the core product development team.

What is UX?

Here’s a good definition of UX from Nielsen Norman Group:

User experience encompasses all aspects of end-user interaction with the company, its services, and its products.

According to ISO 9241-210, entitled Ergonomics of Human-System Interaction, which provides guidance on human-system interaction throughout the life cycle of interactive systems:

User experience is “a person’s perceptions and responses that result from the use or anticipated use of a product, system or service.” According to the ISO definition, user experience includes all user emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and achievements that occur before, during and after use. ISO also lists three factors that influence the user experience: the system, the user, and the context of use.

UX in the Product Development Process

In product discovery, UX has a central role. The first step is to understand the user, the person who will use the digital product. For this, UX uses a tool called persona, which represents a group of users with similar behavior patterns, attitudes and motivations in terms of purchasing decision, use of technologies or products, lifestyle, etc.

Personas are used to:

Know and understand customers and users of products and services;
Bring the user to the project focus;
Make design decisions more humane and less abstract.

The following figure shows how to build a persona:

The first step is to define a name and some characteristics of this persona. This helps in conversations about the product. In the name, it is cool to give a hint of the main characteristic of the persona. For instance, Maria, the cool girl or Michelle, the busy woman.

If you are making a product for Michelle, the busy woman and want to insert a new feature, the question is: “Can Michelle, the busy woman be able to use this feature? Will she find it useful enough to find time to learn how to use it.?” In addition to the name and basic characteristics, it is also important to describe the behaviors and problems. The following examples will clarify the concept of persona.

Maria, the cool girl is one of the personas we used at Locaweb. Given the different products we had in our portfolio, we ended up building eight personas. However, for each product in our portfolio, we have about 3 or at most 4 personas, one of which is the primary product persona, that is, for whom all your software product decisions are made.

The prototype is also very important as a communication tool with product engineering. Showing the prototype makes it easier for engineers to evaluate the difficulty of implementing each feature.

When I made ContaCal, as my drawing skills are not the best, I chose to use PowerPoint as my tool for drawing the prototype:

This prototype will guide the engineering team in developing the product. It is the specification of the product, but remember that it is not written in stone. For this reason, the UX team doesn’t deliver the prototype to you and the engineering team, and then they go do something else. The UX person who designed the prototype should continue with the product manager and engineering team as it is being built to adjust the prototype (if necessary), discover improvements, and bring the engineering team closer to the user’s needs.

What else do UX people do?

Another point where UX people actively participate is in defining and tracking metrics. As I said in the What is a roadmap? article, every item in a roadmap must have its motivation and its metric. The UX designer should know very well what this motivation is when she designs the prototype and should work closely with the product manager and engineering team to define which metrics to follow to measure if the motivation has been hit.

What is the relationship between UX and product management?

UX will always feather their own nest focusing on the user’s side, and will always want to do what is best for them from both function (interaction) and form (visual) points of view. And that’s good! If the UX team is a good team, they will always be feathering their own nest to make the most perfect product from the userâ€™s point of view, just as the engineering team will be feathering their own nest to the technical side, always proposing to rewrite the product and each feature since they just found a better technical solution. It will be up to the product manager to defend the interests of the company that owns the software and find and proposes a balance between these needs.

Oh, and there’s one more thing!

Like product engineers, some UX designers turn out to be great product managers. It’s important to be able to figure out when a designer is looking for “something else to do” and give him that career choice. At Locaweb we have great product managers who were UX designers. In some cases they ended up becoming product managers of the product of which they were responsible for UX. On the other hand, there are also some UX designers who try product management and don’t like it.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

Innovation: Next steps

Posted on 08/01/2017 by Joca

This is the last article of a series on innovation. Here’s the list of my previous articles on the topic in case you missed or want to reread:

Now that you read or reread my previous articles on innovation, let’s move to the last article of the series.

Innovation: Next steps

Once you discovered a problem of a group of people, got to the bottom of it, of its context and the motivations that people have to solve this problem, you analyze the opportunity in details. You evaluate if it is worth to develop the software product. You evaluate how to cover the costs of the development and the operation. And then you go for it.

There’s an enormous amount of books that talk about the subject and, if I would approach the subject in this book, it would probably double its size. That’s why I prefer recommending some book references that I find interesting on this matter. Moreover, software product development has been a much explored topic in several articles, talks and books about startups. In a way, startup and software product development can be considered synonyms.

And here is the list:

To the point: a recipe for creating lean products, by Paulo Caroli, in which he shares a sequence of quick activities to understand and plan the creation of lean products, based on the concept of minimum viable product.
Getting real: the smarter, faster, easier way to build a successful web application, by Jason Fried, David Heinemeier Hansson and Matthew Linderman. This book tells how the guys from 37signals built their successful products. It holds lots of practical tips.
The entrepreneur’s guide to customer development: a cheat sheet to The Four Steps to the Epiphany, by Brant Cooper and Patrick Vlaskovits. Steve Blank, a serial entrepreneur from Silicon Valley wrote a book called The Four Steps to the Epiphany: successful strategies for products that win, that approaches generically the startup subject but creates a very important concept, of customer development. According to his experience, startups donÃt die from the difficulty of making a good product, but from the difficulty in finding clients for it. Hence the idea of search and develop the client before search and develop the product. The problem is that Steve BlankÃs book is very dense, so Brant and Patrick made an excellent summary of 104 pages in which they explain in details the concept of customer development.
Where good ideas come from: the natural history of innovation, by Steven Johnson, author of several interesting books about science and knowledge. In this book, he explains what are the main ingredients of innovation, especially the need of multi-disciplinary teams in order to make possible to see the same problem from different perspectives.
The little black book of innovation: how it works, how to do it, by Scott D. Anthony, business partner of professor Clayton Christensen in an innovation consulting company called Innosight. In this book, he defines innovation as something different that has an impact. From this point on, he presents a step-by-step guide to find and test innovation opportunities.
Crossing the chasm: marketing and selling high-tech products to mainstream customers. Written in 1991 by Geoffrey Moore, who wrote the book in which he explains that between the *early adopters* and the *early majority* there is an abyss that many products are not able to cross, since the latter ones need good references to buy a new product and the first ones usually are not a good reference. In this book, Moore also proposes strategies based in war tactics.
Running lean: iterate from Plan A to a plan that works, by Ash Maurya. In 2010, Alexander Osterwalder and Yves Pigneur presented a new framework to analyze business models, the Business Model Canvas (BMC). I really appreciate this framework, but the BMC seems to me more focused on settled companies rather than startups. In 2012, Ash Maurya created a framework based on Business Model Canvas, but more relevant to new businesses for it approaches problem, solution and metrics.
The lean startup: how today’s entrepreneurs use continuous innovation to create radically successful businesses, by Eric Ries, a close friend of Steve Blank. This book resulted from the Startup Lessons Learned blog, that he wrote and is still writing about his experiences with his startup. It is also focused on general startups, not only the ones on software product. It even approaches a non-governmental organization, well-known concepts such as MVP (Minimal Viable Product) and the feedback cycle Build-Measure-Learn.

Good reading, good product development and brace yourself for the next stage: growth (or the abyss!), our next subject.

Digital Product Management Books

Innovation: a lot of opportunities

Posted on 05/30/2017 by Joca

It is likely that, after focusing on the problem and understanding the job to be done, as described in the previous articles, you will find not only one but a few opportunities to develop a new product or new features for your software product.

I’ve never seen in an organization where there’s abundance of resources and scarcity of opportunities. Usually, there are always a lot of opportunities ahead, and we don’t know which ones to pursue, because we can’t go after all of them since we don’t hold the necessary resources (time, money and people) available.

In these situations, I like using the opportunity assessment model, proposed by Marty Cagan in his book Inspired: how to create products customers love. Cagan is ex-VP of product management at eBay and currently works as a product management consultant.

Answering these 10-questions set, we can gather more information to decide if it’s worth to pursue a given opportunity or if it’s best to re-evaluate it in the future. The questions are very simple:

Which problem will it solve? (value proposition);
To whom this problem will be solved? (target market);
What is the size of this opportunity? (market size);
What are the alternatives? (competition scenario);
Why are we better qualified to pursue this opportunity? (our uniqueness);
Why now? (window of opportunity);
How are we going to take this opportunity to the market? (launching strategy);
How are we going to measure success and make money with this product? (metrics and revenue);
What are the critical factors for success? (essential requirements);
After answering the above, what is the recommendation? (go or no-go).

Questions 1 to 4 will help to understand the opportunity.

Questions 5 and 6 are very interesting because it is not enough to understand the opportunity and find it a good one. It is necessary to be sure that this is the right moment and that we have the required expertise to pursue it.

From 7 to 9, there are the “what if” questions, that is, considering that the decision is to pursue this opportunity, how is it going to be presented to the market, how the success will be measured and what are the critical factors for success.

Answering these questions is good not only to decide if itÃs worth to develop a given product, but it also help the partnership opportunities, opportunities to develop new features, and opportunity to attend a special client that needs changes in the product. Ultimately, every opportunity will require your or your teamÃs effort and should be analyzed to see if the revenue pays the required investment.

How many opportunities to pursue at the same time?

Another important advice is not pursuing many opportunities at the same time; otherwise, you and your team will lose focus and end up not getting any return from any of the pursued opportunities.

In an ideal world, the recommended is to pursue one opportunity at a time. However, knowing that this is utopic, we will end up pursuing more than one opportunity simultaneously. Try to limit this amount to a few units (2, 3 or 4, maximum), reminding that, at any time, you and your team can only concentrate in one thing at a time.

In other words, if you are working on more than one opportunity simultaneously, every time you want to work in one of them you’ll not be working in the other ones momentarily. Therefore, stick yourself to pursue a few opportunities, preferably one at a time.

Validating opportunities

After analyzing opportunities, the next step is to validate them, that is, see if there are people interested in this product of yours that will solve the problem you researched. There are some ways of doing that. The first one is going back to the street and talk to possible clients. This will be an exploratory conversation in which you expose the problem to people who probably deal with it. Later, you tell about the solution that will be developed, and evaluate the reaction. Whereas, the problem of telling about a solution is that, as better as the description is, it is still not a finished product, and forces the person to imagine something that can be quite different from what you are conceiving.

In 2011, I decided to perform a little more realistic validation. At that time, I’ve conducted a startup experiment, did my initial research and ended up with 3 product ideas to develop. Having a hard time choosing in which of the 3 ideas to invest my money, energy and time, I decided to run a simple test. I chose a name and a domain for each one of the ideas and registered them. Later, I created a webpage for each of the ideas of web product I’ve had. As I’m not a designer, nor have any skills to build beautiful pages, I used a site called unbounce, that enables us to create simple pages and even A/B tests in a very easy way. Using Unbounce, I created the following page:

Note that this page only has 3 points that describe the product: one to talk about the problem; another one to talk about the solution; and a third one to inform the price.

The email form was useful to gather the amount of people interested. I’ve made a Google Adwords campaign of $ 10.00 per day per product that I wanted to text, during a month.

Below is a partial result for this validation:

This image is a screen of Unbounce. After 30 days of tests, I ended up with 216 email addresses interested on ContaCal – the product I’ve launched that is running until today – and 1,043 pageviews, giving me 20.7% in conversion rate.

The other two ideas also kept the same trend of this partial result. But I preferred to let them unreadable in order to not influence anyone to bet in any of them without further validation.

For those who don’t know, ContaCal is a nutrition journal in which users record what they ate and the system informs the total amount of calories, with a twist. Aside the total amount of calories, it also informs the quality of calories through a color system. The colors indicate how healthy that food is. If the calories are red, it is best to avoid. Yellow calories can be ingested moderately. And the green calories have no restriction.

The total cost of this test was R$ 990.00:

AdWords campaign: R$ 900.00.
Domains: R$ 90.00.
Unbounce site: free for 30 days; after this period, R$ 85.00 per month for up to 5 different domains that I would want to test at the same time.

Each new idea costs R$ 30.00 by domain .br, and another R$ 300.00 per month with a Google Adwords campaign if we make an investment of R$ 10.00 per day.

A very important point to notice is that ContaCal was not necessarily the best of the 3 opportunities, but the one that I was able to communicate best. Therefore, this validation is interesting, for it helps not only to test the idea of a product but also our capacity to communicate it properly.

Product Management: how to increase the success of your software

In 2015 I wrote a book on Software Product Management in Portuguese. In 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.

The book is organized in 5 sections:

Definitions and requirements
Life cycle of a software product
Relationship with other areas
Product portfolio management
Where to use software product management

This book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedbacks are not only welcome, but needed!

Innovation: the job to be done

Posted on 05/23/2017 by Joca

Professor Clayton Christensen teaches at Harvard and wrote several books – amongst them The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail (Management of Innovation and Change), a must-read for all those who work in technology – and he developed a technique to find out problems to be solved, called “the job to be done”.

The idea behind “the job to be done” is that we must understand for which job our clients have “hired” our products. In other words, the job our clients expect that our products will perform.

Clayton illustrates this technique with a very interesting example. He was hired to evaluate a specific product of a diner, the milkshake. The company already had surveyed clients asking what they wanted: creamier milkshakes, with cookies crumble, fruit or chocolate, or with more syrup. The answer of the research pointed out to a preference, which was implemented. However, this preference didn’t increase sales, the main goal of the company.

Clayton decided to do the survey differently. Instead of asking what clients wanted, he looked for understanding what was the work for which people “hired” the product, in this case, the milkshake. After many conversations with clients, he discovered that they passed by at the diner before going to work and spent a lot of time in traffic. The milkshake was creamy and you could drink it using a straw, so it would take time to finish it. It would take the whole time of the trip to work, that is, it would entertain the client during the whole trip to work. People hired the morning milkshake before driving to work to have something to get entertained on the way.

Clients have already tried with other “competitors”, such as fruit juices, but they end up very fast. They tried with bagels, but the work and the mess to eat it didn’t pay back. The milkshake was perfect for this job to be done!

After understanding the job to be done, the diner could improve the milkshake, making it creamier and putting little fruit pieces and/or cereal in it, in order to add small surprises while clients savor it. In addition, it set an attendance system that minimized lines to guarantee a minimum waiting time, after understanding that its clients were in a hurry and didn’t want to wait in the diner. These adjustments did bring sales improvements.

The “job to be done” market research

Clayton himself argues that, in traditional marketing, it is common to associate a certain product to a certain demographic group. For example, in the previous case, if we were responsible for the product management of the diner, we could relate milkshakes to people of a certain age who work and, consequently, always look for creamy milkshakes that last long. It happens that, using the technique “job to be done”, we have a wider view of where the product stands.

Clayton extended his survey to other periods of the day and caught the same people going back to the diner later in the afternoon, but now with their kids, for a quick meal. Often, the kids asked for a milkshake. The diner served the same milkshake: creamy, large and that lasted long. But parents didn’t want to wait that long for kids to finish their milkshakes; it was only a quick meal.

In this case, in spite of being the same client, the job to be done was another: to please the client’s kid quickly. Therefore, the milkshake could be smaller, maybe half of the size, and less creamy so it wouldn’t last long.

So the same client wants the same product performing different jobs, depending on the situation. That’s the importance of understanding the job to be done.

Understanding problems and their context

On the my previous article and on this one, we learned how to understand more about a problem of a group of people; to deeply understand their problems and the context in which they take place; and to understand the motivation people have to want it solved.

Eventually, by using the technique of “job to be done”, the suspicion appears: do we have a good opportunity in our hands? Or still, we can find more than one problem. So, how do we choose amongst all these problems? What is the best opportunity to be explored? This will be the topic of my next article.

Product Management: how to increase the success of your software

The book is organized in 5 sections:

Definitions and requirements
Life cycle of a software product
Relationship with other areas
Product portfolio management
Where to use software product management