CHRISTOPHE: 0:00

It's not a surprise that Odoo developers are the stars of the game. I think at Odoo we concentrate so much on the product that sometimes we even strive to have the product being able to sell itself. At Odoo, when we're working with the developers, they are the guys that actually make the product right.

OLIVIER: 0:17

Hi everyone, and welcome to this new episode of Planet Odoo. Today we decided to offer you the rebroadcasting of a live from our Twitch channel. This time you'll be able to hear the first part of our conversation. Ready? Let's go! So you can see that we're already ready for the match of this evening. Uh, and I have a bunch of supporters, uh, with me. And let me let me tell you just this one thing. Just this evening, just for this match, we will not support Ukraine. I think it's pretty clear, but we are not here to talk about football yet. We have to work before that. And, uh, I have here people to discuss about the way, uh. Well, functional people and technical people communicate and how we do that at Odoo and what our process is. But who are these people? Could you guys introduce yourself? Maybe. Who wants to start? You start?

MATHIEU: 1:04

Sure. Start. Um, so I'm mathieu, I'm the MRP product owner at Odoo. I've been at Odoo for almost six years now. Um. And. Yeah, happy to be here with you guys today.

LAURA: 1:16

Um, hello, I'm Laura, I'm Laura Bertrand, and I'm the product owner for accounting and expense application. And I've been working here for one year and eight months, to be precise. And, yeah, I'm glad to be here today with you.

OLIVIER: 1:29

You're already live on Twitch. What a career. Yeah.

LAURA: 1:33

Nice.

CHRISTOPHE: 1:35

Hello, everyone, I'm Christoph Klopfert. I'm also a product owner at accounting for. For accounting at Odoo. I'm working at Odoo for three years about now.

OLIVIER: 1:44

So as you can see, we have product owners with us. And so that brings a question. Uh, maybe not everybody knows what a product owner is. And maybe people think they know, but they don't know what a product owner at Odoo is. So could you guys explain what what is a a product owner? So a PO we will probably say PO multiple times during the episode. Forgive us. Uh, it's a product owner. What is that? Sure.

CHRISTOPHE: 2:09

So maybe I can start with that. Um, I think product owner is actually a position that is quite complicated to explain. Most of the time, everybody knows what a sales guy do. Everybody knows what a developer do, but what what is a product owner. And it gets exceedingly complicated when you have, you know, very known methodologies that give specific meaning to the word. Um, we at Odoo, so product owners, typical product owner, would actually make sure that we keep up with the market, that we give a vision, we give a direction to the developments that are going to be made in the context of specific applications. So Mathieu is doing MRP. We are doing it for accounting as well. Together, we also discussed that we align on most of the, you know, general stuff, but the base of our job is making sure that Odoo goes in the right direction, um, that we keep up with the market, that we actually push Odoo forward to make sure that we are always we try to be one step ahead of the competition and always provide the most up to date features that people love and that make actually their business work more efficiently. Because that's basically the the motto at Odoo. So I think that's the easiest part. And the most common part when we talk about product owners, is making sure the developments are made and are useful for the people that are using our software. I think maybe the variation, the slight twist that we have at Odoo is that we are not only just giving directions, we have also responsibilities in terms of project management. I think we're going to dive into more details later in the podcast, but...

OLIVIER: 4:01

I can already explain. Uh, sure. Give us the keys.

CHRISTOPHE: 4:05

We make the task we discuss with the developers that are doing them. We make sure they are doing it right. Um, we make sure they are delivered. We go up until the real delivery of the task. So we really working all the time with the developers. And so there's a there's a project management aspect to, to it. We make sure that the the task, um, we think are delivered at the right time and we make sure that they're working. We keep up with the follow up of those tasks. That is really a project management aspect to that, which is sometimes a bit different with the typical definition of a product owner.

OLIVIER: 4:47

Mhm mhm mhm. And so uh you have to interact a lot with the developers. Right. Uh would you say that I mean maybe we can make the role of the developer clearer, uh, in that, would you say that it works like, because you say everybody, it's clear to everybody what the developer does, but, uh, is it really, uh, because. Okay, uh, programming maybe not. Uh, isn't there in the. Because I have a feeling that in the way we are doing that the developer is doing more things than in more things than in most companies. Right.

CHRISTOPHE: 5:17

That's a great point, because I think you're absolutely right. Um, it's it's like it's not a surprise that Odoo developers are the stars of the game. Um, in many companies, you know, you will always have salespeople that are very important because they are what are the people that bring the money? I think at Odoo, we we concentrate so much on the products that sometimes we even strive to have the product being able to sell itself. You don't need a salesperson to sell a Microsoft office license. Everybody knows what it is, and if you need it, you buy it. You don't need a salesperson. We sometimes we I think we at Odoo, we aim at giving a product that actually is sometimes able to sell itself. For that, we concentrate a lot of efforts on the R&D part and on the product management. At Odoo, when we're working with the developers, they are the guys that actually make the product right. They are the guys that are making the code that we that implement the features that we think. But if it's not the right code, we never getting anywhere. So we need the great developers. And for that Odoo from the beginning invests a lot in recruiting the best developers that are exist on the market and the market in Belgium. I think it's even worse if we talk about other type of markets like the US. The market of actually hiring developers is really, really tough. Everybody needs the good developers, everybody needs them. So so it's actually hard to hire them. And so at Odoo, there's that famous anecdote that we give €10K to a developer that just signs at Odoo. Why? Because the market is so thin that you have all the head hunters there trying to get in the way of between, you know, companies that want to hire people and the people themselves.

OLIVIER: 7:05

So it's not as magic as it sounds, actually. It's it's like reinvesting the money that we would have spent on these exactly directly by giving it to the guy. Exactly.

CHRISTOPHE: 7:13

And so when we get those people and we know that we want to work with them and they are going to develop those features. We want to make sure that the guys actually own the task they are doing. And so. So yes, I think the developers at Odoo also sometimes discover that they have more power than what they think they do. They are not like mere executants of tasks where they receive like a huge specification and they just have to type the code that will actually render the result. No, we work with them, we give them an objective like a feature to implement, and we rely on them so they can develop it.

OLIVIER: 7:56

And of course, we'll dig into the details of how exactly this happens and what the the process if we even if we don't really like that word here. Uh, works and how. Yeah, the the magic happens. Uh, a maybe before doing that, uh, how do you become product owner? What kind of background do you guys have? Uh, I think it's interesting for what will follow. So, um, maybe maybe you to start, uh, how did you end up becoming a po?

LAURA: 8:24

Okay. Um, so I begin, I sorry, I started, um, I studied theory of business engineering at, uh, Solvay. So I don't come from an IT background, uh, like some product owners. And I did an option in finance, so not it. Even though I had, I mean, computer science course, I even had to develop some Python program, but I didn't know that. Yes. I never told you as well.

OLIVIER: 8:53

So we cannot lie to you. You already know everything.

LAURA: 8:55

It was a small group project. It was not something impressive like you do, but, uh, I had the basics. I would say, um, but my option was finance. So, uh, then I started my career in finance in Luxembourg. But I felt that I was lacking, uh, that my creative and management side was not, um, explored enough. So I wanted to to change. Uh, so then I did business analyst slash product owner in a life insurance company during three and life three and half years. And I really loved it actually to to start building a product from scratch and to be in collaboration with the, with the developer. And this is something I love about my about my job is that you you really answer business needs while taking into account UX and UI UI constraints. Uh, and collaborating with business stakeholders or developers and. Yeah, making something and making something. Yeah. Really? You you I don't know, you you feel like you are realizing something concrete and, um. Yeah, this is how I end up being a product owner.

OLIVIER: 10:08

That's a nice story. Mathieu.

MATHIEU: 10:11

Actually, for me, it's similar than, uh, Laura story. So for me, I studied engineering at university, and so mechanical engineering. So, uh, we had a lot of, uh, classes where we had to build, uh, things. So, um, build a 3D printer with, uh, some in one project, uh, or like some mechanical wrenches as well, things like that. So. But when I started working at Odoo actually, which was one of my first jobs, after a few internships, um, I actually started in sales. So I was selling the Odoo software in our direct sales department. It was really cool because I got to know a lot of projects. And, uh, after a while, I also, um, so I specialized a bit in the manufacturing inventory apps and so on. Um, and so one day, uh, I, I was offered the possibility to, to change jobs at, at Odoo. And so I decided to make that that big step and, uh, become a product owner for, uh, similar reasons to Laura. So, I mean, the fact of building, uh, things, uh, the fact of exploring also a bit of a technical aspect of the job was missing a bit, uh, for me, um, and, uh, yeah. So that's, uh, that's pretty much, uh, that's pretty much my story.

OLIVIER: 11:23

Okay. Stuff. Your story is a bit different, right?

CHRISTOPHE: 11:25

Um, yeah, I, I often call myself like a developer that deviated, you know, like that that worsened over the time. So I'm a developer at heart. I did civil engineering and informatics, so I started my career as a developer. But from the beginning, I was the type of developer that was more interested into the problems that we actually solve instead of the beauty of the solution itself. And so naturally, I think it's part of my skills to go more about making sure that we answer the needs, even 80%, but as quickly as possible, because for me, it has more value that to provide the most efficient SQL query you can ever build, which those guys we need as well. Don't don't don't get me wrong, it's not a judgment, but it's my skill set is more oriented at solving the issues. And so over the my career, I started to deviate more and more into the actually analyzing the problems and proposing solutions that would actually answer them, which leads to a position like product owner.

OLIVIER: 12:31

And so you knew nothing about accounting when you were hired.

CHRISTOPHE: 12:35

Don't don't tell that to me.

OLIVIER: 12:38

Because secrets.

CHRISTOPHE: 12:40

But yes.

OLIVIER: 12:42

Good.

CHRISTOPHE: 12:43

When I have accounting questions, I go to Laura to make sure that I, that I, that I'm right. But yes, I think it also brings value because I'm, I'm, it's not a requirement for me to do an to do to be an accountant, to provide an accounting software that answers the needs. And I think that's the business analysis part, which I.

OLIVIER: 13:02

Think it's it's very interesting indeed because, uh, uh, of course you need people with an actual background in accounting or knowing more what they're talking about. Uh, purely functionally. Yeah, it's better, but, uh, it's it's it's interesting to have people that are just there to solve the problems and to have also it allows having like a fresh view of the thing. And, uh, you know, sometimes people can be a bit, uh, dogmatic, if that's a word in English. Uh, on on on on what to do. Uh, because they always did it like that. Uh, and and and you come, you're like, hmm. I'm not sure. It's not sure. There isn't another way that is not easier, actually. Or cleaner. Uh, and that would fit better into Odoo for technical concerns. Uh, and I think for these guys, these kind of issues, it's really interesting to have more diversified, uh, people like you. Uh.

CHRISTOPHE: 13:52

I managed to learn accounting at the end, so of.

OLIVIER: 13:56

Course, but but.

CHRISTOPHE: 13:57

It's it's like accounting is actually a great example of that. Like one of the most the things that we repeat all the time at Odoo is we want to disrupt an industry like accounting is a what Napoleon old branch.

OLIVIER: 14:10

Sometimes it's closer to a religion than an industry. Exactly.

CHRISTOPHE: 14:14

And so, like having fresh views on how to optimize or maybe change a bit the way people are doing the accounting. Well, getting to the same results, because accounting is always controlled and you cannot mess with the end result. But sometimes we provide new type of solutions, of new features that are actually clever and make accounting less boring than it used to be.

OLIVIER: 14:36

Mhm. Mhm. Mhm. Okay. And so how do we do that. What kind of process do we follow. Uh how does it go so well at the origin of everything there must be some kind of specification, some kind of, of task as we call it. Ah. How does it well appear, uh, how do you create them? Uh, what is the flow?

LAURA: 14:59

Okay. Maybe.

OLIVIER: 15:00

Um, sure.

MATHIEU: 15:01

Um, so, indeed, uh, specification or a spec as it's, uh, um, related in the jargon of the R&D, uh, today, uh, it's it's not the most technical word.

OLIVIER: 15:11

So the spec I think is fine. Spec. Yeah.

MATHIEU: 15:14

Um, so it's basically, uh, um, the mission for the developer to develop the feature that we want. Um, it they can vary a lot. Uh, so, um, but usually they have two, uh, bigger sections. So usually, uh, you have a purpose. It's like, you know, please don't just develop that, but we will say, okay, the problem we are trying to solve, uh, is this and that. I think that's quite important for everyone. Uh, I think also, if you are working on something, it's interesting to know what problem you are solving. If you understand the problem you are solving, I think, you will, you know, get more motivated and also perhaps, you know, come up with your own, uh, solution sometimes, uh, to, to solve that problem. But usually as a product owner, we also provide the specification itself, which is, uh, the how that you should do it. Um, there's a range of specifications. So you have a lot of functional specs. Um, it could be uh, some even in manufacturing and inventory, we do accounting. It could be an Excel spreadsheet. And to say, okay, when we are doing some stock movements, we would like to have, uh, the, the entries done from this account to this account and so on. So it could be quite technical. We can also have a UI tasks. So with version 17 of Odoo we launched a new shop floor, um application which allows you to perform your different manufacturing operations. It's a brand new design and we're still improving it. So sometimes I will just do a spec and take some screenshots of of that module and say, okay, it'd be great.

OLIVIER: 16:47

You often work like that, right? Uh, taking like screenshots and then putting like notes and arrows everywhere saying this needs to change. Then when I click that, I need to open this, that, that exactly. Uh, um, would you say it helps like explaining the feature? Uh, for sure. Uh, because maybe I. Because we haven't been doing that forever. I don't know if if you knew the the ancient time where we we. Well, before Fabian discovered the excalidraw. Um, but it it was different. And indeed, it's better to have a tool like that, I guess, because it's just easier to understand for for technical people not knowing exactly the the functional ecosystem around around the task to just get an idea of the whole flow.

MATHIEU: 17:30

I would say ideally it's good to have both. Um, so ideally it's good to have the, the, the that design because it gives such a good it's like a, the abstract of a of uh, of, of uh dissertation or something.

OLIVIER: 17:43

Paper or whatever. Yeah.

MATHIEU: 17:45

Um, because it really summarizes really well, uh, what you're trying to do. Um, but also I think, uh, in a lot of cases, if it's a very big task, it's quite nice to also have some bullet points on the side to say, okay, well, just here's the checklist of what you have to do, by the way. And it helps people to to also structure their work a bit.

OLIVIER: 18:02

Um.

LAURA: 18:03

And also what I, what I like about, uh, the spec with the arrow and, and stuff is that we don't need to make a perfect design, a perfect design beforehand, and we don't lose too much time writing the specification. And it also gives some kind of independence to the developer. And, um, I think it's a very good practice that we have, uh, at Odoo doing that kind of small mockup, but not too detailed, you know. Mhm.

OLIVIER: 18:31

Uh, I agree because. Yeah. Just for, just for you for pure efficiency and not losing time writing, writing, writing, writing. Yes. I think it's a very interesting, uh, you don't have to describe the screen. You just show it.

LAURA: 18:43

And exactly. And in some companies for, for example, you have to follow, uh, a long list of uh, specification, but a very detailed and sometimes you lose way much more time writing it and then testing it point by point, then doing it, uh, quickly, uh, like we do.

OLIVIER: 19:01

Odoo style at all.

LAURA: 19:02

No, we don't like process.

OLIVIER: 19:04

We don't like process. Uh, okay. And, um, so you were talking about the, the, the the fact that the, well, the artistic side of the development, actually. Uh, yeah. Yeah. I mean, what happens, uh, happens better, actually, if there's a bit of room for the, for the developer to just, uh, you know, make, make, make the task his own. Uh, um, not all the tasks follow a strict process, uh, like this one. I mean, sometimes it's a bit a bit more flexible than that. Right. Uh. Mhm. Sure. But yeah.

CHRISTOPHE: 19:40

It goes back to the point that we had previously. We want the developers to own the task. If they are stars, we also expect them to behave as stars and maybe not.

OLIVIER: 19:51

And I phrase it this way, but what what.

CHRISTOPHE: 19:55

What I mean is, in some cases, we don't want to waste a lot of time making detail specifications where we expect the developers to actually understand what he's doing. And if, like everybody knows what he has to do, there's no point into specifying that. You know, that that that button should do absolutely that. Like if the spec is like clear enough with a markup and the purpose is very easy to understand, there's no need to waste a lot of time on our side to make detailed specification that the developer will follow. We expect him to be able to assess his own work and see that if the spec is followed and the purpose is filled in, then everybody, everybody is fine. And so there are cases like in accounting where we need to develop like a new report, and you have like ten lines that need to be filled in with the appropriate amount. And we have the specification from the government that says, what is what, what needs to be done. The developer should not expect from the product owner a detailed specification of a pre-calculation of whatever, like the spec is the report itself. There's no need for us to to provide an additional layer with that. I think we're going to go into the the follow up and the management and the the life time of a of a task. And we are still there to answer questions, to clarify issues. But the specification, like we will not block a task. It needs to start with a base spec that it can be understood by, by everyone without wasting time into huge specification stuff.

OLIVIER: 21:30

We have a question about that in the chat. That's pretty interesting. So I'm just going to display it on screen so others sometimes errors that could be avoided if the POS you used bullet points like in other companies. So would a more strict specification. Sometimes avoid situations where errors are made are made. Difficult question, I think.

LAURA: 21:53

Of course it happens. But, uh, then with communication and with the test, we we are able to see it quickly. And also what we have to point out is that the collaboration between the developer and the product owner is, uh, really, really deep. I would say, uh, because we all sit together in the same office. And when a developer is working on a task and a question arises because maybe the bullet point was not clear enough, then we are just next to them and we can discuss like like in real life. Mhm. Uh, so error might happen like in any other company. But I think with the clear communication that we have we tend to maybe decrease it a bit.

OLIVIER: 22:38

I think we can actually phrase it a bit differently, uh, and just turn the question the other way around and say, uh, definitely there are errors that don't occur because we are working like that as well. So of course nothing is perfect. There are still issues. Uh, sometimes, uh, we have colleagues working at Bug Fix, you know, so they have work, uh, uh, and, um, and, and and and so nothing is perfect, But indeed, uh, having something more with more communication, uh, more dynamic actually, and more and more flexible often solves a problem because before they, they problems before they happen. Uh, so pretty interesting. Um, uh, I would like to I would like to go back to what you were, what you were saying, uh, uh, about the the over start developers, uh, Uh, I think it's something that people tend to forget, uh, a lot. Uh, in the industry or just in life in general. Uh, when they talk about developers. A lot of people that are not developers don't realize that, uh, this job is a lot about, uh, creating things, making them, uh, like, really shaping the thing. Uh, and. And so giving more responsibility to the developer is essentially something pretty good, I think, for them to stay motivated to do the work, like, better, uh, just because they're more involved in it and they, they can give something of themselves, uh, to the thing they're not just executing, uh, something. They're not they're not programs. Uh, they're making them. That's the difference. Uh, and and and indeed, uh, having something where the guy needs to resolve something and not something that is, uh, like pre-digested where you did all the job and just just tried your your code to do that thing. I don't know what the syntax is, but it needs to do that. And essentially you wrote nearly pseudo code for everything. That is way, way less interesting for developers.

CHRISTOPHE: 24:35

Sure. And the guys, they make studies, they are very often developers are bright people like very intelligent. They are problem solving people by just giving the problem, orienting a solution, but making them provide the solution, it makes them proud of their work. And I think we know, like in a society where everybody burns out because they don't see the point of what they are doing. I think one of the greatest thing that we as PEO can do is make the developers proud of their work because they know why they do it. They know they did it, and it actually solves, um, you know, issues in the society. So for sure.

OLIVIER: 25:14

Yeah. And this brings us to like, uh, another kind of, of, of way of getting tasks, uh, and, and bringing new, new features on the table. Uh, sometimes there just appear, like, spontaneously. Uh, I have this anecdote like that. I have I have to tell it because that's that's my big story. You know, uh, in every family reunion, you have one like that. Well, that's the moment. Uh, and it's not about football this time. Um, uh, it's just A4V 16. Uh, so in v 16, in accounting, uh, we redid all the reporting engine. Uh, so it was a big, big thing. Took me busy, too. Kept me busy for a whole year with additional people at the end because I wasn't able to finish everything myself. Um, and at the origin of this task, you would have thought that there was one guy designing a lot of things and being like, hmm, we need to change that, change that, change that. Not at all. Actually. What happened is, uh, so one of our product owners, Benjamin, he's not there today, but maybe he's watching us. Hello. Um, uh, Benjamin actually wanted to add some kind of new way of making formulas on the on the financial reports. So the old model, just so that, uh, we could write reports more, more easily and especially balance sheets and profit and loss reports. And, um, so he drafted something on that. One of our developers did something on that, Lauren. And then we discussed that, uh, by chance and, um, and while talking about that, actually, uh, I had the idea of doing going like way, way further than that because they were like, I don't remember all the details, but there were other things that I was like, mhm. This, this, this needs to be changed or, you know, a lot of accumulated frustration over the years on that model specifically. And then I had the idea of changing a lot of things and I went to, to my team leader just like can I do that. And so that's that's huge thing of rewriting everything. And that's how the task was born. And eventually that's how we got the model we have now. And so that appeared like spontaneously without any kind of, uh, of like, you know, real precise, functional feedback saying you need to rewrite all the reports. But actually we had a lot of, of things everywhere saying, hmm, maybe it would be a good idea to do something there. And we didn't regret it so far. So I'm pretty happy about that. Uh, and, and yeah, so this kind of task happens quite, quite often. Right as well.

CHRISTOPHE: 27:37

Yeah. Sure. Can. Can I give you another one that I go ahead.

OLIVIER: 27:40

That I feel super.

CHRISTOPHE: 27:41

Interesting. It's since my beginning at Odoo. So in accounting we usually do multi-company stuff. And so you're in one company, you open a model and then you want to see in another company and then you switch a company. And for rights purposes, you don't have access to that model because it belongs to another company. Well, since I was at Odoo, when you did that and you had a security error, you would, you would, you would get like a pop up saying you, you don't have access to, which is a weird technical message. You don't have access for security reasons to that model. Whatever was a pop up, you only could click on okay, then it was a blank screen and you you needed to go back to the apps and go a mess. It was painful, a UX, UX mess. And for a while I was I was annoyed by that. And I think one time I went into the into the general chat of of accounting, and when dev said, you know what, I'm going to do that I'm going to see if I can solve that. It's and finally so he did it. The story is complicated. He did the first version, and it was actually so good that it triggered a generic, you know, um, task at the framework team, whatever. But at the end, we got rid of that really stupid error message. And I think that's another great example. At one point, a dev owns the fact that there's something really annoying in the product, and he agrees with me to try to solve it. And it can go that way as well. And I and I really loved it. And the product is better. Mhm. Uh, because of that.

OLIVIER: 29:11

And actually, uh, it's, it's a nice opportunity to make a callback to the first episode of Odoo unplugged actually, where we're discussing about creativity. And one of the key factors we isolated for that was, uh, so go, go watch this episode, uh, was, uh, was just, uh, you know, um, a frustration actually, uh, when you get frustrated about something and, you know, it stays in a lot of, in a part of humanity, like that thing, I don't know how I don't know what we should do, but that that's not okay. And eventually, uh, it will go back on the first, you know, fourth plan. And, and you will maybe discuss that with someone that will bring a solution exactly like that happened for you. Uh, uh, and, and I think it's very interesting because again, uh, having a very, very flexible with a lot of discussion, uh, way of, of making tasks also allows, uh, this kind of task to just be born. Uh, and if we were following the bullet points and very specific, uh, you know, very formatted, uh, documents, uh, that wouldn't be possible because, hey, that's not the process. Uh, you're not the one who make tasks. Uh, and so that wouldn't happen, essentially. Uh, by the way, we have another question, uh, in the chat, and I think it'll be the last one before the the little break before the half time. Um, yep. So how do you determine determine, uh, what's worth a task and what's not? How do we know? Because indeed, we have a very flexible way of working. But that means a lot of bad ideas might also come up. Uh, how do we decide what's a bad idea? Who decides? Um, for.

MATHIEU: 30:48

Sure. It's a very good question indeed. Um, it's difficult, I think, for us, usually the way we we we we move forward or not with a specific task is that we try and see how many users, potential users, uh, it could attract or it could touch. I mean, as a peo, we get a lot of, uh, feedback every day, uh, about, okay, I would like this or I would like that or like and a lot of points are very good. I mean, I get a lot of feedbacks and I agree with, uh, a lot of them, but some of them can lead to a technical debt. Uh, some of them can make the interface more difficult to use. Uh, additional option just makes the form more difficult to understand. And it even if the feature is good, if it's more complex to configure, it could just be a no for us. Um, so I think, uh, we have to really weigh the pros and, and the cons when we, uh, when we look at that. But I think if it's touching a lot of users, if it's simplifying the, the interface, um, and it's actually, you know, solving a real, uh, functional problem at the at the same time, I think usually it's definitely a green light for us, but it's difficult to get all of these three aspects together.

OLIVIER: 32:04

Yeah. And of course, it again, it can never be perfect, but I think, uh, the, the there's always a lot of discussions, uh, around new tasks and new new ideas like breaking up things. For example. There is one going on in accounting at the moment, but you'll see that for the release of the next version, I will not say what it is about. Uh, but there is a big discussion at the moment. Uh, I'm teasing things. Um, and, um, well, essentially we do argue a lot about it. Uh, and eventually we'll, we'll do something, uh, discuss it or argue even more on it. Uh, and, and then we'll see exactly what needs to be changed. And it will be much like that, uh, in the next version. But I think it just makes it better to do it this way, actually, because you have more people like validating it. And even if someone is like super against something, uh, he will get the opportunity to give all his arguments and maybe we'll say, okay, we don't care, but the arguments will be there, and maybe the guy will just prove right in two versions from there. Uh, and then we'll do his thing. But, uh, that's also part of the process. Yeah. No, it's.

MATHIEU: 33:11

I think that exchange is, uh, is quite good. And also when, when you have it on a regular basis, you know, that what you end up developing is really, uh, going to solve some, some problems.

OLIVIER: 33:21

Mhm mhm mhm. True, true.

CHRISTOPHE: 33:22

So any, any decision that we take is like it's it's not forever. Like we can see a feedback evaluate at that point that it's not that important. So we say no and it comes back. We say no again another four times. We say maybe it's time to do something about it. And and that's that's the point. I think Fabian mentioned all the time a good feedback will always come back, so it's better to say no three times to make sure that we don't clog up the software too much as, as Mathieu said. And then maybe later it will finally come. So feedback needs to keep coming. And it's not because we say no two times that it's a never.

OLIVIER: 33:57

Mhm. Mhm. Mhm. Mhm.

LAURA: 33:59

And also sometimes we receive um feedback from a real user. For example I have a small anecdote uh in mind. Uh like two months ago we went to see uh real users who are content with Benjamin and other product owner in accounting. And they were trying so to, to uh, to move their, to move their software so from another one to, to Odoo. And they wanted to import their assets. And in accounting we have uh a small field that allows to insert the, the already depreciated amount. And the issue was that this, uh, field was in debug mode only. So it was not really discoverable. And they were saying, yeah, we don't know how to do it. We lose time to import them manually. And this feature is really lacking. We lost so many hours and we were thinking, but wait, this feature actually exists. It's there. And thanks to that feedback, uh, we managed to just pop out of the debug, put it out of the debug mode, and, uh, it, uh, it, it brought value to a lot of users. So, uh, this is also, uh, something that we do if we see that this is a quick win, we are going to do the, the feedback and make the change.

OLIVIER: 35:16

And we for things like that, we even fix that in the current versions. Yeah. Not especially for the next ones. Uh. Mhm. Um, indeed. And that's also yeah a big, big source actually of, of new features or changes like that. Because it's not a new feature here. It's, it's a change. Uh, it's a change. Uh, it's just feedback from from from people. Uh, indeed. And that's a wrap for today's episode. This this first part interest you. If you want to join us live next time, don't hesitate to follow us on Twitch to receive the notification of our next programs. The link is in the description, and if you're in the mood for more captivating content, I highly recommend checking out our other episodes. Until next time. Cheers!