I spend time on the security side of technology as well as the product side. For a long time I kept those two halves of my thinking separate, because they felt like different disciplines with different temperaments.
They are not. Offensive security is a planning discipline, and it is a considerably more rigorous one than most product planning I have seen. The people who are good at it have habits that would improve almost any roadmap.
Here are the four that changed how I plan.
One. Start from the objective, then work backwards through what must be true
An attacker does not begin with a list of things they could try. They begin with an objective, and then they work backwards: to reach that, I need this; to get this, I need that.
Product roadmaps almost never work this way. They are usually forward looking lists of things the team could build, sorted by some blend of effort, enthusiasm and whoever asked most recently. The connection between any given item and an actual outcome is asserted rather than traced.
Working backwards is uncomfortable because it exposes items that connect to nothing. Take your roadmap, name the outcome you are actually chasing, and draw the chain from each item to that outcome. In my experience a third of the list has no chain at all. Those items are not necessarily wrong, but you should know they are there for another reason, and you should be able to say what that reason is.
Two. Find the path of least resistance, not the impressive one
Attackers are lazy in a disciplined way. They do not look for the most elegant route. They look for the cheapest one that works, and it is very often unglamorous. A forgotten account. A misconfiguration. A person who will hold a door.
Product teams have the opposite instinct. Given a goal, we gravitate toward the substantial build, partly because substantial builds are more satisfying and easier to justify as work.
The discipline is to ask, every time: what is the cheapest thing that would achieve this outcome, including things that are not software at all? A manual process. A partnership. A change to the pricing page. A conversation. If the honest answer is that a week of unglamorous work gets you most of the outcome, the six month build needs to justify the difference, and often it cannot.
Three. Assume you will be wrong and plan the blast radius
Assume breach is the phrase in security. The mature position is not that defences will hold, but that some of them will fail, so the real work is limiting what a failure reaches.
Product planning almost never does this. Plans are built on the assumption that the bets are right. The occasional risk register is a list of things that might go wrong with no structural consequence for how the work is sequenced.
Planning blast radius means asking, for each significant bet: if this is wrong, what else falls over? Sometimes the answer is nothing, and you can move fast. Sometimes a single assumption sits underneath four quarters of work, and discovering that after two quarters is expensive.
This changes sequencing in a specific way. You do the thing that tests the load bearing assumption first, even when it is not the most valuable item, because its purpose is to reduce how much depends on being right.
Four. The map is not the territory, so go and look
The single most consistent finding in offensive work is that the documented environment and the real one differ. There is always a system nobody mentioned, an old integration still running, a process people abandoned but never removed.
Product roadmaps are built on documented environments too. On how the workflow is supposed to work, what the support tickets say, what the customer described in a call.
The habit worth stealing is verification by observation. Not asking people what they do. Watching what they do. Every time I have done this properly I have found something that changed the plan, and it is usually not subtle. People describe their idealised process and then work around it constantly, and the workaround is where the real product opportunity lives.
Where the analogy stops
I want to be careful, because pushing this too far produces something unpleasant.
Attackers have one objective and no obligation to the system they are entering. Product teams have many objectives, and an obligation to the people they build for. A roadmap planned with purely adversarial logic tends to produce short term extraction: the cheapest path to a metric, which is very often a path that makes the product worse.
The transferable part is the rigour, not the ethics. Work backwards from an objective. Prefer the cheap route. Assume you are wrong somewhere and limit the damage. Verify reality rather than trusting the diagram.
The part that must not transfer is indifference to the outcome for everyone else. The whole reason the discipline is worth borrowing is to build something that holds up, and something that holds up has to be worth having in the first place.
One exercise
If you take one thing from this, take this exercise. It takes an hour.
Take your current roadmap and, for each item, write the sentence: we are building this because we believe X. Then, for each X, write down what would have to happen for you to discover you were wrong, and how long that would take.
Anything where the answer is longer than a quarter is a load bearing assumption you cannot currently test. Those are the items that should move to the front, not because they deliver the most value, but because they cost the most to be wrong about.
That is the whole method, really. Not paranoia. Just refusing to let an untested belief sit underneath a year of work.
I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.
