Once your team has settled on a functional slice of product to implement, they need to actually do the technical work (such as writing code) to bring it to life.
Technical slicing helps you avoid over-engineering solutions, or choose pathways which add significant schedule risk where it is not warranted to do so. It uses the same principle as functional slicing, where you collaboratively identify options, then choose the simplest of those options as a first incremental step. Except this time, rather than identifying the simplest implementation from a customer’s/user’s (functional) perspective, you are doing so from the perspective of the tasks YOU need to do (i.e. a technical perspective).
For example, to send an email to a customer, you might eventually want to integrate your product with your customer database in Mailchimp or Salesforce and send customised emails based on the customer’s name and circumstances. However, as a first step it might be good enough to send a generic email using a simple email API (such as the Nodemailer module in Node.js). This will likely be considerably quicker and enable you to get feedback on your product sooner. That simple solution might even end up being enough and you decide not to implement the Mailchimp integration. Or you might find that there is more value in making the email capability more sophisticated rather than adding new capability elsewhere.
The point is, slicing at all levels gives you options for delivering shippable product and then evolving it incrementally. Technical slicing specifically gives you a means of having conversations (e.g. between the product owner or customer and the development team) about technical solution options and trade-offs.
The "hamburger method" by Gojko Adkic is a very effective technique for doing collaborative technical slicing with your team. To get the value of a hamburger you need to take a bite through all the layers, otherwise you are just eating lettuce, cheese or a patty on its own.