I've introduced the technical product roadmap as a document that helps to create team alignment. This document can be used both as a communication tool and as a planning tool. Since it's the source of truth for the product planning, it forces people to align on the priorities. It's important to manage the level of detail in this document, so that it remains easy to read. Technical details can be described in related documents (e.g. a RFC) and detailed stories for the upcoming sprint can be created in a product backlog.

When a technical product roadmap is used then the product backlog will become less important since it is no longer required to communicate the product vision (that's a goal that it was never suited for in the first place).

The focus of the technical product roadmap is on the product features, not on the technical side. However, I think it's important to consider features and implementation together, because they tend to heavily interact. For example, advanced features are usually technically challenging, so we may postpone them. However, there are often alternative options that offer similar benefits, but are easier to implement. By considering features and implementation together, we will be more inclined to explore these options.