One year as a Product Manager
A year ago, I joined Listminut — renamed Ring Twice since then — and took on a new role: Product Manager. Until that moment, I always worked on the agency side, and I felt the need to take on more responsibilities and move toward an in-house job in a Product company. From the moment I started, two things were certain: I had zero experience as a product manager, and I was going to face a ton of challenges along the way. The first year confirmed how good that prediction was.
One of the first things I did in my first days was to go around everyone to understand what was working well, what was not, and what was creating frustration in the team... For example, a recurring problem on projects was never knowing what the latest version of a document was, not knowing who had this latest version, etc. The first change made was, therefore, to switch to a more modern stack of tools built for collaboration. Exit .docx documents, Exit Photoshop... and hello Dropbox Paper and Figma. We also started using an issue-tracking tool — We chose Height for its high flexibility to fit our startup's evolving process and — to follow up on bug reports and improvement requests.
For every newcomer at Listminut, the onboarding process is designed so people gradually work on larger projects. After a few weeks, the first “real” big project I worked on has been a disastrous failure at the moment. I think I made all of the possible mistakes I could have made:
- Firstly, the team gave me their full trust from the start, an almost blind trust. The co-founders could for the first time no longer be in charge of the product. Wanting to do well, and to underline their confidence, they did not look over my shoulder and did not challenge me enough. And boosted by this confidence, I did not communicate enough with them to take the pulse or to ask for feedback.
- Second, the goal of the project was to improve the experience of a small portion of our users who were using a particular feature. With the overflowing enthusiasm I had as a rookie, I didn't realize that the improvements I was making were negatively degrading all other users. To give a few users a little more control, the solution I was creating added friction by forcing everyone else to do more interactions.
- Third, I wanted to solve too many things at once. As a designer (I consider myself a designer at the core), we generally like to see all the problems and take into account all the constraints to define a solution. I took too many things into account, even hypothetical constraints that “could happen”.
Baby P.M. believed he could manage everything by himself - Fourth, our designer didn't know Figma yet, and I wanted to use the project as a case to convince him to use it, so I kept control of the whole process: I was defining the problem, doing the research, and designing the solution, prototyping, doing the visual design — for both pour website and mobile app — while also creating in Figma the basic components in what would eventually become our Design System.
- Fifth, I spent a tremendous amount of time on this project. So busy with my new tasks and my desire to define the smallest details of the project, I quickly became a bottleneck for the developers who were waiting for the project. It was the first time in the history of Listminut that the developers had nothing ready to work with.
- Finally, once ready, the project was so big that it kept our developers busy for several months, plus a few more weeks for the many modifications that had to be made later when it became clear that the solution was not good enough.
This project, called "RAA" internally, was by far the worst but also the most formative. Paradoxically, if I had to do it again, I'm not sure I would do it differently. I have the feeling that I will have made all these mistakes, sooner or later, on other projects and that it helped me realize very early on a lot of things that should be taken care of from now on.
One important lesson I learned with the "RAA" project was the challenge of having a balance between 3 things:
- The desire to create a product with a top-tier UX
- The company strategy, which implies choosing what problem to address and how to scope the solutions well to have the desired impact
- The availability of the teams, especially engineers, who were understaffed.
I find that balancing act incredibly difficult, and I am still not completely comfortable with all the underlying mechanics. It's not an exact science, different team members will often have different perspectives.
Any desire you might have to create something or change something must be well-studied, discussed, and calibrated. For example, a feature I'd like to build to boost activation is an in-app notification system. Today we're relying too much on emails and pop-ups to communicate with our users. Creating such a feature could help reduce the frequent situations where several banners and/or pop-ups are competing for users' attention on the same page, but it's also likely that would be a big project to develop and maintain and it's probably not the best neither to move forward along our current strategy. Having a company culture where communication is key and everyone is accountable helps tremendously.
The role of a Product Manager itself is also comparable to a balancing act. From the beginning and up until now, it was difficult to define what exactly that role at Listminut would correspond to and how its responsibilities previously shared between the other people on the team would be redistributed and redefined.
In a "Product" scale-up in hyper-growth with tens/hundreds of employees, we generally find the same type of organization: Small teams — called Squads — of 7–8 multi-disciplinary profiles (a product manager, a product designer, a data analyst, and multiple developers…). Apart from those people, several other profiles could overlap such as “Product Owner”, “Design Manager”, “Head of Product”, you name it… At Listminut, although the team has doubled in size this year, we are not yet at the hyper-growth stage and we are not yet in this configuration of squads. It is therefore necessary to be able to wear several hats.
I do the very "operational" tasks that are generally carried out by a Product owner (write briefs, test new features, document things, communicate with the devs, etc.), more tactical tasks (create a product process, test new ways of doing things and tools all the time, question everything) and I also participate in strategic tasks that are generally carried out by our three co-founders. I also, more often than I should do now, find myself designing screens to fill gaps.
Before joining the team, I was very apprehensive about the relationship I would have with the only designer. I knew we had two different designer profiles (he is more into UI and front-end, and I'm more into UX). I wanted to avoid being the 'new sheriff in town', revolutionizing and changing a lot of things, but I also wanted to have a certain degree of control over the direction that would be taken for the design of our applications. In the beginning, on some projects, there was a bit of friction — and even some small clashes — between us. I was really struggling to find the balance between challenging his work and imposing the direction I wanted to take. Over time, we worked on that, by better defining who was responsible for what and by challenging each other. I still do a lot of design tasks (prototyping, thinking about systems, and a bit of visual design, especially for our Mobile app), but I learned to let go and trust more. We are now much better aligned, and our relationship has become great.
The way I imagine the future is to gradually delegate the UX side to a product designer (or should I call it a UX designer?). I guess it would allow me to free up time to do things that we currently don't do enough or to do them better: user testing, improving velocity, helping align the growing team towards clear common objectives, better qualifying potential projects to have a more predictable/significant impact on the business…
My role is difficult to put in a box because it evolves every day. I mentally picture my role as one of the people who must help the team grow in terms of product maturity, which obviously involves learning myself and then spreading what I have learned.
To conclude and give my feelings about this first year, deciding to join a startup-scaleup like Listminut was clearly a winning decision. It's not a super easy job because a lot is expected from me, the bar is set high and it's my responsibility when anything product related goes wrong, but it's a great job where I never get bored. I go all day long through a lot of diametrically opposed feelings and states of mind. For those who enjoy moving outside of their comfort zone, playing with lots of problems, testing things, and learning, it's a really great position. I am confident that during the next year, I will do lots of things that I don't do yet, I will continue to learn, a ton, and I will have helped the team move toward our next objectives.
