How to Create Better Alignment Between Product Managers & Product Designers
One of the fundamental problems people who work together have is miscommunication. Many times, while working with a Product Manager or seeing one of my Designers working on a project, I noticed that there is a big gap between how the Product Manager sees, thinks, and explains the project and how the Designer understands it. A written, well-defined, and cohesive description of the project will always be helpful for both sides. Product Managers will be able to clearly define and explain what they have in mind and what they want to achieve, and Product Designers will have a better understanding of what the project is all about and what is the problem they need to solve.
It starts with documentation
At Fiverr, we use something called “The 6Qs” which is loosely based on the Five Ws (or Six Ws). This document helps us define the project and realize better alignment and agreement across the team about what we are trying to achieve before we even start designing or developing a single pixel. The team will also go back to it while working on the project to see we are not getting too far away from what we defined. If we do, the 6Qs should be updated and the team needs to be synced so everyone will know about these changes.
If needed, I might also ask my Designers to fill the 6Qs document themselves (if they do not get one from the PM) according to what they understand from the conversation they had with the PM and send it to them, just to make sure they understand each other or to better define the goal of the project.
Although these six questions are pretty simple and straight-forward, it is not always so easy to answer them. If the reason for starting this project is unclear, or if we are already coming with a pre-defined solution, it will become obvious when you will try to answer them. There are also a few things you will need to be aware of and keep in mind while answering the 6Qs.
1st Question: What is the problem/opportunity?
This is the first and also the most important question. If you cannot define the problem correctly, it does not matter how talented your team is or how useful and beautiful the design and experience are. If it does not solve the user’s problem nothing else really matters. There are a few things you need to keep in mind while writing the problem/opportunity definition.
- The problem definition should be short. Avoid bullets and multiple goals. If you find you have multiple problems, it might be a good idea to separate them into several 6Qs documents.
- Your problem might be a symptom of a bigger problem. That is okay as long as you and the team are aware of that and understand you are not solving the main and bigger problem (a good way to test if you are solving the root problem is the 5 whys).
- Following the previous point, sometimes you will solve the source problem and other problems will be solved following that. In that case, it is recommended to add them to the 6Qs (under the main problem section).
- Be careful of suggesting solutions at this phase. The 6Qs as a whole, and this specific question, are just the groundwork that will allow you and your team to come up with great solutions for the project.
- The problem you define needs to be specific and not generic, it will usually focus on the user.
Generic problems might be:
“We need a better conversion rate.” (A better conversion rate might be the outcome of a successful project, and it is a general goal for your business, but it is not the problem.)
“We want people to click that, but they don’t.” (This is not a problem, this is just something your business wants people to do.)
Specific problems might be:
“People do not understand how our product works” or, “People have a hard time choosing the right service for themselves.”
Sometimes the focus of the project is not a problem, we might have an opportunity we want to push forward, or our project might be an enabler for other teams. In these cases, we might want to use the first question to describe the goal or use it as an intro for our project.
2nd Question: What data supports this?
This might include any kind of data that will help us verify the problem. The Number of conversion rates, click-through rates, retention, bounce rates, specific events, usability testing, interviews, and anything else that might be helpful in getting a good perspective on the problem.
3rd Question: What is our hypothesis? (If we do X then Y will happen)
This should describe what our users will do when they see the changes we have made. This section is mainly about the user’s behavior and thoughts. This part will not define the solution, it will just draw some general lines of what we think might help the users and solve their problems.
For example:
The Problem: “People have a hard time choosing the right service for themselves.”
A hypothesis might be: “Displaying relevant data next to the service will help users easily choose the relevant services for them.”
Critical thinking of the suggested solutions: like what this data is, how it is going to be presented, which users will see what, what might be relevant for our users, should it will be affected by the filters the user use, and all kinds of other questions will be referred to during the solution phase (after the 6Qs).
4th Question: What will be the impact?
This part should define the metrics you are going to use when measuring the outcome of the project. Popular KPIs are Conversion, Retention, CTR (Click-Through Rate); but it also might be UX-related, like Time on Task or Task Success rate. It is important to define that question and also realize that not everything always reflects direct conversion (although, at the end of the
day, this is what we want). It might be a lifetime value KPI for a user that had a good experience and will be coming back in three months to make a purchase.
5th Question: Who is it for?
For us at Fiverr, it might be a Seller or a Buyer (we also have different segmentation for them), it also might be a specific Persona. This step is really important, especially if you have a really specific target audience. Once you know the type of user that will use your product or feature it, it will be much easier to make a decision on what type of solution you want to create and to
make a good connection between the mental model of the user and the conceptual model of your solution.
6th Question: How will you measure success?
This part relates to the 4th question, and it is mostly about the numbers. If you defined more conversion as your KPI how much more conversion will make this test a success?
Conclusion
That’s it! Now that we are all aligned on what the problem is, it is time to start thinking about different solutions and approaches (the 6Qs might, and likely will, be updated after we do some research or get some feedback from users), doing some visual research, reading some articles, wireframe potential solutions, prototyping, testing them, changing them, designing, developing,
and A/B testing them to see if we solved our user’s problem. If we do not, we will start all over again, focusing first and foremost on the problem.
—
This article was created with the help of Fiverr Sellers:
nahuelbardi (illustration) & Maddisont (Proofreading).
