Asking the Product Manager the Right Questions
Hi everyone! My name is Bogdan, I work as an internal product designer at a company that connects clients with industry leaders through technology, and as a course reviewer “Web Designer” And “Interface Design” in Yandex Practicum. After five years of working in startups, I realized that the most interesting things are still ahead for us, designers. Artificial intelligence, virtual and augmented reality will change the approach to design, and high competition will force us to offer more innovative solutions – and all this, it seems to me, will make interfaces more complex.
More and more companies are realizing the importance of quality design and well-developed user experience. That’s why designers are more often faced with complex and intricate projects.
To do a good job, a designer must be able to ask the product manager the right questions. In this text, I will tell you about five important rules that help me prevent misunderstandings at the first stages of work, build communication and effectively solve specific design tasks.
Initial data
I will write about a real example that I encountered in a product company. The conditions were as follows: I had access to the product manager, users and the development team, and all participants were aware of what was happening with the project. Most likely, when working in a studio or on an outsourced basis, the questions and the order of actions will differ, but the principle is always the same.
Don't start work until you understand 100% what needs to be done.
So, our example. We coordinate work in the internal CRM system. Managers create projects, and experts from the internal database join these projects.
Over the years, thousands of projects have been created on the platform, many of which are similar to each other. Our task is to teach the system to search for similar projects using artificial intelligence in order to quickly find relevant experts based on past experience. The search should be launched after the creation of each project.
As you can see, the task is large and vague. It is unclear when the manager should see the interface of the new function, how exactly the system will identify the project as similar, how this task is solved today and whether it is solved at all – these are only a small part of the questions. To understand where to start, you need to answer each of them.
If you are a newbie and find yourself in a similar situation, don't panic – instead, use my list of questions and follow simple rules that will help you step by step analyze the goals and objectives of your project.
Rule #1: Study previous experience – first of all, your own
Your goal is to find out what is happening with the product now and how it has evolved, whether there are similar ones and how they are used. The product manager should know all the nuances and tell you about them. If you have not received complete information, you need to ask for it. Here are some questions to start with.
Perhaps somewhere in the product there is already a solution to the current problem hidden. Maybe it is poorly implemented, or maybe it is simply outdated and does not meet the current needs of users.
If so, we will have the opportunity to talk to previous users and learn from UX interviews what they are missing in this feature.
To create something new, you need to allocate more time for research, design, and development. It is important to warn the product manager about this. This is especially critical for the company's internal products, which are usually difficult (almost impossible) to find in the public domain. The narrower the company's area, the more difficult it is to find real examples of solving a similar problem.
It is not always possible to get such information right away, but it is worth looking for the main competitors. Even a screenshot on the company's website or a photo under a post on social networks can help.
It would be cool if you could see with your team how someone else solves a similar problem, what you like about this solution, what you don’t like, and why.
Rule #2: State what result you expect
If you were given a specific example or a similar product, great, it will make your work easier. But this happens very rarely (almost never).
If you are creating something new or radically improving and reworking an old product, it is important for you to know what the end result should be: what we want to give the user, how we are better than our competitors, and what benefit we see from the product for ourselves.
Ask your product manager the following questions.
Here it is important to focus not on a specific presentation (“here we will place a button, here a link, and here we will show a search result”), but on solving the user’s problem (“the manager sees that the new project is similar to the one we did two years ago”).
The answer to this question is based not on a detailed description of the feature interface, but on the logic and use case.
It is important to understand in advance how we will know whether we have managed to solve the user’s problem: what metrics we will introduce to measure their satisfaction and what criteria we will pay attention to.
In my example there are two such criteria:
the number of found projects that managers continue to work with, in relation to the total number of projects in the search results;
the time a user spends filtering out relevant projects.
During the work process, I conducted special UX tests, in which I measured the time from the moment the user opened the project until he made a verdict – is the project similar or not. After the release, we repeated the test and saw that more projects became relevant, and the decision-making time decreased.
One of the most voluminous and important points. When answering this question, you must carefully describe the mechanics of working with the product: what target audiences the feature has, when and how often they will use it, and what exceptions there are in certain scenarios.
When working on a large and complex product, not the entire result goes into production at once – usually the feature is developed and supplemented in stages. With this approach, it is better to start with the ideal final design version, and only then simplify it to the necessary iterations that will go into development. This way, you can think through the entire interface in advance and not redo it when it is time to add new features. Developers will be able to lay the foundation in the code for what will be completed later. And it will be convenient for users – they will not have to get used to a new design after each iteration.
Rule #3: Consider the interests of the business
If you work on a product, it means that the business needs it. The designer's job is to constantly find a balance between the needs of the employer and the user. Therefore, it is important for us to immediately understand how much we can “swing” in working on the current project. Do we have the time and resources to conduct UX research? Or is the main thing to do everything quickly and easily?
Ask the product manager:
Which features are most important for business purposes and why?
What metric is most important for us to improve?
What features are considered nice-to-have and how important is it to implement them?
Rule #4: Know the technical requirements
If you know what your team is capable of, that will be a plus. A product manager may not always be able to tell you the details of the technical limitations of a project, but often already understands what we can do and what we can’t, what solution would take too long to implement, and what could replace it.
You can clarify the following with him:
What devices do you need the feature for? Web, mobile, tablet?
Are there any technical limitations I should be aware of?
I also recommend finding out which development team will be working on the feature, and then calling them to talk about your vision and technical limitations. I can't tell you how helpful this is and how much time it saves.
Rule #5: Meet deadlines
To meet deadlines and not let the team down, it is also important to ask a few questions at the start:
When should the design be ready?
When does a feature go into production?
What is the priority for implementing a product or task?
If the feature is large and complex, agree on synchronization, for example, every three days. This way you can keep the manager informed of the work and be sure that you are moving in the right direction. This is much more effective than spending two weeks on work and then finding out that it is “absolutely not what is needed” and not meeting the deadline. And this happens – not even through the fault of the designer or manager, but because the requirements, restrictions or priorities have changed.
This is an example from my practice, and it is not universal. I am sure that over time you will make your own list of questions – and in the future it will be easier for you to create solutions that are not only aesthetically attractive, but also functional and convenient for users.
