Good users — bad users: from use cases to misuse cases

Every product team has its own frameworks to build great products. Some are more customer focused and some are more business focused. Smaller and larger teams use classic frameworks and some develop their own methods based on their customer needs, problems and resources.

In addition to having a structured framework, product work generally should be fast and iterative — Lean and Agile. We test our hypothesis and learn from the actions and patterns of our users. However, our frameworks usually stay the same they are not agile or lean.

The new reality of the digital age created an accelerated pace of innovation and growth in digital and mobile consumption. It changed how and when people use products and most importantly, it added a range of actors that contribute in both positive and negative ways to the platform. This new reality must make us think of our product development framework in an agile manner and reconsider them constantly according to the facts, industry trends and impact.

Product development frameworks

When I am building products I use a framework which takes me in a journey from the user through his pain points and problems. It took me some time and work to reach out to this frame work and fine tune it. And I’m sure it is going to change in the future as industry, technology and our users change.

Going through user definition, building personnas, clarifying my problem statement, I am usually thinking in a positive light on the product and its features. I ask questions such as “what are the problems the product can solve?”, “How often people would use the product?”, and “what would be a success after we launch a feature?”. As entrepreurs and builders we have a vision that the things that we do can positively impact the lives of others and make it better.

As I’m doing with entrepreneurs and startups I mentor I like to show them my thinking flow:

It’s important to understand that this process is not linear and the team can iterate and go back to any step in the process. I’ll go through each step and briefly describe what we would like to achieve:

Clarify — Any product development should first be challenged by questions by the team of things that are not clear. In this stage I usually ask “why did we chose to build this product?”, “Why should we invest in this product and not another one?” “ What does the market look like? are there any trends or competitors?

Understand — This stage is where is lay and map all the products and solutions that we already have to avoid any duplications. This is where I usually talk to other teams and consult if anyone has worked on this problem or what are the current solutions the company has.

Users — We dive deep into the question of who are our users? are they individual consumers, businesses, both? Do we have direct users and indirect users? It is critical that you come up with a focused statement on who are your users — avoid very broad definitions and users groups like “people at the age of 16–45 who use the internet”!

Use Cases — After we have a clear idea of who are the users of our product and who are we solving the problem for, we start the journey of stepping into their shoes. We start coming up with stories of potential users and go through different scenarios to detect potential problems our product would solve for them. I usually define personnas, fictional profile of a user, and tell his or her story. However, feel free to have your own approach.

Problems — Going through the use cases you and your team brought up, together we try to crystalize and track the main pain points of your users. I usually write down on a whiteboard the stories and then go line by line and underline where I find the problems. I then list all problems that we found in this process. The team’s goal is to find that critical problem that if we find and solve we will change our users’ lives.

Prioritize — This stage helps you get a clear sense of what is the problem your team should build the product for. You should understand what is a critical problem and what is a problem that could be left to deal with in later stages. I usually ask two big questions for each problem we found:

1. Is it a real problem? That means if this is a problem that the user experiences or is it something that we think is a problem but it’s actually biased by our industry or personal experiences.
2. Is it a problem at scale? often we might become biased about problems that either happen to us or that we think are more pervasive than they really are. To avoid this bias, first we should think of and interview users that are not within our network or of similar character to us but to take a broad range of user profiles. Second, we should always use our research teams and data to understand the scale of this problem? Will we solve this problem for 500 users or 2 billion people?

but how do you make the actually problem prioritization? I have encountered many methodologies and parameters which are applied by different teams in different companies and industries. Being a visual person, I like to draw a four quadrant space. The horizontal axis defines how real is this problem, and the vertical axis describes how scalable this problem would be. Of course that you could flip the two and get the same insights.

If a problem is position in the upper right quadrant, it is a problem worth solving — it is a real problem and at scale. However, if the problem in the bottom left quadrant you should leave this problem even though you think it is a cool problem to solve.

If you end up with more than a single problem in the upper right quadrant do this exercise again and iterate this process until you come up with one main and juicy problem you and you team are excited to build for.

Goals — This stage is extremely critical for you as a product leader. It is so easy to get lost in the amazing goals you can define for and with your team. However all you need is one — one goal that will be your team’s north star. If you reach this goal you should have solved the problem you defined for your user. If you reached that goal your product would be a success and people would love it and use it.

Ideate — This is where you let your teams creativity thrive. I love doing this stage in small groups thinking of solutions together and have loud conversations, debates and more than anything fun by thinking of solutions. It is important to aim for quantity in this stage and not to limit people’s imagination. When I’m running a team brainstorming, I urge the team to draw and build rapid prototypes. I combine design thinking into this process and inspired by Stanford’s d.school and the work done at IDEO. You can learn more about design thinking in this link.

When you ideate embrace the Chaotic feeling creation

Tradeoffs — After you and your team let those brain wheels spinning and you have several product ideas on the whiteboard, it’s time to focus and organize your thoughts. In this stage you should understand what are the tradeoffs of building each product idea and make a decision of which one you would build. There are many ways to weigh tradeoffs which are more mathematical and I’ll add more details in future articles.

Success — in this stage I ask one question: “if everything works as we hoped for, what would success looks and feels like?” you need to link this question directly to your problem statement and the north star goal that you defined earlier with your team. If you reached that goal what is the impact?

Metrics — This topic could be and is covered by infinite number of articles and you can find industry leaders such as Facebook, Google, Greylock and Sequoia Capital writing about what metrics you should track and define. In this stage you need to remember that if you cannot measure it — show a number, it doesn’t really matter. If you can show you hit a the right metric you increase your chances of reaching product-market-fit, gain engagement and retention and even raise capital.

The new reality of misuse of digital platforms

As we see more and more digital platforms and companies grow, the number of players in each is growing as well. Most people are using these platforms for good. For example, most people use Facebook to connect with the people they love and maybe connect to the latest news and most people are using Google to search things that interest them online. However, as the number of active users is growing it makes sense that malignant player will enter the game and try to abuse the platform.

In product development I always like to think of the offline world in addition to the online world. Think of real cases in our non-virtual lives that we encounter problems. Doing so, I like to use the analogy that a platform is like a country. A country has some a land, resources, government and rules . Citizens should play according to the rules and obey the law or else they would be penalised. A digital platform is like a country in the online world. It has a virtual space, resources, the company management and platform regulations. Users are expected to use the platform according to the rules. If they are not playing by the platform rules they are penalised or banned from the service.

The big difference is that tech companies are a young creators unlike countries. In addition, they are an optimistic creature usually developed by a very visionary entrepreneurs who sees all the good its platform can create. The latest stories about Cambridge Analitica, and other privacy issues led companies like Facebook to take responsibility and start thinking on the other cases of using their products — the misuse cases. These are the worst scenarios people who abuse the platform and want to harm other users.

The new approach and view on product development should include 2 things: prevention of misuse cases and enforcement of the platform rules. For both we need to change or broaden the state of mind of builders, entrepreneurs and product teams from thinking of their users as the good players and consider the other type of users — the bad ones. There are some big questions for tech companies such as do every company now need the parallel of a police in the offline world? Do startup need to hire Chief Policy Officer early on in their lifecycle? These are tough questions and I will address those in future articles. However, I chose to focus on how we could prevent the occurrence of misuse cases by adding another layer to the product development framework.

The New Product Framework

Going back to the product development framework I presented previously, the new reality made me add another layer and think a bit differently about the use cases I am considering.

After thinking about my users I divide the discussion of use cases into two types of scenarios: Use Cases and Misuse-cases.

Use Cases: Use cases are the examples of users of our products that use the product as we wanted. We are thinking of real problem who has problem and think how we can build a product that could help them improve their lives and solve their problems. These are the same user cases from the original framework I presented.

Misuse Cases: These are the new cases we should surface and be fully aware of. The users are not the ones we would expect to use our platform, but people who abuse it either intentionally or unintentionally. Examples for these are people who promote hate speech, violent content or financial harm to the platform or its ‘good’ users. These could also be people who unintentionally use the platform in a way that harm others. A great example is users on Facebook or Twitter that share false facts and help the really bad actors to promote it.

Who Really Are Your Users?

But the source and origin to all the problems every tech company is solving, every product and every use case is your users. Most successful companies obsess about their users and their problems. Before you start thinking of either the use cases or the misuse cases, you have to define your users. Therefore you need to consider your entire users base.

Usually your user base will be composed of entirely good players (the blue portion) and a tiny portion of bad players (orange portion) especially in the early days of the product. As a company grows and scales the orange portion starts growing. In order to keep the percentage of bad players low in advance, you have to think of this group as your users. You need to add them to your thinking and product development process.

Most importantly, it is not necessarily that the percentage of bad player to good players is what will matter, it is the impact that this group has on the health of you product. It is critical that your product design process and business model will take into consideration those bad actors and the misuse cases they will be involved in, in order to design mechanisms that will demotivate them to harm and reduce the health of the product. It is often that as the impact of this bad group of players will be significant and will impact very quickly and in your product development process you need to prevent your product to reach this breaking point where their bad impact will cross the good impact of your large user base.

What’s next?

The new reality would definitely change the way we build products and companies, however should we redesign the whole product development process? are we actually building our products for good players and bad players in parallel? Should we have product managers that are building the experience for or more accurately against those bad players? I would love to get your opinions and thought.

If you read it and you know it clap your hands :)

Feel free to connect with me on Linkedin: https://il.linkedin.com/in/illaigescheit

• This post has been published on www.productschool.com communities.