I've been the first engineer on a team more than once. At Facebook I was the first engineer on the business development team. At Oscilar I was one of the first engineers, period. And on my own projects, I'm the only one.
In every one of those seats, the same trait mattered more than raw coding ability: caring about why you're building the thing as much as how.
There's a name for this — the product-minded engineer — and it usually gets described as "engineers who think about the business." That's true, but it undersells it. When you're building 0→1, there is no finished spec waiting for you. You're discovering the requirements as you build. If you wait to be told exactly what to make, you'll build the wrong thing very efficiently.
CoachMyChess didn't start as "distributed analysis of chess games." It started as a frustration I felt as a parent in a tournament parking lot: I have no idea what my kid actually needs to work on. The tech followed the problem. If I'd started from the tech, I'd have built a powerful engine no 7-year-old or their parent could use.
A few things I try to do, in every seat:
Ask "why" until it reaches a person
Why this feature? Why does that reason matter? Keep going until the answer is about a human trying to get something done — not an internal metric.
Get close to the actual user
Sit in on the sales call. Read the support thread. Watch someone use your thing without you narrating over their shoulder. It's humbling, and it's the best signal you'll ever get.
Let the goal pick the trade-off
Speed versus reliability, simple versus flexible — there's rarely a universally right answer, only the one that serves what the product is trying to do right now.
Engineering is solving human problems with software. The more you understand the humans, the better the software gets. That's the whole philosophy, and it's never once failed me.