What you'll learn
- The challenges of scaling alignment in a hypergrowth organization
- How product teams uses Claap to improve alignment & decision-making
- Qonto’s best practices in implementing Claap to review concept papers, design reviews, QA, bug reports and training
Building the new dashboard is a complex feature. It's a complete redesign, super complex. And that was really when I saw the first comments added to my recording. And the fact that it generated enthusiasm in the team. People really got excited to write comments on the video, so I was like “Ok, this is dope”.
Hey Thomas! So, to begin with, can you tell us a little bit more about your role at Qonto and your big challenges today?
Sure. I'm a product manager at Qonto. In the product team, we are about 100 people, we are 40 product managers. The rest of the team are designers and UX writers who help us think about the interface and the messages we want to convey in the product.
I work on two different scopes. The Cash Flow Management vertical and the Integrations one — how Qonto integrates with other tools, like accounting integrations, for example.
Qonto is a financial solution for freelancers, micro-businesses, but also SMEs with up to 250 people.
The majority of our clients are solos and micros: 95% of our clients have less than ten people in their company.
Our biggest challenge as a company now is to scale as fast as possible.
We've already grown a lot, but since the latest fundraising in January, we need to double the number of PMs by the end of the year and quadruple it by 2024.
The big challenge is how to easily onboard new people and keep the alignment we had when we were much less. How to make sure that when we present a topic, we align all key stakeholders.
When I propose a new feature that addresses a specific user problem, I want to get feedback as quickly as possible without taking too much time for stakeholders. At the same time, it’s important for me to make sure that they’re in the loop very early so that I can incorporate their feedback on time.
And what are those stakeholders you need to align with?
The 2 main stakeholders I need to align with are the Head of Product and our Chief Product Officer. Decisions with the design team happen at the squad level. Designers themselves have challenges with their own Head of Design.
I'm the feature owner, I’m responsible for the whole topic. I need to have everyone's approval, or at least I need to prove that I have taken into account the feedback from my stakeholders.
Decisions are not top-down in general. They must come from user research, competition analysis, etc… That being said, it's not because we have a vision that it’s not going to be challenged by people with a different point of view or context.
I'm actually quite curious about these moments of alignment. Have you ever structured some decision gates in your product development cycle? How does that work in practice?
Well, in fact, it's a big topic that has evolved quite a bit in the past few months, in particular thanks to Claap.
What we did before was structured in different phases at Qonto.
The first phase is called value analysis: understanding the problem.
What are my users telling me? What is the state of the business? What are our competitors doing? What problems do we want to solve? What are the user stories I need to work on? What are my constraints? How much time do I need to work on the topic?
That's what we generally call a concept paper. We have the first review here.
It was a bit painful before. Concept papers are quite long written documents. Even if we try to make them digestible for our stakeholders, we’ve worked so hard on it, we’ve done so many interviews and analysis that it still remains pretty long and tedious. And it takes time for stakeholders to review it.
Now we're doing a voice-over on Claap. Recently, I worked on a complex topic of cash management. It was really complex as we were working on two features that were potentially linked one to another. So we had to figure out how to make it work. I wanted to get feedback from my stakeholders, so I wrote my concept paper and I did a little six-minute voiceover where I showed them the key points and the key decisions I intended to make. And it's great because with Claap it's super easy for my stakeholders to stop the video, and say: "Ok aligned with what you’re saying, but be careful, think about this, think about that.” It's really very convenient.
This is usually where we have the first point of discussion.
Then we have a phase called “value engineering” where we work closely with the engineering team.
We’ve already pushed a sort of global vision with our user stories, with our constraints, but we haven't yet confronted it with the technical side. The goal of value engineering is to make sure that what we propose will be feasible in the allotted time. To also bring out new solutions that can emerge. They can come from the tech themselves because they have thought about the problem differently.
And ultimately the result of that is a prototype.
It's also a moment when we're going to record a claap. We're going to present the prototype to get feedback by saying: "Well, we shared the claap with the concept paper. We had received feedback. We challenged it with the tech team. Here is our preferred solution. This is what the prototype looks like." It helps us collect feedback and if it's OK, there are only small adjustments. We validate and we go to the spec phase.
Super clear. Do you also need to validate your product spec the same way?
No, because the specs are actually the results of the value engineering phase. If we all agreed before, the spec is just "I'm summarizing what we agreed on".
I see. It’s like your contract.
The contract, yeah, that's it. Thanks to Claap, we have the contract validated before writing it.
OK, so in fact, your validation has two steps: your concept brief or concept paper which is validated twice: once by the Head of Product/CPO and then challenged by the others.
It happens at the same time! They’re watching the same recording and adding comments on it. No need to do it twice and it facilitates alignment.
Concretely, what are the biggest benefits compared to what you did before?
The quality of feedback and alignment.
Before we didn’t have feedback all the time on documents. That was really hard to force people to give you feedback on a long document. Sometimes it was a little superficial.
Now it’s much faster. Video allows you to quickly explain the point. Now I make the effort to highlight the most important points where I need feedback. I know that my stakeholders can focus on giving feedback where I expect it. And if he wants more details, he can still jump and read the doc. Before that was pretty hard to ensure I had input on the most important topics.
So from your point of view, it’s really the number and quality of feedback you received that changed with this system.
Yes exactly. And in the end, it enforces the culture of feedback that we already had at Qonto.
At Qonto, we have no problem saying that we disagree on certain things. We need to be very solid about why we do things, always giving arguments, pros & cons, and documenting them.
Before, as it was really hard to maintain all stakeholders in the loop, we sometimes had to backtrack on some things that we were doing.
We’re now able to switch to a more preventive model where all stakeholders are in the loop early on. That allows you not to defocus the teams that are building new features. We can move faster as we know we already had the feedback we were expecting.
Ok. I imagine that in the end, you’re able to increase both product quality and velocity?
Super insightful. And regarding other use cases, you briefly mentioned the design review part. How does it work concretely? Are you in charge of that? or is it product designers?
It can be both. More and more, designers record claap themselves, but in the beginning, I presented the prototypes myself. There isn't necessarily a rule, but more and more, it's the designers who do it and who are a bit the owners of the solution in the end. And we apply the same principles: we challenge ourselves, we take into account the constraints and, before starting to build, we want to make sure that everyone is aligned. And if we have the GO from everyone, then let's go.
OK. How did it work before? Did you have to schedule a meeting?
We indeed could schedule meetings and it's true that it took a lot of time. In fact, we presented the prototype live and received feedback live, which was quite painful because you have to present and receive feedback at the same time, which is not always easy.Sometimes it was actually just: I post the prototype in Slack and ping my CPO. I would tell him: "Happy to get your feedback" and sometimes I didn't have his answers because of Slack message overload.
Yeah receiving a design without context, it's still very hard to give feedback.
Yes! There is no voiceover. There is no context. And we don't know why the choices were made like that. When we have a voiceover, we can say: "OK, this is happening because we chose to put the button like this, because X at this stage did this, because Y..."
Super clear. And are there any other use cases where you also use Claap for?
To do all my QA feedback. For bug reporting in fact. I am on technical topics like API, but as soon as there is something wrong with the interface, I don’t need to take a screenshot with a long description. I just write: "I connect to this environment with this user and then it's a video where I show what’s happening.” I open my console if necessary and I just take a claap and, as soon as I spot an unexpected behavior, I select the part of the screen which is buggy and I explain. I highlight the bug.
And you already mentioned some features a bit. What are the features of Claap that are key for you? And, on top of that, if you could also explain the benefits.
I find that the Chrome plugin is very easily accessible. It's super clear, it starts very quickly. I had a lot of problems with installing the Loom plugin before, which I found really annoying. I don't even know what it looks like anymore because as soon as I switched to Claap, I stopped using Loom. In terms of functionality, what I find really good is controlling the video speed and being able to pause and select a part of the screen to make a comment on a dedicated area.
I admit that I haven’t used a lot the polls yet.
The integration with Slack is also pretty good. Before that, I used to receive too many emails with notifications.
Now at least I can choose and easily check-in Slack without being spammed. That's great.
What else? The creation of topics.
Who is using Claap today? And what are the biggest benefits of the solution?
In terms of usage, there are really more and more users. There are designers, there are product marketing managers and product managers like me.
Oh! And there's one use case that I haven't mentioned: user interviews. I record all user interviews on Claap, just because I find it cool to be able to centralize all my videos in one place. I think the entire product team uses it.
The growth team is also using it quite a lot I think but I don’t have a lot of details.
Tech people also use it quite a lot but mostly as contributors. They can save a lot of time for issue resolution.
The biggest benefit is definitely time-saving. Instead of reading a 10-page concept paper, people just need to watch a 6-min video that highlights the key things to validate.
And when was your first "Aha" moment using Claap?
This is the first Dashboard prototype I had to present. Building the new dashboard is a complex feature. It's a complete redesign, super complex. And that was really when I saw the first comments added to my recording. And the fact that it generated enthusiasm in the team. People really got excited to write comments on the video, so I was like “Ok, this is dope”.
Ok. Did you have to explain to your teammates that they could leave comments?
At Qonto we put a lot of comments on everything. When someone is asking for a review, there is in general a lot of comments. We have this culture of feedback. We’re not afraid to say: "There is a problem here." We don't hesitate to comment and say: "Ah, I don't think that's good etc." As a result of this culture, all I had to do was to say: "You can leave comments on the video” ...and there were comments.
How do you see Claap evolving at Qonto? Do you have other use cases in mind?
I would say for training as well. If we take the release of our new dashboard, for example, I will have to prepare some training material, to make sure people are able to explain how the dashboard works, etc… In general, that’s at least 30min of training per team. So my plan is to record the course of Claap so that people access it whenever they need it and comment if there’s anything unclear.
Yes, it's indeed a pretty common use case. We are coming to the end. Anything else you wanted to mention?
No specific comments. I really use Claap all the time. Even earlier, I was asking a software engineer to do something. He told me: "it's done" and I didn't understand. When I looked, it didn’t work. So I sent him a claap. For me, it has become natural to record claaps for everything. And I think I'll end up discovering more and more use cases. Going through a claap can really save us time. Great product!
Okay, so cool! That's all for me. Thank you very much Thomas!
Resources to help you get started
If you loved reading this article and want now to implement those best practices in your own company, here are a few good playbooks to start: