Questions for Feedback

Feedback is often touted as millions with a panacea that seems to solve all the disaster in software development. Hey, of course we like it! But we also need to keep in mind some important aspects of the feedback, rather than simply declaring that "more and more frequent feedback" is the answer to all questions.

Not all of the feedback is equal.

Feedback has its price.

This means we need to choose wisely where to collect feedback and how we intend to use it.

1) feedback is not equal

Feedback is not a prophecy, because data does not tell us what to do-it simply responds to a problem. The order system tells us that sales have fallen this month compared with the same period last year. Then obviously we're going to want to ask what it is. Maybe we'll call a client and ask why we haven't bought our new upgraded product this year, and they'll give us some reasons.

Feedback can be divided into two distinct categories-one is quantitative, the other is qualitative. Both of these feedbacks will reveal something to us, but they can't tell us what we need to do. And even if action is needed, it is not always obvious what to do. Perhaps last year we launched an advertising campaign, which has led to a surge in sales. But we should not expect this year's sales to be the same as last year's. In fact, tweaking a product to respond to a hypothetical problem may lead to worse problems.

So we need a lot of feedback to make sure that we get rid of all the "noise" that interferes with the signal--and that's not always easy to implement. Hard feedback in digital form, such as sales performance, usage, and enrollment rates, is not a lie, but sometimes they need to be interpreted reasonably. The drop in sales may be disastrous, but the compelling numbers rarely contain clues to the problem.

Note, however, that this feedback is critical. It is so important that we suggest that we always try to make the "concept cashing" feedback loop as compact and fast as possible.

This is because subjective data and feedback can be misleading. People do not always tell us openly and honestly the true thoughts of their likes and dislikes. For example, a lot of research has shown that people claim they need a healthy diet, but in fact they tend to choose unhealthy foods. If we were the coffee shop owner and decided to offer a variety of salads on the menu based on the first data set (people announced), we might find that the profits were down--instead, the burger store next door sold hundreds of more unhealthy foods every day.

This is not entirely because people deliberately or deliberately mislead, but because they may not know what they want. So we're going to use a lot of feedback technologies--such as prototyping and testing environments--to help us understand what customers actually use and do (not what people claim).

When Monash University in Melbourne wanted to know the views of students (as potential users) on the school curriculum query system, they did not ask their students directly. Instead, they created paper prototypes for two different design ideas. Next, students interact with these "paper computers" to accomplish their tasks. While the staff later asked which option the students preferred, most of the important information still came from observing the students ' actual performance-which system was easier for students to communicate with. The results of this test led the product team to choose the one they didn't like from a design perspective, but apparently the students felt that the design was easier to use. More importantly, the exercise raises other issues, such as almost 1/3 of students who can't get the job done because they don't understand where to obtain further information. No subjective problem set can elicit such high quality feedback.

Finally, if not all types of feedback are equal, then again, the source of the message is not equal. Back to the company we're supposed to be selling down ... What happens when we start dialing customer calls to collect feedback? They will give different answers, even contradictory messages. And when we join the Director of marketing, the CFO, the nephew of the CEO, and even other people's opinions, who should we listen to?

Many organizations are avoiding the problem-perhaps because they know what the real answer is, but it is also clear that it will be different from what is actually happening. We all have problems with the HiPPO (the highest-paid people) and we have to work hard to make sure that the top opinion doesn't cover the customer's voice. To achieve this, we need to make sure that we keep our work as close to the real customer as possible.

Sometimes we do not obey the client. Customers sometimes want our company to do things that we know are not profitable or, in some ways, are damaging profits. In some scenarios, a lot of feedback can cause distractions (and perhaps an idea that is so radical that no one can really understand it at this stage). Customers should not control the development process, but there is no doubt that the development process should absorb information from customers. Only customers can tell us what they will pay for. Ignoring the customer's voice poses a risk.

In his book, Lean Entrepreneurship, ericries the story of a teenage girl testing a product and figuring out whether it's cool, and she doesn't want to invite any friends to talk about the product. Ries instead recruited another teenager ... The same story goes on again. "We are beginning to encounter a pattern, and no matter how stubborn we are, there is no denying that there is something wrong," Ries in dismay.

The problem is that many organizations rarely communicate with actual customers. Instead, they may arrange for "internal customers" or "Customer agents". No matter what we call the product owner, the customer representative, or the "Business customer", there is no difference. While this may seem like an effective shortcut-the customer agent will make all the decisions about priorities and accept or reject the product-but they are still not real customers, so the value of their feedback is limited. The team still needs to get the product into the hands of real customers and users-there is no substitute for it.

However, the lack of communication with actual customers is not an excuse to do a lot of advance exploration. As has just been discussed, no analog or subjective feedback can match the real data. This also means the need to continuously and as much as possible shorten the concept redemption cycle, so that the product into the hands of real, paid customers.

There is another complicating factor that makes this topic more difficult. The types and sources of feedback are not equal, and we are not equally concerned. All of us-no matter how experienced and knowledgeable we think-can be influenced by cognitive biases. This effect means that we unconsciously give greater weight to evidence similar to our own, but ignore evidence that contradicts our view.

We are not thrilled by the new input to help with the project's improvement; instead, we look at feedback as a rework primer. How many times have we heard someone in the team complaining: "I've got to do it all again!" ”？ Honestly, how many times do we have the same idea? Most organizations or individuals believe that it is more difficult to retrieve feedback than to search for a real customer to join a team, build a shorter development cycle, or set up tests to observe user and customer feedback, especially when retrieving unwelcome feedback. For such organizations and individuals, they all need a major cultural transformation.