Button Thinking versus consistent IT-product

Mimicking User Story, tricky Product Owners and ‘button’ ideas

Александр Бындю
Александр Бындю · 16 июня 2016
IT-архитектор · Эксперт в Agile и Lean · Основатель компании Byndyusoft

This article is an expression of my pain. Button Thinking has ruined my life. I spend lots of time arguing and rationalizing with people.

When I talk with colleagues, customers and users, I use the phrase ‘button thinking’. What do I mean by it? This article is an explanation of this question.

The term Button Thinking is synonyms with terms such as Screen Thinking and Premature Conceptualization. I’ll share about a dozen stories from my experience later, but for now I’d like to tell a story that I believe you are familiar with.

Imagine that a client comes and complains about low conversion rate on the website that you have built for him. You suggest a solution immediately without having to think about it, “Let’s make the Buy button bigger and brighter!” What just happened? Your client came to you with a problem. Instead of diving into details or finding the reason why the conversion rate decreased, you suggested to play with the Buy button size and color. In this situation I use the term ‘button thinking’.

Who generates Button Ideas?

I’ve found three types of people who produce ‘button’ ideas. Note that any member of an IT-product team — developers, QA engineers, designers, clients, investors, stakeholders and users — can make such a mistake.

The Bustler-guy

Consider a situation when the client came with a problem. The client explained a problem to the Bustler. In this case, the Bustler feels pressure because he thinks the client is waiting for a solution right now. The Bustler feels that without an immediate solution the client may accuse him of incompetence. That is why the Bustler generates a premature and hasty solution.

How the Bustler (right one) feels himself on the negotiation with a client (left one). http://youtu.be/CjVVNuraly8

If you find yourself as a Bustler, don’t worry too much. The good news is that you can fix it. First of all, be aware that nobody knows everything. I can assure you that your professional level will gain no points if you blurt out a solution without thinking. And it’s fine if you pause the negotiation. So, take a break to think and come back to the client with a few possible solutions and a list of pros and cons with the risks written out for each solution.

If the client needs a solution right now and can’t wait, then give him the link to this article. I hope he’ll find solid information that will make his wait less frustrating.

The Solution-guy

The Solution-guy is an ultra professional with tons of experience in IT. Ask him anything and you’ll get an answer immediately. He likes to look and act as if he has a lot of experience, when in fact, he has little.

How Solution-guys feel themselves

If you are solution-guy, any existing or future problems are already solved. Solution-guys see the IT-world in the Obvious part on the Cynefin Framework model. It means they need to classify a problem to get the best solution from the shelf.

The Solution-guy tricks himself because he has no chance to grow as a professional. Moreover, the solution-guy can’t deliver high quality solutions to a client because he doesn’t dive deep enough into the problems.

If a client is a solution-guy, he likes to push Pet Features into the backlog. We are going to discuss later how to handle this.


Suddenly, some team member senses that the fate of the project now depends only on him. He becomes the Savior of the project. The Savior-guy has fanatic button thinking.

Only the Savior can solve the problem and save the project

You may say that I’ve just described situational leadership which is praised in agile methodologies. Yes, I did. But, not all situational leadership is equally useful.

The problem with the Savior-guy occurs when he stops listening to anybody but himself. He also stops adequately assessing the situation. As a result, the Savior-guy produces the ultimate solution and doesn’t want to listen to any other opinion — he is now a super button thinker.

If you have a Savior-guy on your project, try to snap him out of this mental state. The faster you do this the better for the project, product, and the whole company. Somebody has to help the Savior.

I’m the powerful button generator

I don’t know exactly which type I am but I know I’m as powerful a button generator as the guys above. I’m a master of fast decisions. 10 years of IT experience and fast brain speed leaves me no doubt to the correctness of my solutions.

Button Thinker inside me

I believe that somewhere there are IT developers and managers with steel will. They have full control of their minds and have the ability to not be the Solution-guy or the Savior-guy. I have no steel will, that is why I became one of the button-thinking-guy or combination types.

When I recognize myself as a button thinker, I slap my cheeks, prick a pin in my hand and try to stop button thinking. To be honest, not always successfully. Anyway, I’m training myself and it seems to have become better.

Mimicking User Story and tricky Product Owners

Ok, we discovered the sources of button thinking. Let’s explore the approaches on how to fight this disease.

Ask yourself, why do we allow the Solution-guy to rule the process? How can we detect poorly thought solutions and throw them away before they have added to the backlog?

User Story as a filter

When I was looking for button thinking barriers, I remembered my favorite way to write requirements down — User Story. At Byndyusoft, we always use User Story for planning the day-by-day work process. The power of User Story is a format that grantees the explanation of business value. If User Story has no Value — just throw it away and do not add an unnecessary button to the user interface.

image source: medium.com/swift-space

Consider our work process:

  1. You invent a new feature for an IT-product.
  2. Write it in the User Story format.
  3. Describe measurable business value for the product, it means answer the question — what for?
  4. If you can’t explain business value, sorry, we can’t add your idea to the backlog.

For example, somebody wants to generate a report in Excel and download it by a button. Ok, we can do it, but answer the question — what do you need it for? Just because you want it? Or because you ‘might’ use it in the future? Throw this idea out, don’t let it in the backlog.

Account manager Lisa said that she likes this color and we have to recolor a report list. The only reason why we have to do it is because she likes it. There is no business value. Throw this idea out, don’t let it in the backlog.

The whole economic department decided to add a new button to the user interface which has no business value, what for? Just because it is their idea and they like it? Throw this sh*t out, don’t let it in the backlog.

You are the client and you see the interface like this. Do you have other answers to the question — what for? No? So, throw this idea out, don’t let it in the backlog. (To be honest, sometimes we develop Pet Feature for a client. But before we start to develop a Pet Feature, we show the uselessness of this feature to the client).

Tricky Product Owners

User Story format is a really strong filter against button ideas. We approved it in practice.

That’s why we are faced with the next problem. Product Owners and stakeholders understood that due to the User Story format, they can’t add anything (Pet Features) to the backlog. Now it has become very hard because the team is asking ‘what for?’ for every feature and idea.

It is hard because Product Owners really like to add things. They are arranged under new conditions and they have learned how to play in this game.

A Tricky Product Owner

Consider this User Story:

As a corporate client
I want to download a cash flow statement report
so that I see that my cash balance is negative

If you don’t have not enough experience, you may take this User Story to the backlog. But we weren’t born yesterday. Please, read carefully User Story one more time and prepare questions for the Product Owner.

I would start by asking this question: “‘What will a corporate client do with the downloaded report?” Because I need to know the clients behavior with this report. What will a client find in a report and how will he find the necessary information? How will a client pick out useful information and weed out information noise?

Mimicking User Story

Although a Product Owner may use a correct format for User Story, we can’t just take it with no questions. We have to find the root problem by asking opened questions and using the 5 Why approach.

Eventually, we will find the root problem and we can change the User Story:

As a corporate client
I have a problem: I don’t know the state of my cash balance. This is the reason why I go to minus balance and lose money.
I want…
so that…

That’s better because we understand why the Product Owner invented the ‘button’ idea for downloading a report. Now we know the root problem: a corporate client lost money because he couldn’t obtain the most current cash balance information.

The next step — to find out how to change a corporate client’s life by solving his problem. In the book Quick Ideas To Improve Your User Stories, Gojko Adzic, draws attention to explicitly show the changes between user life before and after a feature release. With this in mind, we change the User Story to:

As a corporate client
I have a problem: I don’t know the state of my cash balance. This is the reason why I go to minus balance and lose money.
I want to stop working if the balance begins to get closer to zero
so that I’m not losing my money as a negative balance would mean getting a loan

When we show a new version of the User Story to the Product Owner and users, they will recognize how far they were from the solution of their problem in the first version. Users were ready to download a report and analyze it by hand. You could implement the ‘button’ solution but we spend the time to find the root problem first, and then suggest solutions.

Premature solutions

Some people are itching to blurt out a solution. They looks like they are playing Trivial Pursuit. They are waiting for a question and competing with other team members who suggest a solution faster.

People can’t keep solutions inside

You’ll have a blind spot between a business value and a solution if you suggest a solution too early:

In such cases, we would first get the invented solution to work. And now we know that we have to find the root problem or real client needs:

After we’ve found the root problem and actors — mandatory points between business value and solution — we can see how the first invented solution is losing ground.

Now we can suggest more than one solution because we found the root problem. So we have a choice:

From the other side due to more options, it is harder to make a decision. So I think people intentionally stop at the first solution that looks good enough. Because the more choices you have, the less satisfaction you’ll get after the decision. At worst, you could be stuck with too many choices. So, as professionals we have to look up the maximum number of possible solutions.

Life Stories:

Weigh 1000 lines of code, please

Let’t flash forward to the supermarket. You loaded a basket with food and came to the cashier. The cashier is weighing your fruits and vegetables, calculating the total cost and tell you the sum you have to pay. It is a very common situation.

We witness the same situation in the IT world in our own companies. A customer comes to us with a basket full of features. We are, as a cashier, weighing the basket and tell the total price.

Let’s go back to the supermarket and change the common scenario. You loaded the basket with food and came to the cashier. Instead of weighing your food, the cashier said, “You have chosen the wrong tomato for your sauce. You got an Alicante but the best choice for your sauce would be a Campari.”

It could be a little confusing but you appreciate the service in this supermarket. You want to say ‘thank you’ to the cashier because somehow he recognized your cooking goal — excellent sauce. After that he offered a better solution instead of agreeing with you silently. Thereby, the business value of the purchase in this supermarket is increased for the client.

Go back to IT again. For recognizing business value and for finding a path to the clients business goals, I recommend using Impact Mapping:

Impact Mapping

You could learn this technique in few days. You will be able to explain Impact Mapping to the clients very quickly and they’ll like it because it is simple and effective for strategic planning. Furthermore, Impact Mapping is a great tool for filtering Pet Features from a client and a team.

Life Stories:

Self-reflection and peace of mind

I would like to share my rules that keep my nerves and time at war with Button Thinking and Button Thinkers:

  1. When somebody asks to implement his ‘button’ feature, ask yourself why he brought this solution, why don’t you like it, which questions will help find the root problem. Only after that start talking with button thinkers.
  2. Try to understand that colleagues, clients and users generate ‘button’ ideas not out of malice, but because they don’t know the other way to solve their problems.
  3. Manage people only on the business goal level, not on the task level.
  4. Bring problems to the team, not solutions.
  5. Develop the project in as short a time as possible (1 week or less). Gather feedback from the users, clients and the project team.
  6. Validate a business hypothesis as early as you can. Kill any erroneous hypothesis before you get it into the backlog.

The recommendations are equally trivial and effective. They help me in my day-to-day work.

Take notice of your button thinking as well as your colleagues. Tell clients about this phenomena. Learn how to work with incoming ‘button’ requests. Write your stories in the comments, it would be great to see that it is not only my concern.