Button thinking against a holistic IT product

This article is an expression of my personal pain. Push-button solutions ruin my life, I spend time arguing and justifying.

When we communicate with colleagues, customers or users, I use the phrase "push-button thinking." What do I mean by this term? Current article - a detailed answer to this question.

Synonymous with button thinking, I consider “on-screen thinking” or premature conceptualization. I will reveal the thinking with buttons on a dozen examples from practice. And here to begin with a story that probably happened to everyone. Imagine coming to you and talking about the fall of the conversion on the site. And you immediately: “Let’s make the buy button bigger and brighter!”. What happened? There was a problem in business. Instead of diving into details, instead of researching the reasons, you play with the dimensions of the button. It is in such cases that I speak of button thinking.

For those who like to watch, not read, there are videos and slides .

Who generates button ideas

Practice has shown that there are three types of people who generate push-button solutions. It will not be about specific positions in the project, because every member of the team can mess up. Programmers, QA, designers, customers, investors, and end users are potential button makers.

1. Toropygi

Imagine the situation in which the customer brings the problem. He shares this problem with Torpygy. What does Toropyga respond to? Feels pressure, as if the customer is waiting for a response, and an immediate one. After the customer’s question there is a pause, but there is no answer in the head, the tension increases. In his imagination Toropyg already sees how the customer accuses the poor fellow of incompetence. Therefore, the customer is given a premature and rash decision.

What to do if you notice a disease of hurry? First, be aware that it is impossible to know all the answers. Coming up on the fly is not a sign of professionalism. Secondly, taking pauses in negotiations and at meetings is the norm. Take a pause, go think. Bring with you solutions, risks for each, pros and cons .

2. Reshaly

Reshaly - pro guys who ate dog at IT. Ask - immediately answer. Although not a fact that they have serious projects and dozens of years of experience.

For Reshaly, incoming problems and tasks are typical, already solved. According to the Cynefin Framework, Resals see the world in the Obvious box, well, the maximum in Complicated. Those. their solution is already ready, you just need to select the category of the problem.

Reshals are depriving themselves of a chance to present a well-developed solution to the customer and grow on a new task.

Customer-decided more terribly developer-reshaly because he likes to push Pet Features into the product.

3. Saviors

Suddenly, in the head of a person, there is a feeling that if he does not rise from his knees and lead the team, then the end of the project, the product and even the company. He takes on the role of the Savior, raises the flag and leads people behind him. The saviors think with special fanaticism.

Yes, this is situational leadership , about which so much has been said in flexible development approaches. Yes, that is right. Only not all situational leadership is equally useful. The problem arises when during a climb a person stops hearing others and adequately assess the situation. His decisions are beginning to be ultimatum, he is at war, he is a savior, he decides the fate.

If you notice the Savior in the project, then try to bring the person out of this state. Slowly but tough, the sooner the better. He himself will then be sad about his decisions made in the heat of passion.

I am a powerful button generator

I do not know to which part of myself to attach, but I myself am a great generator of buttons and quick solutions. 10 years of experience and the speed of the brain do not make me doubt that I was right. I decide with terrible speed and enjoyment.

Surely in the world live IT people with a steel will. They are able to keep themselves in tough frames, will not fall out in the role of Reshaly or the Savior. I do not belong to such people, and occasionally I roll into one of the roles, and sometimes into their combination.

When I realize this, I hit my cheeks, prick with a pin and slow down my decision. Not always successful. And still I train, it seems it gets better over time.

Mimic User Story and Tricky Product Owners

With the sources of button thinking sorted out. Now let's figure out what to do with them. Why do we give Resalam steer? Why not throw off superficial ideas? What will protect from your own decision?

User Story as a filter

When I thought about filters that do not allow button ideas, I remembered the User Story . In ByndyuSoft, we use stories to shape project tasks in daily practice. The power of the User Story is to make it describe the value. There is no value in history - there is no extra button in the interface.

The work is as follows. Bringing an idea into the work → describe it in the form of a User Story. Answer the question "What?".

You want a report upload button in Excel. Ok so what? To be on the safe side? In the trash, do not take to work.

Accountant Olga said that she likes it so much? In the trash, do not take to work.

You consulted inside the department of economists, drew a button in the interface and now you want us to add it? For what? Because this is your idea and you like it? In the trash, do not take to work.

You are the customer and you see it that way? There is no other “so what”? In the trash, do not take to work. (although we sometimes implement the Pet Feature, we start by saying the risks and showing the futility of this undertaking).

Sly Product Owners

User Story hardcore button ideas. Tested in practice. But here comes the other side of the problem. Product Owners and Stakeholders realized that they could not get through the User Story, because they had to look for the answer to the question “What for?”. And it’s hard if you come with the Pet Feature . Difficult, but very desirable.

Product owners have adjusted to the new model of setting tasks. They learned to play this game.

I'm like a corporate client
I want to download a report on cash flows
To see the balance go negative

An inexperienced developer or designer will take this story for the right one. But look at her carefully. Re-read this story and try to figure out what questions you may have for the Product Owner.

I would first ask about the future life of the downloaded report. About the life of the user who downloads this report. What will he find in the report? With what will find the right? How will he separate the necessary from the unnecessary?

Mimic User Story

Although the format User Story is observed, but without immersion and additional issues in the work we do not accept. Digging, looking for the roots of the problem. Ask open questions, use 5 Why . Over time, we find out the root of the problem and write it in the User Story:

I'm like a corporate client
I do not understand the state of the account and because of this I am going to a minus
I want to ...
To ...

Already better, because we understood where the button solution came from with downloading the report. Now we know that the client loses money if he does not promptly receive account information.

The next step is to understand how we will change the life of the corporate client so that it solves this problem. Gojko Adzic in the book Quick Ideas to Improve Your User Stories indicates that it is better to register in the User Story the delta between how the user lived before the release and how he healed after the release. We get this story:

I'm like a corporate client
I do not understand the state of the account and because of this I am going to a minus
I want to stop work if the balance has become critically low
In order not to lose money

We will stop the work of the user and waste money when the balance becomes negative. When we voice a proposal to users, they do not believe that you can automatically stop the work. For the user, the pain of losing money is so strong that they themselves invented downloading the report, they are ready to look into the report, look for the answer to the question about the negative balance.

In the latest version of User Story, the button solution is removed. The root problem has been excavated. A solution is proposed that closes the root problem. There was a chance to benefit after the release, rather than add another button to download another report.

Premature solutions

Some people want to shoot out the solution. They seem to play their game or Brain Ring. Waiting for the question and the speed offer a solution.

With hasty decisions, a blind zone arises between the problem and the idea. The chain of reasoning and conclusions remains behind the scenes:

We do not make one decision, we dig the root of the problem, we identify the actors. After paving the way out of the target, the actors and the root of the problem, the button solution loses its former strength:

Having seen the root problem or need, we throw a lot of possible solutions:

Please note that the choice is now visible, but the choice itself is more difficult to make. I have a suggestion that people deliberately stop at the first solution that seems appropriate. After all, if you go further, you will have to choose, assess the risks of each decision, the pros and cons, the work is added. In addition, the wider the choice, the less joy the final decision.

Deep drilling problems costly, no one seeks into this swamp. But if we create a useful solution, then we overpower ourselves and reveal the blind zone.

Life stories:

• Case: Narrowing Vision
  Release planning in progress. Product Owner ends the sentence with the words: "... can be sent by mail." I immediately stop the discussion, because in one sentence the narrowing of the problem to one solution occurred. Stopped and unearthed the root of the need. Why send? Why by mail? In the world, after all, many ways have been thought up of conveying information to users. In the end, they offered 5 ways to tell customers about updates. Tip: Do not allow the problem to be narrowed to one solution.
  
• Case: Solutions without a problem
  The new customer is discussing with us the modernization of the IT product. While talking about the product, he remembers the problem - customers go into the negative and overspare resources without payment. The service takes money as the operation proceeds, but it is impossible to predict expenses in advance. As the customer tells the story, the idea to visit is to chop off access and leave the client without result.
  Discussion interrupted, unearthed the problem of users. It turned out that users do not understand how much money remains at each moment in time, so they cannot make decisions promptly. We offered to show them the costs and current balance, changing online. The customer was surprised and said: What is it possible?
  

How much are 1000 lines of code?

Imagine the scene in the store. You scored products in the basket and went to the checkout. The cashier broke through the goods, weighed the fruits and vegetables, called the cost. A typical situation for the purchase of products.

Scene one to one when creating an IT product. You sit at the checkout, the customer comes with a basket of features and solutions. You evaluate, weigh, tell him the cost.

Let's go back to the store and replay the situation. You come to the checkout, lay out purchases. The seller says to you: “You shouldn't have taken the Shedi Lady tomatoes for rabbit stew. This variety is too sweet for stews not suitable. Take the grade Little Prince, the stew with them is excellent. "

Let's see what has changed. Why are you grateful to the cashier and want to hug him? He recognized your purpose. After that, he proposed a solution that moves you toward the goal, rather than silently agreed with the proposed solution. The value of buying at this store has increased, satisfaction has grown, you will want to come to this store again.

Now back to IT. For identifying goals, understanding ways to achieve goals, making choices from solutions, I recommend Impact Mapping :

Technique is studied in a couple of days. With the help of Impact Mapping, we pave the way from solutions to goals, prioritize solutions and paths, cut off the Pet Feature , which comes from the business and the team. The only difficulty is the process of creating Impact Mapping, it requires facilitation skills.

Life stories:

• Case: Need more popups
  Imagine the IT department inside the company. The heads of the marketing, economics and other departments set tasks for the IT department. A boss arrives who is responsible for the sales points and sets the task - to add a pop-up message every 10 minutes to the workplace. Employees and in the field will be obliged to click OK in the modal window every 10 minutes in order to understand whether the worker is on site or not. The task as a task, the IT department took it and did it. The time has passed. Field workers have lived up to the innovation.
  
  The head of marketing came to the IT department and asked for a pop-up message to be added so that the employee would go out and distribute flyers. The message as it is thought comes up every 30 minutes, as a result, sales should increase. The task as a task, the IT department took it and did it.
  
  On the ground, this resulted in a contradictory scenario. The worker pops up a message that you have to go outside and hand out flyers. He goes out and distributes, and at this time a message pops up: "Are you there?"
  
  Why did it happen? No one controlled the integrity of the system. Multi-headed Product Owner brought the task, the developers took the task without question.
  
• Case: Why do?
  The customer came to us with the idea to make an application for couriers. The customer is a federal company, hundreds of branches throughout the country. The purpose of the product is to optimize the work of couriers.
  
  Before working with us, the project has a six-month history. The customer was given a TZ, they implemented a part of the mobile client, but they did not do the server part. With this story, the customer came to us. We started the project in our process and by the end of the Customer Journey Mapping it dawned on the customer. They changed the business model, launched a series of experiments in business and promised to return to us in 3 months. We consider this a success, because not allowed to spend time on a worthless product.
  

Movement without a goal

In continuation to the formulation of the goal. If the goals of the IT department or IT product are not formulated, then this is fertile ground for push-button solutions. Paraphrasing Zhvanetsky's phrase from the monologue : If there is no goal, then wherever you go - it turns out "forward."

When we take a task, we compare the cost of the task with the effect that the task will have on achieving the goal. And if there is no goal? So there is nothing to measure. This is where the work style is born, when tasks are realized, because it is cool to realize these tasks. In such departments, the development is full of life, features are added, there are continuous releases. With this rapid movement, the result does not change.

Life stories:

• Case: We will show because we can
  Product - SaaS tool for top e-commerce partners in Russia. Dialogue with the customer's IT department:
  “Let's draw contracts in the interface,” says the developer on the customer’s side.
  - For what? - we answer.
  - They are already in the database, you can easily withdraw.
  - How does this help to achieve the goals of the product?
  - Without contracts it is impossible to pay!
  - To pay, you need to start using the product, but it does not exist yet.
  
  In such cases, only returning to the objectives of the project and filtering using Impact Mapping helps.
  

Self Reflection and Peace of Mind

To save your nerves, I share the developed strategy of dealing with push-button thinking:

1. When they came to you with a button idea, ask yourself why they brought such a solution, why you do not like it, what questions will reveal the root of the problem. Only after that start talking.
2. Understand that colleagues are not out of evil climb with push-button ideas. No one wants to hurt or sabotage. Everyone is trying to benefit.
3. Manage to achieve business goals, not tasks
4. Put problems to the team, but do not come with solutions
5. Do short iterations (1 week or less), constantly collect feedback from the team and customers
6. Validation of ideas as early as possible, kill ideas before the implementation phase

Recommendations equally banal and effective. It helps me in my work.

Notice the button thinking behind you, notice your colleagues, tell customers and learn how to work with user requests. Help each other in overcoming illness. Write your stories in the comments, let's laugh together at the wrong and strive for the right.

UPD: Translated the article into his English-language blog https://medium.com/@alexander.byndyu/button-thinking-versus-consistent-it-product-3f5c6341cda2