If you've been around the tech world, you've probably been bashed enough with the concept of 'laser focus'. The idea behind this metaphor is to convey the importance not to drift away from core objectives by having an almost binary approach to your selection process of what to work on next.
There is a side effect to this simplified approach though that's brushed over and that makes it difficult for many to focus at all: the tunnel vision.
That is, in order to focus this bluntly, you need to let go of everything else and this creates difficulties.
Many engineers struggle with preparing for the future. They tend to want to over anticipate things, and they can easily (and at times rightfully) see a binary effort of 'laser focus' as basically tunnel vision or short sightedness. This is something that create often frictions - especially between non-tech senior leadership and engineers. "- We asked you to focus on X. - Yeah but all these things will drop, and it will bite us later."
On one side, someone is promoting the 'laser focus' - almost caricaturally as seen on social media - to make sure resources aren't wasted while the other side is obsessed about anticipating future problems - with often a clouded read on risk (probability x consequences).
The truth is that the perfect focus execution isn't so binary. The way to stay focused while retaining perspective is achieved by building a stiff framework on specific areas:
Clear understanding of the current product direction. When you define a product to build, you start with an end user and a given purpose. Out of this effort, you'll extract a number of similar individuals to size a market. Out of this market, you'll identify deviation and focus on the 80% commonality. This will educate the definition of an identity of the product which will simplify all future conversation: "this feature doesn't belong with our product". If you do this work, you will be able on the spot to decide whether an effort makes sense, and if so, when.
You create a stable point in the intellectual storm, aka focus.
On the opposite, teams that tend to explore everything and anything are basically telling you they don't know what they should build. This often looks like feature packing. They build as many capabilities as possible convinced that the swiss-army knife will open all markets. This rarely works as the tool that does it all easily does nothing well.
And worse, you actually loose the focus while feeling that you're progressing and iterating fast.
Precisely scoping and size the effort/difficulty is the second dimension to product direction.
Product direction gives you a north start. This effort is your turn-by-turn journey. If one is focused and the other isn't, nothing is focused.
It's easier said than done because being able to anticipate how long an effort is going to take is one of the most common problem and recurring difficulties. On top of it, you need to know how many resources you need and projecting the difficulties to overcome in order to prioritize the work towards the leanest path.
This skill comes from walking the path, and like point #1, you'll have to dedicated some time and resources to build this knowledge in-house. *Bringing in people who have transferable expertise in this field will make a dramatic difference*.
There are processes to structure this work, but it never hurst to be conservative when doing this effort.
It's a lot easier to add to a scope than to remove.
Designing modular systems that can quickly change should something happen bring a lot more than technical capabilities. You bake into your tech the guarantee that you aren't going to be stuck in a dead end through internal APIs, isolated services and split purpose parts.
Very practically speaking this can be passthrough APIs to create a well-defined interface that will abstract complexity later on. This can be a multi PCB design as to have swap-able components. This can be over sizing mechanical parts to facilitate new components in the future. The list goes on.
Knowing what to do and what not to do is only achieved while going through it in the first place. This is also why it's important to create the opportunity in your current teams to develop such knowledge by deviating from the laser focus in effort with clear goals and resource constraints.
But in the end, if the tech is flexible, it allows to contain the debate because the risk is contained. You achieve balanced focus.
In conclusion, you can apply the 'laser focus' verbatim, but you'll miss out a lot on execution and will deal with internal frictions as you figure out the details that matters. You'll have to accept that focusing implies dropping other important things. If you seek nuance (as you should), you need to bring in skill and develop it internally. Control the effort spent, take away the lessons and share the knowledge. Make sure there is no gap in the plan and maintain consistency.
There are many 1-2-3 steps to go at it, but if I can leave you with one it'd be this: 1/ Repeat your 'laser focus goal'. Put it on signs, repeat it at all hands. It should say "We're building X for Y by Z"
2/ Kick off side efforts. Explain 'why' internally, control how much and how long.
3/ Take away lessons, share the knowledge internally through demo days or engineering all hands. Always invite the whole company. Each of these demos should cover the problem, the journey, why steps were taken, what was learned, what was decided, summary conclusions and next steps (even if deep in the future).
Ultimately, in this context, you're looking to promote a balanced approach to focus, not just an entertaining journey to a solution.
Focus isn't supposed to be a religion (so many things in tech become one), it's a trail path for you to get to your final destination. Take control of it, don't let 'bumper stickers' preach control you.