Another example of an MVD – Minimum Viable Discovery

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

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:

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)

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:

The 2 sides of Product Discovery

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 and 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:

Discovery and delivery flow

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

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:

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

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 e 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:

Fluxo de discovery e delivery

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

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:

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

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.

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 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 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.

No alt text provided for this image

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:

No alt text provided for this image

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.

No alt text provided for this image
No alt text provided for this image

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.

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:

No alt text provided for this image
No alt text provided for this image
No alt text provided for this image

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:

No alt text provided for this image
No alt text provided for this image
No alt text provided for this image
No alt text provided for this image

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:

No alt text provided for this image
No alt text provided for this image

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 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.

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 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.

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.

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.

No alt text provided for this image

Innovation: Next steps

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

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.

No alt text provided for this image

Innovation: a lot of opportunities

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:

  1. Which problem will it solve? (value proposition);
  2. To whom this problem will be solved? (target market);
  3. What is the size of this opportunity? (market size);
  4. What are the alternatives? (competition scenario);
  5. Why are we better qualified to pursue this opportunity? (our uniqueness);
  6. Why now? (window of opportunity);
  7. How are we going to take this opportunity to the market? (launching strategy);
  8. How are we going to measure success and make money with this product? (metrics and revenue);
  9. What are the critical factors for success? (essential requirements);
  10. 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

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

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: Focus on the problem

In my last article, I discussed about innovation, the first phase of the lifecycle of a software product.

The first step to create a new software product is to understand the problem. It is very tempting, as you begin to understand the problem, go on and seek for solutions. The human nature is to solve problems. 

Every software developer has some story to tell about demands that goes like this: “So, I need a system that does this and that, I need to have a field so I can type this information and it should give me a report that shows this.” Then, when the system is delivered, the person says “Well, this helps me, but now I also need a field to insert this other data and I need the system to export a csv file with this and that info.” In other words, demands come in the shape of solutions and don’t even mention the problem to be solved. 

Next I’ll share some techniques to focus on the problem.

Interview

It is a good way to understand customers, the problems they have, the context in which these problems happen, and what motivates them to seek for a solution. However, it is necessary to be careful, because the respondent will try to hand out the solution of what is thought to be the problem. You must be careful not to belittle the suggestion, but should always keep the conversation focused on the problem. 

The interview in which you talk directly to your customer is considered a qualitative method, that is, you ask a few questions but get the opportunity to deepen the answers. 

Next, there is a set of questions that will help to keep the conversation focused on the problem:

  • Tell me more about your problem.
  • What is the greatest difficulty you have regarding this problem?
  • What motivates you to wanting this problem solved?
  • Where does this problem usually happen?
  • When it happened for the last time? What happened?
  • Why was it difficult/complicated/bad?
  • Did you manage to find a solution? Which one(s)?
  • What didn’t you like about the solutions you found?

For instance, let’s go back to the subject of Henry Ford’s car. Now imagine a dialogue between Henry Ford and a hypothetical Mr. Smith, a possible buyer for Ford’s product at that time:

> Ford: Mr. Smith, what distresses you the most?

> Smith: Mr. Ford, the most distressful thing for me is that I donít spend too much time with my family.

> Ford: And why is that?

> Smith: Because I spend too much time in the cart going from one place to another. If I could put one more horse to pull my cart it would go faster and I could spend more time with my family. 

> Ford: Oh, I see your problem, and I have a even better solution for you. It’s called car.

Do you think that Henry Ford got the problem? Or he understood the solution Mr. Smith presented to him, and developed a solution based on Mr. Smith’s solution? Do you think the real problem of Mr. Smith was that he didn’t spend too much time with his family?

Let’s try using the same questions showed previously to see if we can get the problem:

> Ford: Mr. Smith, what distresses you the most?

> Smith: Mr. Ford, the most distressful thing for me is that I don’t spend too much time with my family.

> Ford: And what is the greatest difficulty you have regarding this problem?

> Smith: I spend too much time at work, going from one place to another, without talking to people. 

> Ford: What motivates you to wanting this problem solved?

> Smith: I have small children and, because of work, I spent too much time out of home. When I get home, my kids are already asleep. 

> Ford: Where this problem usually happens?

> Smith: At work.

> Ford: When did it happen for the last time? What happened?

> Smith: Practically everyday. It happened yesterday. I think I manage to get home in time to see my kids woke up once a week…

> Ford: Why was it difficult/complicated/bad?

> Smith: Because it took me away from the kids.

> Ford: Did you manage to find a solution? Which one(s)?

> Smith: I got off from work earlier.

> Ford: What didn’t you like about the solutions you found?

> Smith: The work piled up on the other days.

Note that this conversation can generate a solution such as the invention of the car to help Mr. Smith to get home faster. However, it could be also the motivation for creating a more efficient work process, or a machine that would do the work for Mr. Smith.

You might have a solution in mind. But consider having a real interview, focusing on the questions for really understanding the client’s problem.

Survey

Another way of obtaining information from clients is through surveys. This method is considered quantitative because it seeks to survey a considerable amount of people in order to get what is known to be statistical relevant. This is, for being confident that the results weren’t obtained by chance. 

For example, in case you ask in a survey if a person has iPhone or Android, and only get two people to answer, that is, only two answers – being both iPhone, both Android or one iPhone and the other Android – it is very difficult to reach a conclusion. But, if you have many more answers, you have bigger chances to picture the real world in your survey. 

There are great tools for online surveys, such as Google Form and Survey Monkey. There is also a Brazilian tool called OpinionBox that, besides building your questionnaire and collect the answers, allows that you to select people for responding it based on the profile criteria you specify

Surveys don’t have to be necessarily taken online. You can also perform them by phone or live. There are companies that can help you to collect the answers. 

Deciding to do a survey is easy, but building the questionnaire is hard. The first step is having your survey goal very clear. Then, create your questions with these two main rules in mind:

1. Be brief. The shorter your survey, the bigger are the chances of getting a good number of answers and guaranteeing a highest statistical relevance. 

2. Be clear. Especially in online surveys, when you are not interacting with the respondent, there are big chances of the person misinterpreting your question. One good way of testing your questionnaire live with some people. Check if they understood each question, or if they had some difficulties in comprehending some part of it. 

Check some examples of bad questions that could bring up some misguided interpretations or mix up the quality of the answers, and suggestions of how these questions can be improved:

> Original question: How short was Napoleon?

> Improved version: What was Napoleon’s height?

> Original question: Should concerned parents use compulsory child seats in the car?

> Improved version: Do you think the use of especial child seats in the car should be compulsory?

> Original question: Where do you like to drink beer?

> Improved version: Break into two questions: Do you like drinking beer? If yes, where?

> Original question: In your current job, what is your satisfaction level regarding salary and benefits?

> Improved version: Break into two question: What is your satisfaction level with your salary in your current job? What is your satisfaction level with your benefits in your current job? 

> Original question: Do you always have breakfast? Possible answers: Yes / No.

> Improved version: How many days a week do you have breakfast? Possible answers: Everyday / 5-6 days / 3-4 days / 1-2 days / I donít take breakfast.

Observation

Another very useful technique to understand the problem is to observe. Seeing the client facing the problem or having a need, in the context that it occurs can be inspiring!

Observation is a qualitative way of understanding a problem. In order to make a good observation, be prepared; that is, hold in your hands a set of hypotheses. In each round of observation, re-evaluate your hypotheses and adjust them, if necessary. Usually, after 6 or 8 observations, you can already notice a pattern. 

Observation may or may not be interfered by the observer. For example, if you are observing consumption habits in a drugstore, you can watch people without them noticing you. But in a usability test, in which you invite people to test your software, people will know that you are observing them. The observations can be complemented with interviews, helping to improve the quality of the findings.

A very useful technique to find out problems in the use of software is to observe what the user does 10 minutes before and 10 minutes after using it. For example, if the user catches information in some other system to insert in the software. Maybe here there’s an opportunity for you to catch information from the other system automatically. And if, after using it, the user pastes information to a spreadsheet for building a graphic, eventually your software could spare the user from this work and automatically build this graphic. 

Observation usually is depicted as a qualitative method. But you can and should also use quantitative observation. For such, observe the user and some important metrics such as access and use statistics, engagement, NPS, revenue, new clients, churn etc. In other words, metrics are a way of observing your users’ behavior while they engage with your software. 

Final remarks

I put aside, on purpose, a technique called focus group, in which we gather a group of people (between 6 and 15 individuals) to discuss a certain problem. It is a technique considered qualitative as it enables to deepen in the questions that are being discussed. 

The reason I put it aside is that, in these discussion groups, there’s a strong social influencer element in which more assertive and extrovert people tend to dominate the discussion and end up polarizing the group’s opinion. In my point of view, individual interviews are generally much more relevant, unless in situations when the goal is to research exactly the influence and social interaction of the group. 

Another important point to consider during your discovery of the problem is who are the people holding this problem and which characteristics they have in common. Besides understanding very well the problem, it is important to know for whom we are intending to solve it and what are their motivations and aspirations. It is important to keep this in mind during the process of discovering the problem. 

You might be asking yourself “Why is so important to invest that much time and effort in understanding the problem?” The answer is simple: developing a software product is expensive. Investing in a good comprehension of the problem, of the people who hold the problem, of the context in which it occurs and the motivation people have to see it solved, is essential for not wasting time and money building the wrong solution. 

Lastly, as I mentioned before, the methods are not exclusionary, they can and must be used together, for they are complementary. An observation is complemented with an interview. The findings in observation and interviews can be confirmed (or confronted) with the results of a survey or the analysis of collected metrics. 

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: what is it?

Of all stages of the lifecycle of a software product, innovation is the one that uses to hold the greatest amount of questions. But what is innovation? How to find a problem to be solved? How to find out if this problem is, in fact, an opportunity to be looked for? And how to obtain return with your software product? 

These are the themes that I’ll approach in this and the following articles. 

Innovation is a very common term, but if you ask different people about it, each one will give you a different definition. Some will define it by focusing on creativity, that is, they will say that innovation is something creative, something that didn’t exist before, something different from what you usually find. 

There are many products, not only software products, that are very creative. There are stores specialized in these creative products. In United States, a very well-known store of creative products is Sharper Image.

Without a doubt, this portable air conditioner from Sharper Image is a very creative product.

Another company that sells creative products is SkyMall. The company distributes a catalogue full of different and creative products on local flights in United States. 

However, are these products really innovation? How many people do you know that really need a portable air conditioner? Does it solve a problem or need of a group of people?

Besides people that associate innovation to creativity, others understand innovation as being the latest technology. Quantic computer, wireless electricity transmission, genome editing, virtual reality, augmented reality, nanotechnology and the internet of things are some examples of the latest technologies. 

Whereas, once again, I’ve the same question: Are these really innovations? How many people need these technologies? Do they solve some problem or need of a group of people?  

Defining innovation: Innovating is not just simply being creative or knowing the latest technology. It is necessary to know the available technologies and how to use them to solve a problem or serve a need of a group of people, this has the potential of really producing innovation.

This definition makes clear that innovation – and we can consider creating a new software product as innovation – should start by discovering and understanding problems and needs of a group of people. 

But how can we do this? Do customers know what they want?

Of course customers know what they want!

Customers don’t know what they want.” Unfortunately, it’s common to hear such sentence in conversations about products and customers. At a certain point, someone will utter the famous quote from Henry Ford, the automobile inventor:

“If I had asked people what they wanted, they would have said faster horses.” –Henry Ford

Steve Jobs, Apple’s eternal CEO, enjoyed repeating this sentence to exhaustion.

Nevertheless, I disagree. Clients do know what they want. They want a solution for their problems. That’s where Henry Ford, Steve Jobs and us, mere mortals, come in, willing to develop products to solve these problems. 

The first steps to create a good product are:

  • To realize that there are people with a problem or need to be solved;
  • Understand very well what is this problem or need;
  • Understand what motivates people to want this problem or need solved.

When you talk to people with problems or needs, some will even say that this problem could be solved like this or that; however, in this initial moment, the priority is to find out if there really is a necessity to be solved. You must decouple the problem from the suggestion of solution your interlocutor is trying to give. 

People used to take a long time to move. This was the problem to be solved at Henry Ford’s time. No matter how. 

It could be more horses in front of the carts, it could be horses trained to walk on rollerblades, it could be using genetically modified horses that would ride faster, it could be the invention of the car, the invention of the airplane, even the invention of tele-transportation. 

The specific solution for the problem didn’t matter, as long as the problem was solved. Many people probably gave solutions, like the fastest horses from Henry Ford’s quote, but this is just a suggestion. The problem to be solved is that people took too long moving from one place to another. The problem was not that they wanted to move faster. That’s already part of the solution. 

In the following articles, we will approach some techniques that will help us to find out and understand the problems or needs.

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!