When Your Solutions Engineer Becomes Your Product Manager

There’s a fundamental misunderstanding about product ownership.

I think the narrative around product managers is great - that yes, we should have Ben Horowitz (of the Hard Thing About Hard Things) PM who:

does act as effective challenge to C suite oversteering
doesn’t just roll up roadmap for approvals
doesn’t just project manage the product
does chase what problems exist internally, what clients want externally, and how the market is changing

But a lot of the time product management does just wind up as the Horowitz type one or type two trap. An interesting symptom that happens, if product does skew towards these kinds of problems, is that product management thinking and problem solving starts to seep into other parts of the organization, if the skills, knowledge, and cross function literacy exists.

tl;dr - When product management fails to define and solve the right problems, adjacent functions fill the vacuum. Our organization lacked deliberate pre-sale and post-sale strategy. This was inelegant from a product and strategy perspective, but it fit the ‘ship fast, break things’ mold—build something great and respond to the loudest voices. Eventually, I defined both our internal problems and how we could reposition our product to outcompete alternatives and simplify our value proposition. Even with clear problem definition, market analysis, and buildable solutions, organizational circumstances can kill good product thinking.

Context and chosen problems

In 2021 I was picked up by a security awareness vendor after they got an intimate view of how I was managing their platform as a client. This was a step up from local consulting work—bigger scale, more complex problems.

The platform itself was unique in the security awareness space in that it was a software/SaaS/onprem solution, when every other vendor in the space was a cloud provider selling licenses on shared infrastructure across all clients. This made the platform super powerful in that you could run it wherever you want (internet facing or not) and use whatever domains you owned (or with no properly configured domains at all, if you wanted.) Super powerful, and the wrong tool for most clients. I was brought in to help them close a top ten financial bank where they were just starting the sales cycle, where the main rep and technologist in NA was the president - with everyone else basically just being talktrack without the technologist.

I was part of North American operations with a team of less than ten employees, with the same (including the platform’s creator) being mostly Swiss based. The main divide between operations, aside from cultural and timezone differences, was on how and what we sold. Our NA operations sold licenses without managed services but with our own support team, and our European operations sold licenses only with managed services attached to them.

These fissures, and the high skill bar for the product, meant that we had some understandable issues:

we had no standardized onboarding materials or program for onboarding clients
we had no non-support CS facing materials on diagnosing and standard workpaths for resolving inbound client issues
we weren’t roadmapping features on frontend or backend that would have reduced support workload
we didn’t have clear lines of demarcation between SE, CS, and support (didn’t even originally have any SE or CS)
we didn’t have a defined CS or SE function
we didn’t have defined client types, and weren’t targeting them specifically

And to some degree, these were the chosen problems. The executive bet was clear: grow ARR fast, optimize operations later. Build a fantastic product, close big deals, get bought, sort out the rest later. We closed that Fortune 100 financial institution after an eight-month sales cycle, and did get bought by another startup. But “later” arrived when we’d already trained customers to expect high-touch service we couldn’t sustain.

When we were bought, I became Senior Solutions Engineer, but my actual scope was far broader. I operated as the de facto Head of Customer Success for North America while also serving as the Technical Account Manager for that top-ten financial institution. In practice, SEs at ThriveDX were the organizational glue—we handled pre-sales, post-sales, managed services, escalations, roadmap input, and even CS education and materials.

if this sounds like a lot, it was. I reported three ways: to the CTO, the Chief Solutions Officer, and the VP of Sales for North America. Our SEs were rockstars but global with fiefdoms/patches. Our support team were technical saints but overburdened by relationship management and low-level fixes that could have been prevented with UI and UX changes. We were also a startup that had been purchased by another startup that became part of a global conglomerate.

But post acquisition, we also made both predictable and unconventional choices

we established a SE function, formalizing pre- and post- sales
I built user-facing training videos for how to do most of infrastructural config and guides
I built internal-facing sales training artifacts for everything from understanding the industry, to competitors in the space, to buyer profiles, to battle cards
we changed CRM platforms again, and again
we established a CS function that I almost led that was focused only on renewals and not on relationships (but that’s for another post)
I built a RACI chart defining different functions and escalation paths
I built CS artifacts for how to diagnose client issues, what questions to ask, and standard language for troubleshooting

These were tactical (as opposed to operational or strategic) wins that didn’t address the strategic question: what business are we actually in? High-touch managed services, or self-serve software?

My earliest conversations with the Chief Solutions Officer centered on this tension. We both agreed: you can’t scale high-touch managed services. You can’t copy-paste Solutions Engineers.

The limits of treating symptoms, and needing to reframe the problem

These treatments only went so far, because even despite additional controls of

entirely restaffed NA sales team
entirely rebuilt support team
a designated chief product officer
a fully rebooted marketing office
fancy business consultants asking and receiving for our pain points and solutions

None of it actually got past the delicacy of “what was our business” or “who are we selling to, and what are we selling, for what reason”

We hit flash points in two contexts that made things clear.

Context one: The multitenancy math problem. An old member of the sales team—someone who’d been overlooked during earlier rounds of professionalizing the North American team—tried to sell a 30-organization multitenancy deal for $5,000 total. Our standard pricing for small organizations (sub-200 users) in North America was $5k as an easy-to-sign, move-to-the-next-one deal. This rep proposed selling 30 distinct organizations for that same $5k, with onboarding training and ongoing support included to each of those 30.

There was no version of this deal that didn’t hurt us. $5k annual recurring revenue for 30 organizations works out to $166 per tenant per year. With onboarding and support included, we’d be losing money on every interaction. But selling licenses-only, leaving them to figure it out? They’d misconfigure the platform, generate support tickets anyway, blame us when it broke, and we’d damage our reputation with 30 organizations at once. Our options were financial harm through a net negative contract, operational damage through throwing messy problems at already exasperated support functions, or reputational damage through signing onto something we know we couldn’t or wouldn’t support well. I flagged all of this to VP Sales for North America, and we shut the sale down.

But the episode revealed two valuable insights: First, this sales rep was the only one actively selling our security awareness product. The rest of the team was selling secure coding training instead. When I asked why, other reps were explicit: “We don’t sell Lucy because we can’t.” The product was too fiddly, broke too often, and generated too many support escalations. Second, this rep had been fired once already—during the sales cycle with the top-ten financial institution—because they’d promise deliverables without following through, escalating to multiple SVPs and getting removed from calls. I ended up closing that deal because I had the artifacts, technical knowledge, answers, and soft skills the rep lacked. They’d been rehired, then overlooked again. This was part of the growing pains of North America professionalizing and standardizing.

Context two: The federal agency prototype. We pursued a deal with a federal agency that had 30+ offices and branches. Similar multitenancy challenges, but with an added problem: we’d be competing against cloud-hosted solutions that didn’t share our blacklisting vulnerabilities. If one administrator misconfigured their instance on a competitor’s platform, it wouldn’t take down email deliverability for every other office. On ours, it could. We invested dozens of hours—pitch materials, a custom frontend derivative built by operations—and the deal fell through. Even if we’d won, we would have sold it with support hours attached, but it remained expensive for us to deliver and risky compared to how straightforward it was for our competition.

These misses were lessons if we were listening:

Salespeople had no intention of selling a fiddly product that broke, especially when pipelines were full of low-value prospects we hadn’t properly segmented or targeted.
Training dozens of administrators how to use our platform—without safeguards to prevent them from misconfiguring things—was a losing game both from a white-glove training perspective and from the exponential support time required post-sale.
- even if product did put in place manual safeties that had to be taken off, that still didn’t solve our pipeline, customer expectations, training needs, or existing clients
Neither of these clients had actual specific or difficult needs. They were generic use cases that should have been easy wins. It was only the back-to-back multitenancy in different contexts that forced the reflection

We’d been asking “how do we make our platform easier to use?” when the right question was “who are we actually building this for, and what job are they hiring us to do?”

We had been selling, and positioning, the strongest most powerful security awareness solution with infinite tailoring… but to administrators who didn’t want to learn how to technologically operate the platform nor technically steer their programs towards outcomes. We were selling big brain platform to those wanting bargain purchase.

This echoed and forced a deeper and more acute reflection on what we were doing and why. A year earlier just after we were bought, I was considered for and championed by some of the C suite to lead the CS function, and gave a pitch around my thinking for the function and what problems I thought the function needed to solve and how it would need to be supported. It was a mostly internally looking presentation around what we don’t know, and the consequences of those things we didn’t know.

If my pitch for head of Customer Success was ‘here’s all the collateral damage from things we aren’t managing and don’t know about our clients’, my redraft was to both focus on what clients wanted, what they get from platforms or consultants, and how we could solve our own problems.

Reframing client wants and needs

[This section is still in development]

So, how did it go?

Lol, it didn’t. I got laid off in a fourth round of company layoffs as the only and last NA SE asset to go. Every non-revenue generating function was trimmed.