Button Thinking versus consistent IT-product
Mimicking User Story, tricky Product Owners and ‘button’ ideas
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.
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.
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.
Savior-guy
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.
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.
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.
Consider our work process:
- You invent a new feature for an IT-product.
- Write it in the User Story format.
- Describe measurable business value for the product, it means answer the question — what for?
- 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.
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.
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:
- Case: Narrowing of vision We were planning a release with a Product Owner. He ended the conversation with the phrase, “…send it by email.” In such a case I always stop the planning discussion because ‘send’ and ‘email’ are the solutions for the root problems that we haven’t found yet. Eventually, the team suggested 5 ways to notify the user about product updates.
- Case: Solution without a problem We were talking with a client about his IT-product (3D-render service) modernization. While he described his existing product, he was concerned that users were overusing the resources of his render farm without payment to him. Consequently, he lost money. It is a complicated task to predict the time when a 3D-scene will be completed so, you can’t predict the render cost either. At the moment, the client came up with an idea — stop the rendering if a user spent all prepaid money and leave the user without a result of rendering. Of course we stopped the discussion and found the root problem for the user. We discovered that a user has no actual information about his balance while the rendering is in progress. After we found the root problem we suggested showing the balance on the screen and keep it updated. The client was surprised and said, “I didn’t think that we could solve it like that!”
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:
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:
- Case: We need more popups Consider a typical IT department in a big corporation. The head of the marketing department, the head of the sales department and other heads are creating tasks for the IT department. One time, the head of sales came to IT and created a task — make a popup message that will appear every 10 minutes in the corporate sale system. Every employee, while connected to the system, will have to click the OK button to show that he is actually with the clients in the office. The IT department took this task and developed it with no questions. All employees learned that they have to click the OK button every 10 minutes. The last time the head of marketing came to the IT department and created the task — add a popup which will ask employees to go out on the street and promote company products. This popup has to appear every 30 minutes and it aims to boost sales. Again the IT department took this task and developed it with no questions. It was real nightmare for employees. Because every 30 minutes the system asks you to go out and promote products, and now you could miss the first popup that asks, ‘Are you here and working?’ The reason why the whole system became inconsistent is, nobody controlled the system integrity. They didn’t have a birds-eye-view plan for their business and should have used, for instance, Impact Mapping.
- Case: Why we do what we do? A client came to Byndyusoft with an idea — create a mobile application for their couriers. The client is a federal company with hundreds of branches around the country. The business goal of the IT product is to optimize courier costs by 2. Before the client came in my company, the IT-product had a 6 months development history. The client bought an Information Architecture document, paid for a mobile application but the previous developers were not competent enough to develop a server-side code and the necessary algorithms. So the client came to us with the project in this state. We began working by our process — Impact Mapping, then Customer Journey Mapping, then User Story Mapping etc. In the middle on this process they realized that they don’t need the project in the current business model. So, they changed the business model for the couriers department. They began a number of experiments and promised to get back to us after their first results. So we only spent 8 hours to give the client his business value. We believe that it is successful because we saved the client money and time.
- Case: Because we can! We are working with a web service that affiliates users who can earn money by selling products on their platforms. The client is one of the biggest e-commerce companies in Russia. Our dialog with the department on the client side follows: “Let’s show a list of offers in the user interface in the first release” said the head of the department. “What for?” we responded with suspicion. “Because we have a list of offers in our Database, so it is very easy to show a list of them in the interface.” “Will this feature bring us closer to the business goals of the project?” “No, but it is really easy to develop…” In this case we have tried to explain that we must develop features for achieving the business goals but not the features that we can implement easier. We used Impact Mapping to convence them during the discussion.
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:
- 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.
- 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.
- Manage people only on the business goal level, not on the task level.
- Bring problems to the team, not solutions.
- Develop the project in as short a time as possible (1 week or less). Gather feedback from the users, clients and the project team.
- 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.