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

Be the first to like.

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

Be the first to like.

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!

Be the first to like.

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!

Be the first to like.

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!

Be the first to like.

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!

Be the first to like.

UX e gestão de produtos

Parece que estou bem ruim de pagar dívidas… No último post da série sobre diversificação de portfólio de produtos prometi dois posts, um sobre a relação de engenharia de produtos e gestão de produtos e outro sobre a relação de UX e gestão de produtos. Chegou a hora de pagar segunda parte da dívida!

Mas antes de pagar essa dívida, vou fazer mais uma promessa, a de não fazer mais promessas de posts, porque, pelo visto, quando eu prometo um post eu acabo ficando muito tempo sem escrever… :-/

O que é UX?

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

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 tb 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 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: sistema, do usuário e do 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 imagem abaixo ilustra bem o papel de UX, bem como o de engenharia de produtos e o de gestão de produtos, no processo de desenvolvimento de produtos.

desejavel-viavel-possivel

Na fase de concepção do produto, UX tem um papel central. Baseado em muita pesquisa para entender a fundo os problemas e necessidades do cliente, 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. E tb nas conversas com o time de engenharia de produto, 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 (“Vc vai ver uma tela com login e senha e um botão de entrar. Tb verá um link caso vc 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:

paper-prototype-1

paper-prototype-2

paper-prototype-3

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 feita só em preto e branco, só com os contornos dos elementos. Essa versão é muitas vezes chamada de wireframe:

wireframe-1

wireframe-2

O próximo passo é UX preparar um protótipo / wireframe navegável, ou seja, um protótipo que já tenha o comportamento de interação para que vcs possam mostrar para clientes e usuários que eles possam testar e interagir. Em seguida, o designer visual de UX começa a colocar cor e forma nessa 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 convida-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 interagindo com o produto. O usuário é incentivado a verbalizar suas ações, opiniões e sensações, dessa forma, conhecemos 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 que ela não é escrita em pedra. Por esse motivo, o time de UX não entrega o protótipo para vc 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 produto e com o time de engenharia enquanto o produto estiver sendo desenvolvido para ajustar o protótipo se necessário, descobrir melhorias e aproximar o time de engenharia das necessidades do usuário.

Outro ponto em que o pessoal de UX participa ativamente é na definição e acompanhamento das métricas. Como eu disse antes, 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 produto e com o time de engenharia para definir qual(is) métrica(s) acompanhar para medir se a motivação foi atingida.

Ah, e tem mais um ponto!

Assim como os engenheiros de produto, alguns designer de UX acabam se tornando ótimos gestores de produto. É importante ser capaz de perceber quando um designer está procurando “outra coisa pra fazer” e dar a ele essa opção de carreira. Na Locaweb temos e tivemos ótimos gestores de produto que eram designer de UX. Em alguns casos acabaram se tornando gestor de produto do próprio produto dos quais eram responsáveis por UX. Por outro lado, existem alguns designer de UX que experimentam a gestão de produtos e não gostam. É preciso deixar a porta aberta para ele poder voltar a ser designer de UX, sem nenhum prejuízo para a sua carreira.

Be the first to like.

O trabalho a ser feito

Já discuti um pouco sobre o que vou tratar aqui no artigo intitulado Claro que o cliente sabe o que quer! onde descrevi que para criar um bom produto devemos:

  • perceber que existem pessoas com um problema para ser resolvido
  • entender muito bem qual é esse problema
  • entender o que motiva as pessoas a querer que esse problema seja resolvido

Uma maneira de se fazer isso é com uma técnica conhecida como “o trabalho a ser feito”, termo e técnica criados pelo professor Clayton Christensen, professor de Harvard e autor de vários livros, dentre eles The Innovator’s Dilemma, livro obrigatório para todas as pessoas que trabalham com tecnologia.

clayton

A ideia por trás do “trabalho a ser feito” é que precisamos entender para qual trabalho nossos clientes contrataram nossos produtos, ou seja, qual o trabalho que nossos clientes esperam que nossos produtos façam.

Clayton ilustra essa técnica com um exemplo muito interessante. Ele havia sido contratado para avaliar um produto específico de uma lanchonete, o milkshake. A empresa já tinha feito pesquisas com os clientes perguntando o que eles queriam, se milkshakes mais densos, ou com pedaços de biscoito, de fruta ou de chocolate, ou com mais calda. A resposta da pesquisa apontou para um preferência, que foi implementada. Contudo, essa preferência em nada mudou as vendas, que era o objetivo principal da empresa.

Clayton decidiu fazer então a pesquisa de forma diferente, ao invés de perguntar o que os clientes queriam, procurou entender qual era o trabalho para o qual as pessoas contratavam o milkshake. Após várias conversas com clientes descobriu que os clientes passavam na lanchonete antes de ir para o trabalho de carro e que ficavam bastante tempo no trânsito. O milkshake, por ser grosso e ser tomado de canudo, demorava para acabar. Demorava o tempo todo da viagem, ou seja, entretia o cliente durante toda a viagem até chegar ao trabalho. As pessoas contratavam o milkshake de manhã antes de ir para o trabalho de carro para ter com que se entreter no caminho. Elas já haviam tentado com outros “concorrentes” como bananas, mas acabava muito rápido. Tentaram também com bagels, mas o trabalho e a sujeira para passar manteiga não compensava. O milkshake era perfeito para esse trabalho a ser feito!

Entendendo o trabalho a ser feito, a lanchonete pode melhorar o milkshake, deixando-os mais densos e colocando pequenos pedaços de fruta e / ou cereais para adicionar pequenas surpresas enquanto seus clientes degustavam os milkshakes. Além disso, preparou um sistema de atendimento que minimizou as filas para garantir um tempo mínimo de espera por entender que seus clientes estavam com pressa e não queriam ficar esperando na lanchonete. Esses ajustes sim trouxeram melhorias nas vendas.

O alcance da técnica do “trabalho a ser feito”

O próprio Clayton comenta que no marketing mais tradicional é comum associar um determinado produto a um determinado conjunto demográfico. Por exemplo, no caso acima, se fôssemos responsáveis pela gestão de produtos da lanchonete poderíamos associar milkshakes com pessoas de certa idade que trabalham e que, consequentemente, sempre procuram milkshake densos que demorem para acabar. Acontece que, usando a técnica do “trabalho a ser feito” temos uma visão mais ampla do contexto onde o produto está inserido.

Clayton estendeu sua pesquisa para outros períodos do dia e pegou as mesmas pessoas voltando à lanchonete no fim da tarde, só que agora com seus filhos, para um lanche rápido. Com certa frequência os filhos pediam aos pais por um milkshake. A lanchonete servia o mesmo milkshake. Denso, grande, que demorava para acabar. Só que os pais não queriam esperar muito tempo para que os filhos terminassem seus milkshakes. Era pra ser um lanche rápido…

Aqui, apesar de o cliente ser o mesmo, o trabalho a ser feito é outro, agradar o filho do cliente de forma rápida. Sendo assim, o milkshake poderia ser menor, talvez metade do tamanho, e menos denso, para acabar mais rápido.

Ou seja, mesmo cliente quer que o mesmo produto faça trabalhos diferentes, a depender da situação. Daí a importância de entender o trabalho a ser feito.

Be the first to like.

Why the hurry to launch an MVP?

I mentioned earlier that I was starting:

a new project called “The startup guide: how to create and manage profitable web products”. It’s a blog that will eventually become a book where I’ll explain how to create and manage a web product with a profit.

Well, I finished writing the book which is called “The Startup Guide: how startups and established companies can create and manage profitable web products“. The book is focused on how any type of company – no matter if it’s a startup or an established company – can create and profitably manage a web software. All it’s content is available at the “Guia da Startup” blog. It’s currently in Portuguese so it’s a good opportunity for you to practice reading in a new language. If you are not up-to-date with your Portuguese skills, there’s the option of using Google Translate but some meaning may be lost in translation. For these reason I intend to translate the content into English eventually.

One of the most popular posts from this blog is about the reasons to make fast the first version of your product. Why do we need to make an MVP? Why not wait to have the product with more features to launch it? Herb Kelleher, co-founder and former CEO of Southwest Airlines has a famous phrase to motivate people to do things:

“We have a ‘strategic plan.’ It’s called doing things.”

This “strategic plan” can be translated into the #jfdi hashtag which means something in the lines of “just focus and do it” or “just freakin’ do it” (polite form).

But why the hurry? Why can’t we keep working on our product until we feel comfortable it has all the features we believe are needed to solve the user’s problem?

Well, there are 3 main reasons:

Reason #1: The moment of truth!

The longer you take to put your product in front of real users, the longer you take to start getting feedback from real people to know if you’re on the right track. And what’s even worse, you’ll probably be giving too many steps in the wrong direction.

A software is supposed to solve a certain problem of its users. You will not know if you have built a good product until the product is used by real users and it actually solves one of their problems. The longer it takes for this to happen, the longer it will take for you to know if your product is or is not the solution for someone’s problem.

And if it is not, what should you do? Change, adapt and present it again to real users! The sooner you know that what you’re developing is not on track, the better, because you’ll have spent less time, energy and money moving into the wrong direction.

Reason #2: Featuritis

There’s a limit to the number of features an user can understand. When we present a software full of features to a potential user, instead of providing her with a possible solution to one of her problems, we may end up creating a new problem for her. Kathy Sierra, a well known software development and user experience instructor, designed the Featuritis Curve that illustrates in a clear and fun way how user satisfaction diminishes as we increase the number of features of a product.

Reason #3: ROI

The longer you take to put your product in front of real users, the longer it will take for you get some revenue and the longer you’ll have to invest from your own money or investor’s money. Below is a typical return on investment chart. While you don’t launch your product and don’t have revenue, all you’ll have are costs, i.e., you’ll be in the investment phase of the curve below. This situation will only change when you get some revenue and this revenue pays your monthly costs. This is the monthly profitability phase in the chart. Only after a few months in the monthly profitability phase you’ll be able to get to the return on investment phase. It’s a long way:

Now take a look at the chart below. If you decide to delay your launch in 3 months, this can delay your return on investment in 6 months! Are the features that you intend to implement in those 3 months you are delaying the product launch worth the 6 months delay to get to the return on investment phase?

On the other hand, if you are able to launch 3 months sooner than what’s described in the first chart, you’ll get into the return on investment phase 6 months sooner. Isn’t that worth figuring out how to launch your product faster?

If you’re not embarrassed…

There is a famous quote by Reid Hoffman, founder of LinkedIn, which really resonates with the MVP concept:

“If you are not embarrassed by the first version of your product, you’ve launched too late.”

To illustrate this quote, here are some print screens of early versions of well known software products:


Google in 1998


Twitter in 2006


Linkedin in 2005


Facebook login screen in 2005


Facebook in 2005

Next post

Last year I decided to run a lean startup experiment. Would it be possible to build a software and market it without using Locaweb’s marketing power? The result of this experiment is a calorie counter web product with more than 17,000 registered users in less than one year of operation. In my next post I’ll explain how I built the first version of this product in 10 days.

14 people like this post.