I Thought I Was Taking a Detour from Product

I never intended to become a solutions engineer.

At the time, I was working at Microsoft. While I enjoyed the work, my family wasn’t enjoying living in the Seattle area. An acquaintance mentioned a solutions engineering opportunity at Logi Analytics back in Northern Virginia. I enjoyed presenting, liked working with customers, and figured I’d do it for six months, get us back to Virginia, and then find my way back into product.

Six months turned into several years.

What I thought would be a temporary stop became one of the most rewarding chapters of my career. I became Logi Analytics’ first solutions engineer focused solely on our OEM business and eventually helped build and lead a team of six, supporting more than 30 sales representatives. Together, we worked on many of the company’s largest and most technically challenging opportunities.

The role fit me better than I expected. Most of my customers were software companies, and I’d spent my career building software. I could relate to the questions their engineers, architects, and product teams were asking because they were the same questions I’d asked throughout my own career. My job wasn’t to out-talk anyone or simply close the deal. It was to help both sides determine whether our product was actually the right fit.

At the time, I thought I was taking a detour from product.

I wasn’t.

I was standing on the front line of it.

For those unfamiliar with the role, solutions engineering is about much more than giving software demonstrations. You’re responsible for helping customers determine whether your product can actually solve their problem. You answer difficult technical questions, build prototypes, troubleshoot customer environments, and work toward what we call the technical win.

Just as importantly, you’re responsible for recognizing when the answer is no. Sales is understandably focused on winning the business. Professional services, customer success, and support ultimately have to deliver on the commitments made during the sales process. Product has to think beyond a single customer and build capabilities that benefit many customers.

Good solutions engineers sit at the intersection of all those perspectives. Closing the wrong deal might help this quarter’s numbers, but it rarely helps the customer — or your own company. That gives you a front-row seat to where products meet reality.

There are dozens of prospect visits I could talk about, but three have stayed with me for very different reasons.

The first was in Seattle.

Tom, the account manager on the opportunity, and I flew to Seattle to meet with a prospect evaluating one of our products, Logi Ad Hoc. They liked many aspects of the platform, but they had concerns about the user experience and a few quality issues they had already encountered. Because I’d developed a reputation for helping close technically complex opportunities, I was asked to lead the demonstration.

Everything was going well until I tried to close a dialog box.

As I moved my mouse toward the Close button, it moved. I tried again. It moved again. No matter what I did, I couldn’t click it. The button literally ran away from my cursor.

The prospect looked at me. I looked back at him. He smiled and said, “See what I mean?”

There wasn’t much I could say.

We went to lunch.

We didn’t get the deal.

I’ve thought about that meeting many times over the years. Not because of the bug. Software has bugs. But because everything else became irrelevant.

The prospect wasn’t evaluating our architecture, our roadmap, or our long-term vision. He was trying to close a dialog box.

The second visit couldn’t have been more different.

The product UI itself wasn’t the problem. We simply couldn’t get it installed and configured in the prospect’s environment.

The prospect was incredibly patient. They gave our account manager, Keia, and me a small conference room while we spent over an hour on the phone with people back at headquarters, trying one thing after another. At one point, I turned to Keia and said, “I’m about ready to throw this laptop against the wall.”

Looking back, I don’t think anyone was intentionally being difficult back at the home office. Engineering was balancing priorities. Product was thinking about the roadmap. Sales wanted to win the business. I was focused on one prospect sitting just down the hall, waiting for software that wouldn’t work.

That day, I learned something that has stayed with me ever since.

Installation wasn’t separate from the product. It was the product.

On a third evaluation, a large healthcare software prospect raised a security concern that our platform couldn’t address. Rather than walking away, I built an extension that solved the immediate problem. Later, our CTO learned what I’d built and decided the capability belonged in the product.

It was one of the clearest examples I’d seen of a customer-specific solution becoming part of the product.

What started as a workaround to get a deal across the finish line was shipped as a product feature.

Years later, when I found myself leading product organizations, I realized those experiences had shaped my thinking far more than I had appreciated at the time.

Solutions engineering taught me lessons that no roadmap review, planning session, or strategy meeting could. So did time spent in professional services and customer success. But solutions engineering is where you see it first, before the deal is signed, before implementation begins, before anyone has committed to anything. You’re watching your product succeed or fail in real customer environments, with no safety net. If you want to understand what your product actually is, rather than what you intended it to be, that’s where you start.

When I accepted that role at Logi Analytics, I thought I was taking a detour from product. I was wrong. I wasn’t stepping away from product. I was standing on the front line of it.