The work of Product Manager involves the continuous generation of solutions. When the problem of the target audience is identified, and the goal is set for the future product (or part of it), it is time to come up with an implementation that will successfully solve this problem for the user.
How is the decision making process usually going? Having worked on product positions in a wide variety of companies: from micro-startups to the colossal size of corporations, I noticed that most often teams use one of two approaches.
1.Collective discussion. Participants gather in a meeting room, one goes to the marker board, and the discussion begins:
“And what would we like to do?” “I suggest that the user can definitely log in via social networks!” “Be sure to ask the phone!” “Let’s make cool animations!” Such meetings can go on for hours. The output usually turns out to be only a small part of what is planned.
Frequent scenario: 2/3 of the meetings go into discussion 25% of the plans. Then everyone understands that a lot of time has passed, and nothing has been done, and the remaining cases run through the express train without diving deep into them.
This approach is not effective, because, firstly, the uneven depth of the task is obtained (from the beginning of the meeting to the end), and secondly, it takes a lot of time.
In addition, the low effectiveness of brainstorming and group meetings has been scientifically proven. Back in 1958, scientists from Yale University conducted a series of experiments, which showed that the quantity and quality of ideas achieved through the “brain storm” is lower than if people thought alone.
2. Delegation. The task is given to the designer, who immediately renders it in the UI, based on the data that he has.
Further, PO accepts the work, “fully trusting the professional”, and the task goes into development.
This approach takes less time, but is still lacking in depth. Product tasks should not be decided by a designer, but by a UX expert, whose role can sometimes be played by both a product and a group that includes a product, researcher, designers and analysts.
This solution is surprising in its simplicity and logic, which will save a lot of time on meaningless disputes, without losing depth and quality.
The essence of the method is to explain to the team the task and ask everyone to spend 5-10 minutes on sketching – simple sketches of a future solution on paper.
The process takes place cyclically in 1-2 circles.
Step 1. 7-15 minutes. Explain to the team the goal and tasks that are solved by the product.
This is the most important step since it depends on how much the invented solutions will be “down to earth”.
There must be a person at the meeting who will take on the role of a facilitator. He should tell us in simple and understandable terms what problem we are solving and why. If he has user research data, then it will not be superfluous to spend 10 minutes demonstrating them.
After the story, the team will ask clarifying questions, and after 15 minutes from the start of the meeting, all those present will have a single vision of why this process has been started.
Step 2.5. 5-10 minutes. Sketching.
Each team member takes a piece of paper (at least A4) and markers, and begins to sketch out his solution. Sketching happens in complete silence. Any questions that arise may be asked later. Now everyone is working, based only on the information received before this and their own experience.
Of course, in order to make a sketch, you do not need to be a designer. These are the simplest interface elements drawn on paper in as much detail as a 10-minute limit allows.
A sketch can be a single screen interface of a site / application, or their sequence. There is no framework here, on the contrary – the less limited the participant will be, the more creative decisions can be obtained at the exit.
After 10 minutes, each member of the team will have several pieces of paper with his solution.
Step 3. 5-10 minutes. Presentations
Each should, within no more than 2 minutes, talk about the concept of his decision: what is his foundation, why he chose these or those elements, why he came to this sequence of actions.
After the story, participants can ask questions for another 1-2 minutes. Important: this is not criticism or discussion, it is only leading questions, so that everyone can better understand the intent of the author of the solution.
After all the participants talked about their decisions, another round of sketching is carried out.
Step 4. 5-10 minutes. Sketching (round 2).
Everything is repeated, only now the participants have already seen the suggestions of colleagues, have taken sound thoughts and will improve their options. Someone can make a completely new option – it’s not scary.
Step 5. 5-10 minutes. Presentations (round 2).
The same as last time. Now the time for each presentation is limited to 60 seconds. Again, no discussion, only questions for understanding.
Step 6. 7-10 minutes.
Development of a single concept. The facilitator, standing at the blackboard, draws the target solution, which is based on all the discussions that took place. As a rule, this stage passes quickly and without much discussion, because all questions have already been answered before this.
Team members can actively comment – this only helps the process.
Step 7. Finish.
After only 1-2 hours, the team has a well-developed UX of the future solution. It takes into account the opinions and experience of several professionals.
If the subject of the meeting is a large piece of functionality or a completely new product, then I usually remove the 2nd round of sketching and presentations. So it is possible to work out 3-4 large independent parts of the product in 2 hours.
Steps 8.9 … Prototyping and testing.
What to do next with the resulting sketches, every product specialist knows. In my practice, most often I give sketches to the designer so that he builds a clickable prototype from them.
Subsequently, it will be tested on clients to identify the most obvious UX errors. Then, after troubleshooting, you can move on to the UI, new tests, and, finally, transfer to development.
Thus, in one meeting in a length of 1-2 hours, you can deeply work out a solution to the user’s problem without slipping into a booth and arguing, and improving the quality of the result.
The “silent sketching” approach can be used in any product tasks, and not only in IT products. The GV team advises dozens of portfolio companies that create, including robots, coffee houses, shops, etc. And everywhere he uses the same methodology – SPRINT, of which sketching is a part.
I personally noticed a significant jump in the speed and quality of working out product hypotheses after I began to use this method in my projects.
And how do you generate solutions?
P.S. SPRINT authors call the methodology “Working alone together” and recommend spending hours sketching. This is acceptable in the framework of SPRINT, but for everyday product tasks, the option with short iterations, which I described above, is suitable.
If you find a typo, select it and press Ctrl + Enter! To contact us, you can use email@example.com.