Trying to reason where the Solution Architect lands. Is it pre-sales? Post-sales? Not sales at all? And where should it land in the organization? Is this title just a fancy hat for an engineer who can talk to customers?
Pre-sales role
When a new opportunity comes up, there should be a tech person included to keep the discussion within bounds. They don't need to say much at the early stages but should be listening to what else the customer is saying and didn't actually articulate. These are the details that make the project successful down the road. They mentioned that managing employee accounts was a pain but said they don't want single sign-on. Sometimes the sales person just notes that they don't want SSO and it is taken at face value. This might be an area to help guide the solution.
So a sales engineer?
This can start with a sales engineer but at some point the decision needs to be made to either keep the customer coloring inside the lines of the existing products or if this is a time for extra flexibility. In general, sales engineers are providing guidance on the product as designed, not straying too far into related fields.
The sales engineer can say, "Why yes our API can do that." Where the customer might need some more hand-holding to ask, "Do you have resources that are comfortable using an API? If not, can we help you with using the API?". The first answer is correct, but the second is what is going to make it successful.
Post-sales role
So if the concern is making the deal successful, then it seems to be post-sales? The bulk of the work is going to be post-sales but not engaging until the deal is signed is always a recipe for misery.
I had a year-long pilot that was well into the roll-out and expand phase. We already had a dozen sites installed when the customer's senior management wanted new metrics on the dashboard. They wanted to expand the customer journey tracking by adding a new phase before the current start. They wanted to track "time to first greeting". The only problem with this is that the signed deal did not have surveillance cameras where they were needed to capture this. The deal had come to us with a strict camera count and positions. We could add this metric using computer vision but only if we had clear views.
This ultimately cratered the deal. I use this example because the failure was the customer not understanding the constraints they were imposing. Easy to change early, impossible to change after the fact.
Not actually sales at all
Coming from an engineering background, this is my default position, but I think it is wrong. The best director in the world can't just show up on set on the first day and do their best work. They need to have read the script and cast the actors. I can't imagine that being a success any more than I can expect product/engineering doing great work when they first hear about it announced as a sales win.
We've established that a Solution Architect doesn't cleanly fit into a single definition and that nobody can really claim ownership of this mythical engineer who can talk to customers.
This leaves us at an interesting point in time. The new, related role of Forward Deployed Engineer is rapidly rising in prominence. It tries to solve the same problem another way. The details of the role rhyme more closely with consulting than SaaS companies are accustomed to.
I have spent my fair share of time deployed to customer sites and regularly offer to meet in person. This model has advantages and may well take over the Solution Architect role. In that case, I could probably republish this blog post by replacing Solution Architect with Forward Deployed Engineer.