False Friends | Black Swan Farming

TL;DR: Avoid the seductive sirens that lead you astray. Dial the fundamentals up to 11.

Every few years, the tech industry finds a new banner to rally around. Agile. Lean. Design Thinking. Cloud. Digital. DevOps. Product.

Unless you’ve been asleep for the last couple of years, it’s now AI all-the-things.

Each wave promises to change everything. And in some ways, they do. They bring new tools, new language, and lots of promises, hopes and dreams. But if you’ve been around long enough, you might start to notice a pattern. Every wave of change eventually circles back to the same question — are we actually making meaningful progress?

We’re still very early in the current cycle, but it seems that we’re going to see a speeding up of everything — design, testing, coding, decision-making. There’s a compression of cycle-time for almost every piece of the puzzle. But that doesn’t mean we’re heading in the right direction.

When the cost of movement drops to near zero, the cost of misdirection goes through the roof. It’s a bit like putting an inexperienced driver behind the wheel of a supercar. Yes, it’s a lot of power. Yes, the acceleration is incredible… No, that tree won’t jump out of the way. Neither will that brick wall.

So, the real challenge with this latest wave of change, like many before it, is that AI doesn’t fix dysfunction — it amplifies it. Whatever habits, blind spots, or shortcuts were already there… they’re happening faster now. Which means avoiding obstacles and maintaining some semblance of steering is critical to survival, as well as making sure you’re actually heading in the right direction.

And that’s where the real danger lies. The bad habits, weak culture and shortcuts are going to get amplified. Those things tend to subtly reveal themselves in the language we use. It’s not that the words themselves are wrong, more that they coax an organisation in the wrong direction.

I call these false friends. They’re particularly seductive because they sound right and they appear to be what we desire. They make people nod in meetings! They give the illusion of maturity and control. But unfortunately they also slowly corrode what matters most — curiosity, learning, and the ability to adapt.

The Sirens and Ulysses (1837) by William Etty

When everything accelerates, that puts more pressure on judgment and reaction times. Which makes knowing what obstacles to avoid more important than ever.

Sensible people can disagree on what these might be, but here’s my take – based on my experience of what gets leaders into trouble. Here’s some familiar words that we often hear in product development — words that sound safe, even sensible — but which, followed too faithfully, can quietly lead you astray…

Language isn’t neutral. The words we choose shape what we notice, what we ignore, and how we make sense of things. Each word carries a set of assumptions baked into it — about what matters, what’s controllable, what’s expected — and those words quietly steer behaviour and shape our culture. OTOH, change the language, and you often change how people think about the work. That’s why it’s worth paying attention to the words that sound responsible but quietly distort how we think, decide, and build. They’re false friends.

1. “Requirements”

The illusion of certainty, false confidence in things we can’t yet know – that have to be discovered.

“Requirements” suggests that we can know up front what users need, and that we just need to figure out how to deliver that. Unfortunately, this is almost never true.

“We just need to get the requirements locked down.”

Inconvenient truth: we have hypotheses about what customers and users need. Whilst we can test those needs early and often, until we’ve actually put our solution in front of them we don’t really know how they are going to react. And so, we need to retain curiosity and speed up our learning loops – in particular the primary outer loop of whether we’re actually creating value or not.

When we treat discovery problems as delivery problems, we hinder or hide the learning. Teams that optimise for “building to the spec” rather than understanding the customer.

A requirement is a frozen guess, and every frozen guess hides a risk: is this actually going to be used, does it actually solve the problem, will people buy or hire this solution to get the job they really needed to do?

Why “Requirements” is a false friend:

“Requirements” imply the problem is solved upfront.
Encourages delivery mindset, kills discovery.
Replace with hypotheses and shared why.
Stay humble. Stay curious. Don’t hide the uncertainty.
Speed up your double-loop learning to avoid this.

“Requirements” is a false friend. It makes it sound like we know exactly what the customer needs. It removes uncertainty and creates an “order-taker” relationship.

2. “Execution”

Execution” suggests that we already know all of the steps needed to deliver it, that we just need to do the typing part.

“We just need to crank up our execution, dial up the velocity and deliver.”

Inconvenient truth: Until we’ve done it, we don’t know in detail how we’re going to do it. We might have a hypothesis for how we’re going to do it, but there’s a lot more discovery in the doing than is suggested in the word “execution”. Like all complex endeavours, the process is non-linear – we are discovering as we go.

And so, small increments and iterations are essential, with tight feedback loops to let us know whether we are off track. We need to not just respond to feedback loops along the way, we also need to build those feedback loops. This is especially true with the new genie assistants we have.

“Execution” is one of those words that sounds like leadership. “We just need to focus on execution.” It signals decisiveness, discipline, energy. But in product work, execution is meaningless without direction.

And so, much like the “what” question, where we are discovering what users and customers will actually use and love, the “how” question is also fuzzier than our language suggests.

Why “Execution” is a false friend:

“Execution” feels strong and decisive, but it’s just not how product development works.
Small steps, tiny reversible increments with lots of room for iteration to find what truly works.
Fast feedback is key, and we need to build that along the way. TDD style.
Let’s not pretend that it’s linear. It’s not. Speed of learning is the critical variable, and talk of “execution” hides that.

“Execution” is a false friend. It makes it sound like we know exactly “how” we are going to build it, and that the “what” or the “how” won’t change.

3. “Efficiency”

By treating your tech function as a Cost Centre, that drives a relentless hunt for faster and cheaper inputs, often a false economy.

“Let’s move some of this testing and development offshore — the rates are half as much. So much more efficient!”

Inconvenient truth: product development is not like manufacturing plant. The work is complex in nature, and the potential upside is asymmetric to the input. So to optimise for efficiency will generally lead you to bigger batches and slower feedback loops that leave you exposed to disastrous outcomes. Also, without your tech, most organisations would fall over completely in days, if not hours. It’s also the primary touch point for the vast majority of your customers or users.

“We need to be more efficient.” It’s the most respectable phrase in business. Efficiency feels virtuous, frugal, rational. But in creative work, efficiency can be the most expensive mistake.

When we optimise for local efficiency — full utilisation, fewer meetings, tighter timelines — we destroy global effectiveness. The cost of delay, rework, and misalignment far outweighs the visible “waste” we trimmed.

In manufacturing, efficiency and waste elimination is indeed key. In that context, the nature of the work is:

Highly repetitive processes
Predictable inputs and outputs
Tolerances are fixed (measured in mm or even nanometres)
Work is bounded (can only cut once)
Parts are all visible

In Product Development, efficiency is a long way down the list, because the nature of the work is:

Each work item is unique (we’ve never done it before)
Process is unpredictable
Tolerances are evolving (w
Work is unbounded (can always make it a bit faster, more scalable), and
Parts are mostly invisible.

Be careful not to fall into the trap of prematurely optimising for efficiency. If cost of inputs is really the issue, you’re probably missing the wood for the trees. And if you talk like you’re a cost centre, don’t be surprised when people treat you like a cost centre.

Efficiency is a false friend. Sounds sensible, but optimises for the wrong game and set you up as a cost centre, instead of hunting for value more effectively.

4. “Accountability”

Loading bullets for a game of Russian roulette, with predictable behaviours that quickly emerge.

Calls for more “accountability” suggests that folks are lazy or negligent, and that what is missing is sufficient fear of reprisal or punishment. That by holding people to account, that they would somehow be less lazy or make fewer mistakes.

“We just need to make people accountable for these estimates.”

Inconvenient truth: we simply don’t know. It’s way too early. We’re largely guessing and there’s dozens of unknowns that are outside of the team’s control. And the bigger the batch, the worse the guess. Folks (of course) respond by either avoiding saying anything about the relative size, or they hide contingencies and padding (that then get’s used up – so you get a very predictable and much slower delivery). Cobra Effect – unintended consequences.

“We need to make sure someone is accountable.” It sounds like good governance. But in practice, accountability often means “we need to know who to blame.”

When people fear blame, they protect themselves. They pad timelines, over-scope features, or understate risk. The result isn’t higher performance — it’s defensive performance.

Psychological safety isn’t about comfort; it’s about truth. When teams don’t feel safe to be wrong, they stop being right.

True accountability is collective — to the outcome, not the output. It’s about owning the system, not the scapegoat.

In short:

Accountability feels like fairness.
In practice: fear, padding, blame.
Destroys safety → no honesty.
Fearful teams hide, avoid responsibility, insist on analysis and approval to protect themselves. Slower learning.
Replace with shared responsibility for outcomes.

Accountability is a false friend. Sets up the blame game, ignoring unknowns, drives unintended consequences and protective measures: Cobra Effect.

5. “Just”

When you hear “just” in a sentence, that’s a clear signal that we’re trying to wave away the complexity.

“Just” is everywhere in product development. I hear it all the time. It’s a tiny sleight of hand that oversimplifies what we’re trying to do. Should add this to our list of four-letter swear words.

“Can’t we just add X feature?”, “We just need to do Y”, “We just need to migrate users over”, etc. etc.

Inconvenient truth: this is a word we often use when we don’t understand all of the interdependencies or risks or the complexity of what we’re attempting. It also sounds decisive and removes doubt.

“Just” is the magical wand that transforms all the complexity into something so simple and obvious anyone can see it. It’s like corporate denial, compressing complexity into a single syllable. It’s what we say when we don’t fully grasp the system — or when we want to sound decisive and remove all doubt.

This use of “just” hides an iceberg of interdependencies and complexity, things we don’t know and have a tendency to bite us down the road. It also reduces the space for conversation and kills the curiosity that complex problems demand.

Instead of “just,” try “what would it take?” It invites learning instead of pretending.

“Just” – In short:

• “Just” = polite oversimplification.

• Masks complexity and uncertainty.

• Shrinks dialogue, stifles curiosity.

• Hides dependencies and risk.

• Replace with: “What would it take?”

“Just” is a false friend. It makes things sound so simple – obvious even. “Just” is a common signal of oversimplification. Not always bad (we all use it), but worth keeping your ears pricked for dangerous wielding of the “just” sword.

Back to first principles

These false friends sound sensible, even noble. They’re what executives say when they’re trying to sound in control. But that’s the trap. They soothe our anxiety about uncertainty, when what product development really needs is a deeper comfort with it.

Let’s not fall victim to the myths that what we are doing isn’t complex. This isn’t like manufacturing. Where we are going, there are no roads (yet).

Product development isn’t manufacturing and it’s not a skyscraper project or the renovation of an old villa. The fundamentals are different to those contexts, and those fundamentals haven’t changed. It’s a multi-pronged search process in a context where:

Payoff is asymmetric: limited (but expensive?) downside, potentially unlimited upside. It’s a search for va
Uncertainty is irreducible: we must navigate the complexity, not try to eliminate it – no matter how attractive that sounds. You can’t control the waves, you have to learn how to surf.
Learning beats efficiency: optimizing for “execution” or “delivery” doesn’t matter if you’re heading in the wrong direction. Figuring out the right question to ask is critical.

These truths change how you approach everything, once you see them. And it drives home the importance of what we know to be true. That customers don’t know what they want, we have to discover that with them. That developers don’t know how they’re going to build it. That also needs discovering. And the safest and fastest way forward is lots of small reversible steps plus lots of feedback loops along the way.

So what’s next as we peer into the future isn’t actually something new. It’s more about using the new tools we’ve built to lean in, learn and master what we already know. The challenge lies in avoiding the hallucinations, the siren song of attractive things that pull us off-course.