Mimicking User Stories and tricky Product Owners
The sources of button thinking have been dealt with. Now let's figure out what to do with them. Why do we let the Decisions drive? Why don't we throw away superficial ideas? What will prevent us from making our own decisions?
User Story as a filter
When I thought about filters that didn't miss the button ideas, I remembered User Story. We use stories to form project tasks in everyday practice. The strength of User Story is that they make you describe its value. There is no value in history - there is no unnecessary button in the interface.
The work is built as follows. Introduce the idea → describe it in the form of User Story. Answer the question "To what?
You want to upload the report in Excel. OK, so what? To be just in case? In the trash can, we do not take in work.
Olya's accountant said she liked it so much? In the trash can, do not take in work.
You consulted inside the department of economists, drew a button in the interface and now you want us to add it? So that what? Because this is your idea and you like it? In the trash can, we do not take in work.
You are a customer and you see it that way? There is no other "to what"? In the trash can, we do not take in work. (Although we sometimes implement Pet Feature, we start by talking about the risks and showing the uselessness of this idea.)
Cunning Product Owners
User Story is a tough way to sift through button ideas. Tested in practice. But there is a downside to the problem here. Product Owners and stakeholders realized that User Story is not going through, because they have to look for the answer to the question "To what? This is difficult if you come with Pet Feature. It's complicated, but I really want to.
Product Owners have adapted to the new task definition model. They learned how to play this game.
I'm a corporate client
I want to download the cash flow report
To see the balance become negative
An inexperienced developer or designer will take this story for granted. But take a closer look at it. Read this story and try to figure out what kind of questions you'll have to ask Product Owner.
I would like to start by asking about the future life of the downloaded report. About the life of the user who downloads this report. What will they find in the report? With what help will he find the right one? How does it separate what it needs from what it doesn't need?
Mimicking User Story
Although the format of User Story is observed, but without immersion and additional questions in the work we do not accept. Digging, looking for the roots of the problem. Ask open questions, use 5 Why. Over time, we recognize the root of the problem and write it to User Story:
I am a corporate client
I don't know what the score is and I'm going down because of it.
I want to...
So that...
That's better, because we figured out where the button solution with the download of the report came from. Now we know that the client loses money if he doesn't receive his account information promptly.
The next step is to understand how we are going to change the life of a corporate client to solve this problem. Gojko Adzic in the book Quick Ideas To Improve Your User Stories points out that it is better to register a delta in the User Story between how the user lived before the release and how he will heal after the release. We get such a story:
I am a corporate client
I don't know what the score is and I'm going down because of it.
I want to stop the job if the balance is critically low.
In order not to lose money.
We will stop the user's work and spend money when the balance becomes negative. When we voice an offer to users, they don't believe that they can automatically stop working. For the user, the pain of the loss of money is so great that they have come up with the idea of downloading the report themselves, they are ready to look into the report, look for an answer to the question about the negative balance.
In the latest version of User Story, the button solution is gone. A root issue has been dug up. A solution has been proposed that will close the root problem. There is a chance to do some good after the release instead of adding another button to download another report.
Premature solutions
Some people have a way of making a decision. It's like they're playing their game or Brain Ring. They are waiting for a question and offer a solution for speed.
Hurriedly, there is a blind spot between the problem and the idea. Chain of reasoning and conclusions is left behind:
We do not make one decision, we dig the root of the problem, we identify the actors. After paving the way for the target, the actors and the root of the problem, the button solution loses its former strength:
Seeing the root problem or need, we throw in a lot of possible solutions:
Note that the choice is now visible, but the choice is more difficult to make. I have an assumption 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 solution, the pros and cons, the work is added. Besides, the wider the choice, the less the joy of the final decision is.
Deep drilling of the problem is costly, nobody tries to get into this swamp. But if we create a useful solution, we overpower ourselves and reveal the blind spot.
To be continued on the next part