I agree with your characterization in general. If all someone has is an idea and no relevant experience to back it up, run. I can’t stand people like that.
But there’s one type of ideas person I’m thrilled to work with. Someone with deep and successful experience in sales. The head of sales at my company is also relatively product oriented and boy, he just has a knack for what customers want.
In general, I think many engineers can do some product management. We can figure out basic accounting and finance. But the idea of making a cold call to sell dental software, or chasing down school principals at an education conference is almost as foreign to most software engineers as CS is to most sales folks.
There’s a role called sales engineer that typically exists in the sales organization but requires a technical background. From the engineering org’s perspective, your SEs are there to make sure sales doesn’t oversell or undersell. At my company your pay is commission-based but with a higher base than sales proper.
Solution Architect is another common title. As someone else mentioned, Developer Relations is at least adjacent though that tends to be less salesy and, depending on the role/company, may be more focused on community aspects than building demos and the like. In any case, at software companies, there are definitely customer-facing roles that are more technical though they may not involve a lot of direct coding. For non-field roles, product management qualifies as well.
I would say an SA (Solution Architect) is very different from an SE (Sales Engineer) in one fundamental way: the SA is focused on delivering value post-contract and the SE is focused on making sure the org is able deliver the value promised by working with sales in the pre-contract phase. In some smaller companies or organization within a company, I can see these roles being performed by the same person but in general that distinction between pre and post sales has been my lived experience.
SA people that I have met so far (30+) can architect and more importantly talk about and market the solution. But the execution is often times lacking. And that is solely because the execution is less important. (If the contract is big enough SA can always lean on product engineers or hire contractors to execute).
Being the engineering contractor to SA organization is daunting to a programmer, but rather rewarding.
Where I work, SAs are pretty much technical pre-sales. (There are also chief architects who are somewhat related.) If a customer needs ongoing post-contract support, they can buy a TAM (technical account manager). We don't have sales engineers.
(When I worked for a long-ago hardware company, system engineers (SEs) were pretty much the equivalent of SAs where I am currently.
In my company, all of our sales people have a technical background. They are not the best engineers in the company, but they could do the job if they had to. More importantly, when faced with technical people, they are not completely clueless.
Agreed. I have a thousand tools mastered to solve any software issue quickly. But people issues can still stump me for days. Both skillsets take dedication and years(decades?) to master.
But there’s one type of ideas person I’m thrilled to work with. Someone with deep and successful experience in sales. The head of sales at my company is also relatively product oriented and boy, he just has a knack for what customers want.
In general, I think many engineers can do some product management. We can figure out basic accounting and finance. But the idea of making a cold call to sell dental software, or chasing down school principals at an education conference is almost as foreign to most software engineers as CS is to most sales folks.
Salesperson + engineer = superpowers