Who should you have in the Product team so as not to worry about KPIs?
In my opinion, the key to the creation of an effective team is the cooperation of people with different competencies and temperaments — people who ensure the right balance between being “YOLO” and being 100% data-driven.
I want to answer the title question by referring to the experience gained in my “Patient Bookings” team at Docplanner. Our goal is to help patients find the right doctor and book an appointment online. Increasing conversion rates show that we are meeting our goal quite well.
I would also like to use some examples from the Star Trek TV series, which is my lifelong and professional inspiration :). But enough of this introduction. In my opinion, in your team:
You should have someone who can evoke emotions
The easiest way to get your team involved is to show that planned product changes will help your users. Therefore, first, you need to learn about the real needs and problems of the users. A good Researcher can help you with this, as he knows how to plan and conduct a relevant study. But having right insights is not enough. You need someone who will present the collected use cases to the team convincingly. Someone who will help them understand that insights, feel them. A Researcher or a Product Manager can do this. The involvement of your team members (including developers) in usability tests is also a fantastic idea. They can be observers, take notes. I remember when, after one of the refinements where we tried to find a solution to the problem of SMS delivery from LATAM countries, Kamil (one of our developers) sent us the following message:
It is hard to imagine a more proactive attitude. The solution invented by Kamil on the train allowed us to improve the overall conversion by 5%.
You should have someone who can turn emotions off
The problem is that making decisions based solely qualitative research and fiery speeches of a Product Manager, you can get yourself into stupid projects. To minimize this risk, you need to have a Product Analyst on board — a kind of a team’s Spock. A person, like Ania from my team, who can brazenly interrupt your passionate speech and say: “Nice idea, but it won’t bring us closer to achieving our quarterly goal. So, are we changing the goal or the idea?” Another time she can ask: “What data are you looking at? (…) Well, here you have forgotten that we are still counting (…), so you should not draw conclusions on this basis. I would instead look at this table…” And here, we also have to come back to Product Managers. They should be humble, able to accept rational arguments, and admit their mistakes. They do not have to (or even should) be a slave to data (or Spock), but to seriously consider the Analyst’s arguments and take them into account when deciding on the tasks that the team should undertake.
You should have someone who can be carried away by imagination
A good Product Designer should have such a trait. I remember one of the changes in the product that we had to make at the request of our Chief Security Officer. It regarded changing the validation of passwords that users must set. From now on, passwords had to be more complex. We wondered how much the conversion would decrease when we would introduce this change. However, Patryk, our Product Designer, prepared an interface that clearly and engagingly explained how and why our users should set a strong password. Thanks to this creative approach to such a seemingly standard change, conversions did not drop, and our CSO summarized our mini project like this:
You should have someone who can make things happen
I know that there are well-organized Product Managers. I even know them and work with them. However, I am not like that. I’m always late. I still have many unfinished threads. It’s not only because I’m absent-minded but also because of the scale of our product; we are working on a global healthcare product. In each country, we need to pay attention not only to cultural or linguistic, but also legal differences. If I devoted 100% of myself differences in countries, I wouldn’t have time for user research, strategic planning, and team management. Thank God that I have a Project Manager, namely Dani, who is the engine of our team and tirelessly makes the wheels of the train called “Patient Bookings” spin. Project manager works closely with developers, analyst, designer and product experts in countries where we introduce changes. He supports communication and makes things happen. Of course, it also has a big impact on the product. Like any team member, he can suggest changes at any time, and he makes smaller implementation decisions alone. He is like Captain Picard’s first officer, William Riker.
You should have someone who doesn’t know that something cannot be done
One time, based on the analysis of our users’ behavior on the site, we noticed that modals with extensive content are not intuitive enough. Our Product Designer had prepared a solution with a CTA button fixed to the bottom edge. I told Monika, our, Junior Frontend Developer (at the time), about it and asked her to check this out. A moment later, in the kitchen, I came across Michał, our Frontend Team Lead. Michał told me that they had tried to implement such a thing a few times, and they failed, so we should look for another solution. When I got back to the desk discouraged, it turned out that Monika had already encoded this feature. She didn’t know it couldn’t be done. And what is interesting, Michał liked her solution and gave his approval within the “code review”. I believe that such developers with a fresh mind are needed in every product team.
You should have someone who can keep your product from falling apart when you try to expand it
In opposition to the above, you also need experienced people who know the code thoroughly and have a vision that goes beyond “from feature to feature.” Such experienced developers ensure that the product is developed and does not generate millions of bugs that will paralyze the project in the long run. It is essential, however, that these people are not just blockers. Our CTO once told me that, from Senior Developers, he expects the attitude usually presented by Scotty, the chief USS Enterprise mechanic in Star Trek. To better illustrate this, have a look on the one of the dialogs between Scotty and captain Kirk
“How long to re-fit?” — Kirk
“Eight weeks. But you don’t have eight weeks, so I’ll do it for you in two.” — Scotty
“Do you always multiply your repair estimates by a factor of four?” — Kirk
“How else to maintain my reputation as a miracle worker?” — Scotty
“Your reputation is safe with me.” — Kirk
It reminds me of my first tasks estimations with Bartek, our Senior Backend Developer, when I joined Docplanner. At first it drove me crazy, but over time I began to appreciate it. Thanks to this way of estimating tasks, our sprints were not overloaded and we avoided many fuckups.
You should have someone who can make people feel good about each other
As you may have noticed, I built most of the above examples on the principle of opposites. So, it’s only natural that tensions, frustrations, and conflicts arise in the team. Therefore, you need someone who can be like Deanna Troi, half-human, half-Betazoid (Betazoids are famous for their amazing telepathic abilities and sense the emotions of others). Deanna is an advisor to Captain Picard, whose empathic skills are limited, to say the least. It is really important to recognize, acknowledge, and resolve conflicts in time. You need to talk a lot so that everyone can present their arguments and feel heard. In our case, this role is most often performed by the Product Manager himself (people with low levels of empathy are not taken into account during the recruitment process). I can imagine, however, that the role of a Betazoid can be fulfilled by a Scrum Master or some other person in the team.
If you are afraid that you have to recruit new people to build your Star Trek crew — don’t be. Get to know your current team. You might be surprised with the outcome :) Some people in your team may convey more than one of the traits. It’s not that you have to have one person per trait. You can also ask for help from members of other teams to support you in areas where you lack competence. What do you think? Share your opinions in the comments.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
