In this interview, Fouad Benyoub explains how competitive intelligence (CI) professionals can cope with the flood of internal requests by applying design thinking and Kanban principles. He stresses that CI programs must be customized to each organization, beginning with an empathy phase to understand the company's specific needs before defining the problem to solve. The design thinking process then moves to ideation, where CI deliverables, meeting formats, and target teams are brainstormed, followed by prototyping these outputs and testing them with internal stakeholders to ensure relevance. For day‑to‑day work, Benyoub recommends a simple Kanban system: all incoming requests enter a funnel, are placed in a backlog, and are prioritized based on strategic importance, using the concept of a Key Intelligence Topic (KIT). He highlights the importance of managing lead time—ensuring work is completed efficiently—and establishing clear criteria for when a KIT is ready for stakeholder presentation. After each delivery, soliciting feedback allows the CI team to decide whether to pivot (adjust the approach) or persevere (continue as is), thereby continuously optimizing the CI program and avoiding the production of low‑value outputs.
mentioned a few of them, but some very specific practical examples. And you talked about the overload. So we get so many requests, right, as CI professionals, so many requests coming. So could you explain how, let's say, you know, design thinking or Kanban could be used to help CI professionals?
Sure. Well, I discovered, for example, the approach of design thinking, it's more about Creating, let's say, CI programs adapted to the organization. All organizations are not equal. And we have first— what I love about this approach is that we empathize first, that we understand the organization first to define the problem we want to solve. We don't start with a generic CI program and we think that it will work. Sometimes the deliverables or CI outputs for one organization will have no value for another organization. So it's always about before seeking to fight or to do something, seek to understand. Once we understand, we define after that the problems in the— we want to solve for the organization. We start to ideate which kind of CI outputs, deliverables, meetings, for example, what, what are the formats, what kind, what teams we have to talk to. We ideate on that. What we call prototyping in, in the design thinking process is, is creating, let's say, uh, well, a prototype. What I call it for CI, it could be the deliverables, the, the meetings we will have with people, and we test it with, with the, with the people inside the organization. That way we can get closer to what the organization really needs in terms of market and competitive intelligence, not going broad and, and, and maybe we miss the point. For Kanban, for example, for the day-to-day, and I, I love the approach You don't— so do I. Yeah, you don't just get— take any request and start working on it. You don't run with it, you keep it. And I have a very simple Kanban I, I, I use, and I advise people to use, is you have your funnel, everything going to, to, to, to come in your way, you keep it there and you prioritize in your backlog. Same way product teams do, you prioritize, you make sure that the KIT you're working on— for KIT stands for a key intelligence topic— uh, is, is really the most important and the most urgent, or something like that. It's the strategic level of that request. Then you move on into working on it. So it helps with that. Uh, of course, I would spend a whole hour talking about Kanban, but the idea is to make sure that the entry point, when you have any element, you don't just run with it and start working on it. You prioritize, you make sure that it's listed according to the value it brings. When you work on it, you make sure that you're not spending a month working on something that you can work on for a week. So the lead time is important. You define your criteria for when we can say that, that, that key IT is ready to be presented to stakeholders. And once it's ready and presented, what kind of feedback you can get to make it done. Because you don't close any key IT until, let's say, you have some feedback about that also. And this is something maybe new for many people, uh, talking about each time we're presenting something, uh, a CI output or deliverable, we seek that feedback from people to make sure that we optimize the, the output each time and we optimize the overall program over time. Because the worst thing is to keep presenting, uh, outputs that nobody cares about, for example, and it's not responding to their needs. So we need to know if it's really valuable to them or not. If it's not, we adapt. And this is what we call— we're talking about pivot or persevere over time. So yeah, these are some elements I want to share with the— with people. Of course, it will be more specific and for— with some examples, but that's the goal.
