In this article, the author proposes that to build a successful product, it is necessary to always pay attention to "user needs", "business needs" and "technical needs" in product development. The translation is as follows:
How to avoid building products that fail
"if i ask people what they want, they say they want a bunch of horses that run faster." this sentence is said to be the famous quote of henry ford, the founder of ford motor. it is often cited to support so-called innovations that have not been tested by users. this statement is actually of little value, because ford may not have said it at all, and running a company in this way of thinking is likely to fail miserably in the market.
we should recognize that it is very dangerous to execute an idea that has not been validated and tested. we should not jump directly to the solution section until we understand a problem. and that's what this article is going to be about.
the starting point for developing a product is always the demand. we can't take it for granted that a product will be good, and only a product that truly meets the needs of users and pays off commercially can be successful. i think the process of developing a product should be more invested in the following parts, and we will discuss these 3 aspects in detail in this article:
user needs. we have to understand the market well, understand the company's consumers (both existing and potential), understand their behavior and attitudes. we shouldn't leave a dead end in our product target audience research.
business needs. the slogan "user first" often obscures the fact that products exist to make money. but the need for business can't be an excuse for poor design either.
technical requirements. people often place too much emphasis on more direct front-end and commercial needs and neglect technical needs. developers know the limitations of the product, they know what problems need to be solved, and they know what technical deficiencies need to be filled.
one of the biggest mistakes in product development is to start execution before you can complete a sound product plan. therefore, we need to pay enough attention to the planning process. first, let's talk about collecting user requirements.
user needs
let's first distinguish between two concepts: requirements and functionality. people often mistake product functionality with user needs. looking at some examples of the home appliance industry, you know why i said this: there may be many preset modes on the washing machine, but are there only one or two that you usually use? how many ways do you need to bake bread with a bread machine? these two examples show that the functionality of the product is not equivalent to the value created for the user, and more does not mean good. we don't need more modes to wash clothes, but we may need to wash faster or a quieter way to wash.
When the product design is too complicated, we have to find our own way to solve the problem. (Image courtesy of Reddit)
Shortly after Facebook Home came out, comments and usage statistics began to appear, and John Gruber said something that impressed me: "It's well designed, but no one wants this idea." His remarks are exaggerated, but they also illustrate the consequences of equating functionality (home page feeds, friends filling screens, Chat Heads features, app launchers... ) with demand (why people would want to swap their phone's operating system for an app). The difference between features and requirements is very important and sometimes difficult to spot, and user research should be done.
research that gathers user needs relies primarily on observation and analysis, not just a bunch of pre-set answers to questions. but before we can explore the various ways to optimize a product, we need to define some basic research content.
first, we need to distinguish between quantitative and qualitative studies. in quantitative studies, data is often not collected directly from respondents, but through questionnaires or web analytics. quantitative analysis can help you understand what happened, or to what extent it happened. qualitative profiling data is collected directly from participants, usually in the form of interviews or usability tests. qualitative analysis can help you understand how and why certain behaviors occur.
second, we also need to distinguish between market research and user research. both are very important, but they have different purposes. market research is to understand the overall demand in the market, mainly focusing on issues such as brand value and market positioning. attitude questionnaires and focus group interviews are basic methods commonly used by market researchers to figure out how to position products in the market. questionnaires and focus group interviews are very useful when understanding market trends and needs, but not very useful in product design.
user research, on the other hand, focuses on how users interact with your product, how people use new technologies, and what we can learn from what they lack, need, and feel frustrated about. in this section, we will focus primarily on user research methods.
so, based on the above definitions, let's look at some of the most commonly used user research methods. it is broadly divided into three categories:
1. Exploratory Research
exploratory research is very effective when our goal is to identify the most important (often unmet) needs of users to use a product. exploratory research includes situational interviews (also known as "ethnographic research methods" or "field visits"), participatory design sessions, and concept testing. the goal is to identify deficiencies in existing products that address user needs. ideas for new products or features often come from these meetings.
make no mistake, this approach isn't about asking people if they want "faster horses," but about looking at people and finding out what they need to do better than they do now.
For example, we've done on-site visits to many eBay sellers around the world. By walking into people's homes and observing how they manage sales, we discover a problem that is absolutely impossible to spot through web analytics or surveys. Every seller manages their store differently, with some plastering post-it notes around their monitors and others using Excel tables with complex formulas. Sellers had to do something themselves that should have been done by eBay: how to document the sales process and make an analysis to draw conclusions. Through field visits, we found some unmet user needs and solved them in a variety of ways. And demand is the starting point for all of this.
2. Design Research
Design research helps developers use the conclusions of requirements analysis to further improve product ideas. Specific methods include traditional usability testing, rapid iterative testing and evaluation (rapid iterative testing and evaluation), and even quantitative methods such as eye tracking. This kind of research plays a very obvious role in the process of designing products and solving user needs. For example, we can develop an interactive prototype first, then take people to a usability testing lab and give them some tasks to complete on the prototype, in this way we can discover some usability issues before we get into the costly development process. Through in-depth one-on-one interviews, we have many opportunities to learn more about whether we are well meeting the needs of the users found in exploratory research.
3. Assessment Research
evaluation studies help us verify whether changes made to the product are really improving the product or just doing useless work. this type of research is often overlooked, but it is a very important part of the product development process. we can use questionnaires and web analytics to see how our products are performing over time. here we need to pay attention not only to the changes in some hard indicators, but also to the changes in user attitudes. only by deeply combining evaluation and design research can we better understand why we see changes in our products. for example, a tabular analysis can show where people are giving up filling out a form. whenever we improve the usability of the table, we need to understand how these changes affect the completeness of the table. without evaluation studies, we have no way of knowing if a product is in the right direction.
In the Internet industry, we have seen many companies that fully meet the needs of users but cannot make money and cannot continue to develop. In the past few years, many excellent network services have shut down because of a lack of revenue. Editorially, for example, is a great collaborative writing and editing tool, but its founders found that "even if all users pay, it's not enough." ”
Before Editorially, everpix, a photo management service, was also shutting down. Part of the reason is that they can't afford to pay for cloud storage. Although there are a large number of paying users on the Everpix platform, they still can't make ends meet. The founders later admitted that while the company had developed products that people really loved, the team spent too much time on the products and didn't set aside enough time to focus on the company's development and product promotion.
now a lot of internet products want to get as many users as possible first, and then think about making money. but in my opinion, this is not the way of doing business. i'm not saying that a new product needs to be profitable from day one (which is better, of course), but at least you need to plan a business model that will bring stable revenue, and clarify the company's future revenue sources when making business plans.
so, how should companies generate revenue? most of the time, we need to rely on consumers. in the "user needs" section, we've discussed some research methods that can help you determine if users are willing to pay and how much they are willing to pay. in the process of developing products, it is necessary to unite the business development team, sales team, marketing team and engineering team within the company to do two aspects: abandon bad income and pursue high-quality income.
abandonment of non-performing income
An ancient Greek writer once said, "Gain is always sweet, even if it comes from deception." (Profit is sweet, even if it comes from deception) This phrase reveals how vulnerable we are to money. Making money through deception can sometimes seem tempting, but this short-sighted behavior can be hugely problematic in the long run and can burden you with heavy moral baggage.
In interface design, we call some deceptive techniques "Dark Patterns", that is, through the inducing interface, let users do things that would not normally be done. On darkpatterns.org this website, we can see such a case:
Some iOS apps for children, such as Talking Tom, will randomly pop up pages to induce children to purchase some in-app purchases.
When logging in to PayPal, you will often see full-screen ads, and there is only a small button in the upper right corner to close the ads and continue to operate on the account.
FarmVille, a farm game by Zynga, was developed with only one goal in mind, which was to force users to take care of their virtual land for as long as possible.
Ryanair puts the option to cancel their insurance purchases in an extraneous drop-down menu, so many people don't realize they're insured.
How to cancel the purchase of insurance on the Ryanair website. (Source: Dark Patterns)
It's clear that there is some income that is unethical and therefore not worth pursuing. The problem is that these methods often make money (at least in the short term). But its long-term effects can't be ignored, and once users figure out what's going on, they start complaining. These disgraceful tactics can directly affect the company's reputation, but also increase customer service costs. The conspiracy of insurance sales like Ryanair has become a classic negative of "dark mode."
of course, most people don't want to make money by cheating, but "dark mode" may subtly erode our normal ideas until they are completely changed.
for "dark mode", we don't need to spend too much effort to fight, just remind ourselves: be careful, don't fall into this trap. whenever you encounter an opportunity to increase your income, ask yourself, "if a product lets me do this or makes me pay for it, will i accept it?" "if the answer is no, then give up the idea, there will be a better way." while it's sometimes difficult to find the right monetization model, sacrificing short-term benefits in exchange for long-term loyalty from users is more valuable and you'll be more comfortable.
there is another situation, where an income line is benign at first, but gradually becomes a bad income as the external environment changes. if this income has become an important source of income for you, you need to be very careful.
One example of this is images in eBay search results. When eBay was founded in 1995, storage was very expensive. So it's reasonable to charge a user a fee when uploading an image in a product list. After 10 years, by 2005, storage had become so cheap that it seemed ridiculous to charge a fee to upload photos. But image uploading has become a considerable income for eBay, and it is a very difficult decision to give up this money and upload images for free.
Our user experience team and analytics team have found that showing images by default in search results not only increases sales, but also has a positive effect on rating the usefulness of search results. In the end, eBay decided to give up this bad income, upload the image for free (up to 8), and never change it back.
eye tracking data shows the importance of image presentation to search results
WHEN SOME BAD REVENUE IS INVOLVED IN THE PRODUCT DEVELOPMENT PROCESS, THE BEST THING TO DO IS TO CONDUCT RESEARCH, UNDERSTAND THE NEEDS AND MOTIVATIONS OF USERS, AND COMBINE A/B TESTING TO MEASURE THE IMPACT OF BAD INCOME ON QUALITY REVENUE.
pursue quality income
quality revenue can come from many different channels. for consumers, as long as the value of the product is obvious, they have the willingness to pay. therefore, in the whole process of product management, it is necessary to first clarify the value of the product, and then develop the product and carry out related business, can not first develop the product and then attach to its value, user demand research is always the first step in product profitability.
For some of the revenues that already exist, there are some standard ways to grow, such as expanding to new regions, establishing new channels, extending to a wider market, and developing new products for existing markets. In the book Adaptive Path by Brandon Schauer, a new concept of revenue growth is also proposed, called Long Wow. Long Wow is defined in the original book as follows:
Long Wow means gaining long-term loyalty by satisfying customers again and again. Long Wow isn't just a measure of loyalty, it's about cultivating and creating loyalty through a way that puts user experience at its core.
Long wow consists of the following four steps:
1. understand the platform to communicate with users. identify different ways to engage with users online and offline.
2. meet the unmet needs of users. on the basis of user needs research, identify which important user needs have not been met by your product or any existing product.
3. create and develop a repeatable process. combine the company's existing strengths with new ideas to continuously meet consumer needs and delight users.
4. plan for a stunning user experience. improve your idea over time. no new, better user experience is introduced throughout the product lifecycle.
then, repeat the process continuously depending on the situation. in this way, you can measure whether your product is generating quality revenue, and you can ensure that you continue to provide value to your users and cultivate more loyal customers who are willing to pay.
Before discussing technology needs, two concepts need to be clarified: "technology assets" and "technology liabilities". The so-called "technical assets" are the underlying technology on which the product depends and some of the systems used in the daily office (procurement, finance, logistics). Instead, "technical liabilities" refer to systems and code that limit product development (often in the form of bugs), and technical liabilities can cause more serious problems if not mitigated over the long term. Steve McConnell, principal software engineer at Construx, believes that technical liabilities can be divided into two main categories:
unintentional debt occurs when a bad design is implemented or when a programmer writes poor code. this debt is not deliberate, of course, the less the better.
intentional debt is when a company knows something isn't ideal, but compromises (usually due to budget or time constraints) for a variety of reasons. while this type of technical liability isn't a good thing either, it's inevitable for any organization, and all we need to do is minimize its impact.
for technical indebtedness, we need to minimize the negative impact as much as possible, otherwise we will encounter what we often call the "broken window effect".
the "broken window effect" is a term in criminal psychology. used to explain the disorderly and destructive behavior of the city, its meaning is:
urban management needs to keep facilities in good condition and monitored at all times, so as to prevent further destruction of public property and even escalation into more serious violent crimes.
we can compare software to the environment of the city. if a few windows are broken (some bad code appears in the software) and the broken windows are not fixed as soon as possible, there is a good chance that there will be more broken windows (people become less concerned about good code), and then the environment will deteriorate further: garbage is everywhere, and more and more people are taking over empty houses without permission (code standards generally decline). soon after, all the windows will shatter.
If the debt expands to a certain extent, the company will end up spending more energy on closing these loopholes than on creating new value. A common scenario is that legacy code bases often require a lot of effort to maintain (i.e., "pay off debts"), leaving less time to develop new features in the system. ——Steve McConnell
every effort needs to be made to avoid such technical liabilities when developing products. if you do, the process of finding time to deal with these arrears can be very difficult, often not seeing any changes, some people on the team who don't understand why they do this, and many people who are too lazy to clean up the garbage in the code. however, cleaning up these technical liabilities during the development process is a very important task, and if not done well, it is likely to destroy the entire system.
Of course, it's important to note that technical debt isn't always a bad thing, and sometimes technical debt gives rise to some powerful features. In general, new liabilities are fine, but old debts accumulated over time are not good. In his article Good and Bad Technical Debt, Henrik Kniberg proposed a good way to avoid technical debt loss of control, which is to introduce the concept of debt ceiling, and when your debt reaches a certain limit, you need to take steps to avoid further loss of control:
when the debt reaches the ceiling, we declare a "debt emergency", stop working on new projects, and everyone focuses on cleaning up the problems in the old code until we return to the baseline.
theoretically, you will encounter technical liabilities in every development cycle, but when the liabilities reach the upper limit, they need to be adjusted in time to avoid the situation getting worse.
weigh three aspects of demand
collecting user needs, business needs, and technical requirements is only part of the product development process, and more importantly, how to deal with this information and balance the three aspects of demand. at this time, we should mainly consider the following three elements:
the stage at which the product is in its life cycle. is this a brand new product, or has it been around for a while?
user acquisition. are you trying to attract users, or will users find their own door to use your product?
the company's financial position. are you trying to make money, or are you already earning a steady income?
the combination of these three elements is different, and your focus should be different. if it's a new product that's trying to acquire users, then you need to pay a lot of attention to user needs; if the company is looking for massive, benign growth, then you need to focus on profitability.
finally, it should be emphasized that if you do not understand the needs of the core users of the product and the needs of the business and technology, then your product is built on nothingness. a product may be in the ascendant for a while, but eventually there will definitely be new products. so don't base your product on dangerous assumptions, develop it with thoughtfulness and strive to develop a sustainable product.
No comments:
Post a Comment