Frameworks: When, Why, And When To Move On

Leonard Kongshavn, Tristan Charvillat, Chantal Botana, Mihaela Draghici at UXDX EMEA. Video: https://www.youtube.com/watch?v=EYMOG4UmoA4

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions: why frameworks

[00:00:00] Mihaela: We have three guests: Leonard Kongshavn, global product lead for Google; Tristan Charvillat, VP of design and customer experience for BlaBlaCar; and Chantal Botana, who is a VP for consumer experience at Mews. They're going to join me today to talk about frameworks. We will go through how they tackle defining or choosing and implementing frameworks within their teams and their business, how they worked on adoption, but also how to adapt frameworks to their benefit within their specific contexts.

[00:00:36] Hello everyone, and welcome. I hope you can see me okay and hear me okay. Hello. Hi Tristan, hi Catherine. I'm actually really keen on moderating this discussion, because I've been working with various frameworks over the last eight years as a product manager. I got excited about some of them and enjoyed using and implementing some of them; I felt challenges with some of them. So I'm really looking forward to hearing your take on this. I would like to start the conversation by asking you to quickly introduce yourselves, and also briefly answer my first question, which is: why frameworks? What do they mean for you, for your teams and for your business? Who would like to start?

[00:01:29] Tristan: Yes, okay. I'm Tristan Charvillat. I'm working at BlaBlaCar, which is a carpool company, a global company. My role is pretty much to connect from marketing to design, taking care of what we call the consumer experience team. So it's product design, research, product marketing, the brand and the creative team. And I'm working on several frameworks, in particular the one that we built and we're using today at BlaBlaCar.

[00:02:07] Chantal: Great. I'm Chantal Botana. I'm the VP of product management at Mews. We are reimagining the art of hospitality. We have a property management system, and we deliver remarkable experiences to guests. I have about 20 years of product management experience, so back in the day of true waterfall, which we haven't quite gotten rid of yet either. Frameworks, for me: I think Rory Madden said it best in his earlier ways of working session, which is "constraints enable autonomy." I consider a framework a form of constraint, but a good constraint, that enables the teams to have more autonomy.

[00:02:51] Leonard: And I'm Leo. I work at Google as a global product lead, leading our search partner business and a couple of ads UI teams as well. I have a lot of fun doing that, of course, from Norway, being remote. I could really feel what [?] was talking about; that was great. On frameworks, of course I agree on being a constraint, but frameworks, most of all for me, are a structure. It's a way for us to agree on what's the process, what are the steps, what's the next thing we should do. If you're a junior member of the team or a more senior member of the team, you still abide by the same rules. It's like football: it wouldn't make sense if people could start using their hands and whatnot on the pitch. Having the common set of rules really helps you apply and move faster, in my take.

Choosing which framework to apply

[00:03:38] Mihaela: Thank you. So I take from here that whether you see them as constraints or a set of rules, it's about giving the structure that enables teams to do their jobs best, or to be efficient. Regarding this structure and these processes, let's say not necessarily rules but the structure: when should you apply what type of framework? When do you know what type of framework is needed for a specific step in product development, for a specific stage of the team? How do you choose that? Tristan, would you like to start?

[00:04:19] Tristan: Yes. I would say that it depends on the problem you want to solve. You can apply frameworks in many, many different fields. Back to the definition Leo and Chantal just gave, it's a structure, so you're going to structure the activity. But there could be hiring frameworks, personal development frameworks, team collaboration frameworks, delivery frameworks, and probably there's no framework that is covering all those aspects. So probably the first thing is to identify where there is something that you want to fix or to improve, and then, based on that, figure out: what type of framework do we have in the market, or what type of framework can we build? That would also be very influenced by the type of problem you want to fix, or the type of dynamic you have within the team.

[00:05:13] Mihaela: Chantal, what's your opinion on this?

[00:05:15] Chantal: I would second that. I think "it depends" is always a good answer, although that sometimes frustrates people. Actually, an agile coach said to me earlier today that if your agile coach doesn't say "it depends" often enough, then they're not actually an agile coach. I think that's very true. There's a ton of frameworks, and it really does depend. Are you doing discovery? Are you doing delivery? Are you doing discovery on the delivery? Are you doing discovery on the research, on the initial problem? There are so many out there, and I think it also depends on how much time you have, because certain frameworks require more time than others. But certainly we're talking about agile, lean and design thinking frameworks.

[00:06:11] Mihaela: What about you, Leonard?

[00:06:13] Leonard: Of course I very much agree with both statements. I think the bigger question would be when you should not apply a framework. I think that's much more the real question. Think about the outcome, be very clear on what you want to accomplish, and then pick something that works in your organization. Every organization is different. You notice that when you join a company; typically you don't notice it when you're in a company, because that's just the way it is. I really love it whenever we get new team members on my team. I love spending time deep diving into their thoughts on, hey, what are we actually doing, what's not really working? Getting that feedback and checking yourself on the framework you're delivering is, I think, the best way to figure out when not to apply them and when to apply them.

Adapting existing frameworks versus building your own

[00:06:57] Mihaela: That's actually an interesting take on this. Sometimes it's important to look at when not to apply a framework, just for the sake of applying a framework. We mentioned there are different types of frameworks. We had this previous conversation where you mentioned, Leonard, there are so many frameworks out there, and Chantal, you said the same thing just now. What do you feel about using and adapting existing frameworks versus designing your own new frameworks within the team or within the company? Leonard?

[00:07:32] Leonard: I made my own framework, so that tells you which camp I'm in. But at the same time, it's typically an evolution of something else. There are no new frameworks coming. Even if you claim you make something, it's not a new one. You take something and you adapt it, and you keep adapting it. Just like my framework, which I brought to the world a year ago, is something that's been changing along the way. As you get more input, more feedback from people, you have to look at it: wait, does this make sense? Does it make sense in this case? And then develop it. That's why it's now turning into this three-part article series that I've written on LinkedIn, just to clarify some of the points which weren't as clear in the first part. This is how you see them develop.

[00:08:09] I would argue you start by adapting what works, because there are so many benefits of a really well thought through framework that you can apply, that other people know and can share experiences from, which I think is the best part of it. Secondly, from there you develop it enough until it becomes your thing. Just like product development, by the way; just like how you build the products as well.

[00:08:35] Mihaela: You talked about adapting, so you start by adapting something that exists. When and how do you do that?

[00:08:46] Leonard: For my part, it's when I see something not working, when I see a framework or process that isn't working as smoothly as we want, and we catch something: why are we doing this step when we shouldn't be doing it? In product discovery, do you have to follow a strict process, or can you jump steps when you already know the answers, or there's already a robust set of data you can just pull on? Sometimes you don't have to go through all the steps, even though when you do have time, you want to go through them. That's just one example of where you can do that. There are tons of others. I've talked about product excellence as well at Google, which is something we work really heavily on, and with that there are obviously steps you can skip, because if you follow everything, you will never get any product out in any sort of time frame.

[00:09:24] Chantal: I like that. On the flip side of that, it's always a hot topic with frameworks: should you use them the way they were intended? If you have a really high-performing team and it's a mature team, then sure, they should be able to decide what they're going to do, Scrum, Kanban, XP, or if it's on the discovery side, earlier in the process, they should be able to decide as well. Again, the frameworks are there to help make the teams more successful and take some of the maybe tedious thinking out of the process, so they can focus on more important things.

[00:10:00] But I do think that there is a risk in taking a framework and trying to make it your own before you've reaped the benefits of it, especially if it's a new team. If you think back to Bruce Tuckman's forming, storming, norming and performing, maybe the team needs to gel a little bit and get to be high-performing, and then by all means pick and choose, and then over time, as a company, come up with your own way of working. But it has to be documented, especially as you're scaling. It's one thing if you're just a couple of Scrum teams, or whatever kind of team, but once you start to scale, if it's not documented, it's chaos.

Small companies versus enterprises

[00:10:47] Mihaela: You're actually making a really good point here about documenting and having information available for people to refer back to, and it's related to what we were discussing previously as well. What is your experience with implementing frameworks in, let's say, a small team or company versus a more established or enterprise-level company? Maybe, Tristan, you have some input on that topic as well.

[00:11:17] Tristan: Yes. Maybe that's a strange approach, but I would say that the smaller the company, the bolder the implementation should be. It's really hard to apply a framework on a large company first, and maybe it's very risky. But in a small company, if you apply it to just one or two people, you'll have a really hard time evaluating whether it's actually working or not. Back to my own experience with BlaBlaCar, which is a pretty small team: we applied a product framework on the product team, which would be probably 60 people, not more, and we really tried to apply it straight. Straight doesn't mean it comes from nowhere and then suddenly, overnight, you ask everyone to apply it, but it was a pretty fast rollout. We processed it a lot; we thought about it a lot.

[00:12:12] Back to the comment I just heard: yes, absolutely, starting with something that exists is a very important one. I think it's also a sense of humility. If you start from scratch, from nothing, as if you know better than others... hard to believe. So you start with something, and then probably you need to develop your craft. It's a bit like music: if you want to improvise, you'd better start by mastering your instrument. If not, then it's kind of a crazy thing. So you start, you apply it very loudly, significantly, so you can have a sense of how it's working and what's not. Then you develop the usage of it, and then probably you can start adapting based on the strategy.

[00:12:53] Maybe I just want to add one thing back to the previous question, something interesting: a framework is also a tool of influence. If you're a leader and you see some weaknesses, or elements that you want to improve in your company, based also on your capacity and your culture, you can use it to double down on one type of activity. If you believe that you're not doing enough research, as an example, maybe the research step or activities will help you to develop that specific muscle. As you move forward, you can start playing with your framework, expanding or collapsing it, so that you adapt your influence. But at the very beginning, if there are some startup people in the audience, I would advise that you probably shouldn't start too small in the startup, because there will be such a small number of people that you'll hardly see the impact you will have.

[00:13:54] Mihaela: Thank you, Tristan. That is actually a very useful insight. Chantal, what is your experience when it comes to implementing frameworks?

[00:14:03] Chantal: I've worked with a variety of frameworks in different size companies: scale-ups, startups, Fortune 500 companies. I think it's really important, whether you're big or small, to experiment, actually. I'd say if you're a really large company, maybe just take one or two teams, experiment with a couple of frameworks, and see how it goes before rolling it out to everyone. I think what you want is for people to become champions of those frameworks, or those tactics. If you get goodness out of a couple of teams, then they become your influencers and your champions of it. You really want people to be begging to have the same techniques and tools at their disposal. That's not to say that you would withhold it from anybody else. But you wouldn't want to step into a new company and pull the rug out from everybody and say, "Hey, we're going to be doing this, this, this and that." I think that's crazy talk.

[00:15:12] I'm actually going through a process right now: all of product and tech at Mews is R&D; we like to keep that innovation spirit alive. I'm starting to do a journey map to see how our team members are going through the journey of our way of working, what tools they're using, what frameworks they're leveraging or not, so that we can look for those pains and gains and try to help fill the gaps.

[00:15:46] Mihaela: Thank you. What's your experience, Leo?

[00:15:49] Leonard: I've done this on both smaller and larger teams at Google. In a small team setting, we actually tried to introduce some sort of framework which didn't make sense. There were just too few people for it to be different from what we were doing normally, and people just found the solutions they needed. In our small teams, I think that's very much aligned with what the startup experience would be: you just do what works, until the point where it doesn't work anymore, when it breaks, and that's where you look at it: wait, we need to adapt what we're doing.

[00:16:20] In a larger team it's the opposite, very much like Chantal is saying. You start with one part of the team, or a problem that exists, and try to figure out that small part, and then you integrate it slowly into the rest of what you're doing. My takeaway [?] is that it takes a lot of time, much longer than anything else. If you try to force it by setting policies or saying "this is how we do it," it doesn't work. It just falls apart. You need internal motivation. Just like with kids, they need internal motivation to do what you want them to do. It's that type of scenario. So that's my experience.

Avoiding water-scrum-fall

[00:16:58] Mihaela: Thank you very much. Actually, Chantal's point around experimenting triggered a question from our audience, which goes: when you experiment, how do you help companies avoid water-scrum-fall, or other "making it work in your context" that limits the original benefits and intent? What's your take on this, Chantal?

[00:17:22] Chantal: That's a really, really good one. I think it does go back to using the framework the way that it was intended. I don't think you should experiment within the framework, moving different pieces or dropping certain ceremonies, et cetera, if you're new to it. Do it the way that it's intended. But then experiment with a variety of frameworks. Let's say you want to start doing opportunity solution trees. Okay, do it the way that it was intended by Teresa Torres, see what you learn from it, and then see if it makes sense to apply it to the other teams as well.

[00:18:04] But oh, the waterfall. It's not gone, is it? A lot of these frameworks end up becoming just a... I don't know. That's a really tricky subject. I don't have all the answers for that. I think every company still struggles with that, to be honest. You've got to have the support of leadership, though, to make sure that everyone feels that psychological safety to be able to do more discovery, or whatever else it is. But I'll pass it over to one of my other panelists.

[00:18:44] Mihaela: Tristan, Leo, do you have any views on this?

[00:18:48] Tristan: I think the right setting, the right environment for the framework to work, is definitely an important topic. At the beginning it's fragile. It's very easy to go back to previous habits, for many reasons, and you named some of those. So having the right setup for success is also having the right environment to welcome your framework. The culture of your company, and its fit with your framework, is absolutely critical. If you want to do discovery work in a company that's not at all mature and ready for that, then probably you have to develop your first strategy, which is to get your company ready to accept such a framework and make it work. If you try to do both at the same time, meaning you're trying to change the habits of the people at the same time as trying to change the culture of your company, maybe that's a setup for failure, or a risky setup, I would say.

Overarching frameworks: OKRs, jobs to be done, Design for Delight

[00:19:52] Chantal: If I could just add to that, I think it's really important to have, in these instances, a strategic framework above everything else, that doesn't necessarily sit within R&D or product and tech. A strategic framework like OKRs. Some of the frameworks that we talk about, like discovery frameworks, are not going to work if the teams are not autonomous, and they're going to need something to guide them, and those would be OKRs. But if you don't have that, then probably that's not a good framework for you.

[00:20:27] Mihaela: You mentioned OKRs as an overarching framework that can help guide the others within different divisions or departments or teams. Tristan or Leo, do you have other suggestions for such overarching frameworks?

[00:20:43] Leonard: I think OKRs are by far the most common, and the reason they're most common is because they're really, really helpful and really productive. You clearly state it; it's like saying, on a Saturday, "I want to go on a walk, I want to go this distance," and you proclaim it to the whole world. So you build your commitment towards what you're trying to achieve. The good thing about OKRs is, of course, you have to go back to how they were originally intended. You should have stretch OKRs. You shouldn't be focused on having a one on everything, because if you rate yourself 100% across everything, you haven't been ambitious enough. That's something we practice at Google very heavily: it's okay to miss your OKRs as long as they are really ambitious ones. If they're not ambitious, that's a bigger problem. So OKRs are by far my most favorite overarching one.

[00:21:31] Beyond that, I'm really, really passionate about jobs to be done, which I try to use whenever I want to talk about the user. Are we solving the job that they want to hire us to do? I think it's a very helpful, quick mental framework, and the way I like to think about it. So that's helpful, and the team seems to like it as well, so that's good. Those are the two, but I would focus on strategic company-controlling or company organizational frameworks before I go into specific elements of the business, like product.

[00:22:07] Mihaela: Thank you. What about you, Tristan?

[00:22:12] Tristan: Well, I like using frameworks for cultural topics. Maybe discovery framework is one of those; it really changes the way we look at things, and it's a deep change. A framework I really like is Design for Delight. This is an Intuit way to look at things. I had the chance to work there for some time, and what's interesting there is that it's profoundly rooted in the DNA. This is how people think. What comes to the surface is the deep stuff that comes to the surface, and that's the structure that people should adopt. So I'm a big fan of those types of frameworks, where it's hard to measure the direct impact. You can talk about efficiency, but not always, and success, but sometimes it's a hard thing to measure.

[00:23:11] But in terms of the cultural impact it has, and the alignment of people... maybe we haven't talked a lot about this, but it's also a way to create consistency for your company in the way we approach things. So it has a deep impact on the communication between the teams. As soon as we have a common way to look at things, a common way to work, it facilitates the communication. There are plenty of advantages that you can get from applying such a framework, so I like looking at it through the cultural aspect also.

[00:23:41] Chantal: I think it provides a common language as well, to your point.

[00:23:43] Mihaela: Yeah, I was exactly about to make the same comment. I think we're all aligned on this. It's about creating a common understanding and a coherence behind everything we do.

Adapting to remote work

[00:23:58] You told me about your favorite frameworks. I have another question, which comes from the public as well, from Huayun [?], who's asking if you changed any frameworks or ceremonies to adapt to working from home and working remotely.

[00:24:17] Chantal: I think not so much. We just do some things async versus sync, and that's really up to the teams to decide. Some teams that are doing Scrum have decided to do their daily standups in Slack. That's up to the team. Other than that, I don't think things have changed too much. I think it actually changes more what it means when you're all back together again, because now we start with remote first. If one person is on a laptop because they're not in the room, then we're all on a laptop, so that there are no second-class citizens.

[00:24:56] Tristan: Sorry. No, good. I would say it hasn't changed the overall structure of our framework, but probably some activities that are part of the framework. We have a framework with different steps. One of the steps is the testing activity. Obviously user tests and all the consumer touch points have been really challenged over the last year. Some creative activities as well: there's a design part that requires a lot of touch points, and it was so smooth face to face, in a room, drawing on the wall and creating that dynamic. I would say that was quite painful. So we haven't changed the overall structure, the steps we need to go through, the type of delivery, but the activities have been a bit challenged.

[00:25:50] And yes, I should have said, we tried to adapt, we found something, but now it's a new era, where it's half back and half not back to the office, which is another setup that honestly I didn't expect. I didn't forecast it. There was full remote, and now it's half and half, and it's again one thing we need to figure out for those activities.

What success looks like

[00:26:14] Mihaela: Once again, we need to adapt to new ways of working. That's true. I have one final question before we wrap up, because we're running out of time. You all mentioned success. What does success of a framework mean to you?

[00:26:31] Leonard: I like that one. I think Tristan had a very good point: it drives the culture. You see a change in the culture and the way people think. It drives commonality among every team member, and among teams as well, and then the whole company. So I think a good framework has a culture element, it has a structure element, and it has an efficiency element. Look at those three: are we solving for that? I think that's what any good framework should have. Sorry, was that the question?

[00:27:04] Mihaela: Actually, that's the question, yes.

[00:27:07] Leonard: Yeah, I think that wraps it up.

[00:27:10] Chantal: Just to add on to that, I think that's exactly right. It's hard to find metrics for some of these things. We're playing around with time to value, especially when you're doing, like what we do, dual-track agile, and we're focusing more on the outcomes instead of the outputs. How do you reframe your metrics within that? So time to value is something that we're exploring.

[00:27:41] Mihaela: Thank you. What's your take, Tristan?

[00:27:44] Tristan: Everything that's been said, yes, a hundred percent. Maybe one thing I've noticed which makes me excited, and I'm not sure this is a success sign, but somehow it is, is when I hear people using our internal vocabulary. That's one thing we did: we made a lot of changes along the way, and one of those is having our own naming, our own vocabulary. Even though it's discovery, we call it slightly differently. But it becomes our internal vocabulary, and when I hear people saying, "Oh, we're now in the immerse phase," which is a kind of discovery phase, I feel like, oh, now it's theirs. When you see that the framework is owned by the people, that's the way they work, and we don't even know where the framework is coming from, it's our framework, that's, I think, the very interesting success sign.

[00:28:40] Mihaela: That's a strong sign of strong adoption. People already speak about it and live it on a day-to-day basis. I'm afraid we've run out of time, but it was a great pleasure to have you here with us today. If any of the attendees have any further questions for our panelists, feel free to go to Slack, to the ask-the-speaker channel, tag them and ask your questions. They will be happy to respond to you.