It's possible to write flawless code for a feature nobody needed. That's a more common failure mode than most teams like to admit, and no amount of engineering discipline fixes it after the fact: the mistake happened before a line of code was written.
What strategy work actually looks like before building
It's naming, specifically, who the feature is for and what problem it solves for them, not in the abstract, but concretely enough that you could describe the exact moment someone would reach for it. It's asking what happens if you don't build it at all, which is often the fastest way to discover a feature was solving a problem nobody actually had.
Strategy and engineering aren't sequential; they inform each other
The best outcomes come from strategy and engineering working together from the start, not strategy handing off a finished spec to engineering. Technical constraints should shape what's realistic to prioritize, and business goals should shape which technical trade-offs are actually worth making. Treating them as separate phases is how teams end up building the wrong thing extremely well.