Life stories:
Case: Narrowing the vision
Release planning is in progress. Product Owner finishes with the words: "...can be sent by mail. I am immediately stopping the discussion because the problem has narrowed down to one solution in one sentence. We stopped and dug up the root of the need. Why send? Why by mail? There are a lot of ways in the world to deliver information to users. As a result, we offered 5 ways to tell our customers about the updates. Tip: Do not let the problem narrow down to one solution.
Case: Solutions without a problem
A new customer is discussing the modernization of the IT product with us. While he is talking about the product, he remembers the problem - customers go into the negative and overspend resources without payment. The service takes money as the operation progresses, but it is impossible to predict the costs in advance. As the story of the customer visits the idea - to cut off access and leave the client without results.
Discussion was interrupted, the problem of users was excavated. It turned out that users don't understand how much money is left at each moment of time, so they can't promptly make decisions. We offered to show them the costs and the current balance, changing online. The customer was surprised and said:
"What can you do?
How much do 1000 lines of code cost?
Imagine a scene in a store. You put the products in the shopping cart and went to the ticket office. The cashier punched through the goods, weighed the fruits and vegetables, named the cost. Typical situation for buying food.
Scene one to one when creating an IT product. You sit on the cash register, comes the customer with a basket of bugs and solutions. You evaluate, weigh, tell him the cost.
Let's go back to the store and replay the situation. You go to the cash register, you lay out your purchases. The seller tells you: "You shouldn't have taken Shedy Lady's tomatoes for a rabbit stew. It's too sweet for a rabbit stew. Take the Little Prince, the stew with them is great.
Let's see what has changed. Why are you grateful to the cashier and want to hug him? He recognized your purpose. He then proposed a solution that moves you towards your goal, not silently agreed to the proposed solution. The value of buying in this shop has increased, the satisfaction has grown, and you will want to come back to this shop.
Now back to IT. I recommend Impact Mapping to identify the goals, understand the way to achieve the goals, and make a choice from the solutions:
The technique is being studied in a couple of days. With Impact Mapping we are paving the way from solution to goal, prioritizing solutions and paths, and cutting off the Pet Feature that comes from the business and team sides. The only difficulty is the Impact Mapping process, which requires facilitation skills.
Life stories:
Case: Need more pop-up windows
Imagine the IT department inside the company. The heads of marketing, economics and other departments set tasks for the IT department. The head who is responsible for the points of sale and sets the task - to add a pop-up message once in 10 minutes at the workplace. Employees in the field will be required to press OK in the modal window every 10 minutes to understand whether the employee is on site or not. The task as a task, the IT department took a yes and did. The time has passed. The employees in the field have got along with the innovation.
The marketing manager came to the IT-department and asked to add a pop-up message for the employee to go outside and hand out leaflets. The message is supposed to pop up every 30 minutes, which should result in higher sales. The task as a task, the IT department took it and did it.
On the ground, this resulted in a contradictory scenario. A message appears to the employee that he should go outside and hand out leaflets. He goes out and distributes it, and at the same time the message comes up: "Are you there?
Why did this happen? Nobody controlled the integrity of the system. Multiheaded Product Owner brought the task, the developers took the task without questions.
Case: Why do we do it?
The customer came to us with the idea to make an application for couriers. The customer is a federal company, hundreds of branches across the country. The purpose of the product is to optimize the work of couriers.
Before working with us, the project has accumulated a six-month history. The customer was provided with TK, a part of the mobile client was implemented, but the server part was not made. With this story, the customer came to us. We started the project on our process and by the end of Customer Journey Mapping it hit the customer. They changed the business model, launched a number of business experiments and promised to return to us in 3 months. We think it's a success because we didn't allow us to spend time on a useless product.
Moving without purpose
Continuing with the formulation of the objective. If the objectives of the IT department or the IT product are not formulated, this is a fertile ground for button solutions. To paraphrase Zwanetsky's phrase from the monologue: If there is no goal, wherever you go, you get to "go ahead".
When we take the 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? It means that there is nothing to measure with. Hence, the style of work is born when the tasks are realized, because it is fun to realize these tasks. In such development departments, life boils, features are added, there are continuous releases. At the same time, the result does not change.
Stories from life:
Case: Let's show it because we can
The product is a SaaS tool for partners of the top e-commerce Russia. Dialogue with the customer's IT department:
- Let's deduce the contracts in the interface, - says the developer from the customer's side.
- So that what? - We answer.
- They are already in the database and can be easily output.
- How will this help you achieve your product goals?
- Without contracts it is impossible to pay!
- To pay, you need to start using the product, and it does not exist yet.
In such cases, only a return to project goals and filtering with Impact Mapping can help.
Self-reflection and peace of mind
To protect your nerves, I'm sharing a strategy to combat button thinking:
When you have a button idea, ask yourself why they brought the solution, why you don't like it, what issues will reveal the root of the problem. Only after that, start talking.
Understand that colleagues are not evil with button ideas. Nobody wants to hurt or sabotage. Everyone is trying to do good.
Manage at the level of achieving business goals, not objectives
You put the team in trouble, don't come up with solutions.
Do short iterations (1 week or less), collect feedback from the team and clients at all times
Validate ideas as early as possible, kill ideas before implementation
The recommendations are equally banal and effective. It helps me in my work.
Notice the button thinking behind you, notice your colleagues, tell your customers and learn how to handle user requests. Help each other with their illness. Write your stories in a comment, let's laugh together at the wrong things and strive for the right things.