Selling Problems (and Then Solutions) Instead of Philosophy

(this builds on my June difficult discussions post)

As good product folks, we know that customers must recognize a problem before they consider buying our solution.

Companies that don’t have supply chain issues (or think they don’t) are not in the market for ERP systems. Organizations that don’t think they are hacking targets don’t invest in security infrastructure. Couch potatoes don’t care about traction metrics for running shoes. Households without pets (mostly) don’t buy cute doggy sweaters. We don’t shop for antidotes to unrecognized diseases.

But I often see product managers / product leaders forget this when dealing with internal stakeholders and executives. We push our companies to adopt product-side practices and processes without clearly framing and ‘selling’ the underlying problems. We fail to describe improved outcomes in non-technical terms. I think of this as ‘selling philosophy:’ tossing out-of-context keywords and obscure tech terminology at market-side executives who don’t understand (or deeply care) about the fussy distinctions we techies treasure. I hear product leaders say these to CEOs:

“We need to be more agile and less waterfall.”
“We’re sales-driven, not product-driven, so major deals keep getting priority over roadmaps.”
“Operations keeps telling us exactly how they want us to fix our internal Ops applications, instead of framing up problems.”
“We should move to Test-Driven Development.”
“Product get hundreds of feature requests monthly: from every department, user, and channel partner. So we need every submitter to complete a business case with their request.”

Cart before horse. (Recommendation before problem.) For many CEOs and sales/marketing-side leaders, these are meaningless phrases that sound like whining. I’ve watched go-to-market (GTM) execs listen to the first three minutes of a two-hour ‘Kanban vs. scrum vs. XP vs. SAFe’ argument and walk away disgusted. (“The reason we don’t get much out of Engineering is because they spend all day debating how many architects can dance on the head of a pin.”)

As product leaders, we should also apply our product skills to internal organizational change. For me, that means avoiding technical philosophy and overloaded catch phrases – instead building shared understanding of problems based on detailed, specific internal incidents.

My approach to these discussions:

We must agree on a problem before offering solutions. GTM execs don’t care about technical philosophy; they do care about revenue and business goals and productivity.
Don’t assume GTM execs know what we mean by tech-side keywords. ‘Validation’ and ‘product-driven’ and ‘MVP’ may be meaningless to them: already dumbed down in the business press or hijacked by big consulting firms who sell transformation snake oil. They typically hear ‘agile’ as ‘build all the stuff I want faster.’
Assume that the GTM side doesn’t see the patterns we see on the tech side, or attributes different causes. What seems causally obvious to us isn’t. We have to find enough company-specific examples to demonstrate a problem worth solving.
It’s self-defeating to adopt an intellectually superior attitude. Selling is hard; marketing is hard; finance is hard; running a company is hard. Looking down on coworkers who can’t code is a fundamental mistake. We don’t ask product managers or engineers to figure out ‘account-based selling’ or ‘search engine cloaking.’ We need to leave our egos at the door.

An Example

Poor problem statement: “we are letting our biggest customers define the roadmap, including detailed technical specs. Product needs to do broad market validation first.”

This comes from a development process viewpoint with lots of internal product assumptions. It’s not always obvious to the go-to-market side that we have a problem. Isn’t that how it’s supposed to work? We’ve jumped right into cryptic keywords (‘market validation’) and process changes without framing the issue. I’d expect responses from my CEO and VP Sales/CRO like:

“Of course we do that! Our customers know what they want, and go the extra mile to write detailed specs for us. You should be thanking them/us for doing your job.”
“Our sales teams talk with a hundred customers each week. Product managers get a few conversations per month. Sales represents the Voice of the Customer.”
“Market validation is a waste of time. We poll the sales and marketing teams weekly to hear what’s new. And last week they told us that everyone in our segment wants X.”
“I’d love more doing, less arguing. Our executives and customer success teams are experts at freight logistics | movie reviews | orthodonture appliances | ecommerce auctions | whatever. Your developers/product managers aren’t. We know how these systems should work.”

The GTM world view can be quite different from the product/development worldview. For them, saying ‘yes’ to all customer requests should be our goal. They believe that buyers understand our internal systems well enough to write user stories for us. Especially within Sales, they rapidly generalize from 2 similar demands to universal market needs. Where you stand depends on where you sit.

So let’s reformulate our problem statement and change the dialog:

Product: “We have a systematic problem. Often, incoming requests from our biggest customers are less important than our agreed roadmap, and tend to be technically incomplete/incorrect. So we’re wasting effort that should go toward strategy and commitments.” This sounds less panicky, less judgmental, and invites discussion.
CEO: “We don’t do that.”
Product: “Well… Three weeks ago, the exec team approved HugeCorp’s request for nine-factor authentication. We’ve pulling staff from This Year’s Major New Innovation, which will slip by a month. That’s $25M in ARR that we’re delaying.”
CEO: “But everyone wants nine-factor authentication. Sales said so.”
Product: “We haven’t identified any other customers by name, and their use case is muddled. I don’t think more than two of our 800 customers would use it.”
CEO: “OK, I guess I see your point. But that’s the only time we’ve done this, and HugeCorp pays everyone’s salaries.”
Product: “I hear you. But last week, we also promised to build a custom app integration for MassiveCo. Wasn’t planned, sized, or on the roadmap. That pulls from the same team working on This Year’s Major New Innovation. Could push that $25M ARR back another month or more. And conflicts directly with that commitment to HugeCorp.”
CEO: “Hmmm. Just two times, then. Engineering has lots of capacity and 20 open positions.”
Product: “And Behemoth Inc just sent over their spec for hybrid cloud data synchronization. It didn’t make sense to our architects, and probably won’t work. But they are waiting for a committed delivery date. We’ve told the Board that we’ll start migrating on-premise customers to hybrid clouds by December, and this pulls from that group. I think we should point Behemoth toward one of their system integrators instead of doing this ourselves.”
CEO: “Hmmm. Maybe. I’m starting to see the pattern. Tell me more about how we’re approving these and who is putting together business cases or sizing work…”

Note that we’ve framed a problem in technical and business terms, gathered a series of recent instances (evidence), and started by identifying (‘selling’) the problem rather than the solution. We’re prepped to address objections to the problem itself: recency bias, pattern non-recognition, subtle impact on customers or revenue, and sales goals that are misaligned with company/product goals. We hold off pitching new workflows or approvals or committees or ticketing systems or additional product management hires or business case templates until the CEO recognizes that we have a problem worth confronting.

Another Example

Poor problem statement: “We’re not making money on the custom development that Leviathan Bank pays us for. Product needs veto power on all specials.”

I’ve seen this many times: companies seek out bespoke software projects from major customers to bring in immediate cash. It ignores the real cost of one-of-a-kind development and the fundamental economics of the software business. But I’ve gotten better responses when talking with CEOs and CFOs (and CROs) about this in terms of investor valuations.

Product: “These big custom services projects for Leviathan may look like revenue we want, but I think the Board and our investors would be upset to hear about it.”
CEO: “Nope. They are excited that Leviathan is a $1M+ account.”
Product: “Backing up a bit, investors typically value recurring subscription software revenue at 6x or more, and contract development services at 1x or less*. They want scalable software growth, where adding more customers doesn’t force us to do more development work. Selling the exact same bits hundreds of times.”
CEO: “But Leviathan needs this work and are willing to pay us for it. A dollar of revenue is a dollar of revenue.”
Product. “Hmmm. I think we’re spending most of that services contract doing the engineering work. Pretty sure that this quarter’s $280k Leviathan project will cost $200k+ in development, which leaves maybe 20% margin after we pay the account team. Signing up one more $75k/year customer on the core platform would be $70k profit – same as for that one-off project – at 90%+ margin. We could add ten mid-tier customers faster than we can complete this piece of work, which would boost valuation 10x versus Leviathan. Doing this project may actually reduce our exit value.”
CEO: “Doesn’t sound right to me. You’re the product guy, not our CFO or venture investor. Let me run it past some of them.”
Product: “Absolutely. I just want us to get a better exit for shareholders. Please let me know what the financial folks think.”

Again, we recognize that not all execs are fascinated by the mechanics of software development, and may have very short-term views of revenue. But they are all interested in financial exits and how investors value companies. And we need to call out specific instances rather than philosophy. We’re motivating a discussion that will take a while. (BTW, handy if you’ve already had this very discussion with your CFO – who is prepped to talk it through with your CEO. But never – ever – go around the CEO to board members or investors.)

Once we’ve all reached consensus on shifting away from heavy services offerings, we can look for solutions: shifting sales focus toward middle markets; partnering with integrators for custom work; engineering away much of our onboarding effort; not paying sales commission on services; creating incentives for customers to migrate to the latest supported release; etc.

As product leaders, we think about how the entire company operates. We work to be a trusted executive voice for end customer value – less departmentally focused than others around the (virtual) conference table. Sometimes issues fall neatly to Engineering/Design/Product, but often we have recommendations or suggestions for our C-level peers. Important to take our humility pills every day, frame discussions to fit our audiences, understand company reward systems, and focus on where we can motivate change.

Sound Byte

Internal company issues can be just as complex or misunderstood as external customer problems. Getting agreement about solutions usually requires us to agree first on underlying problems. When framing up core product/development issues for less-technical audiences, we need to focus first on root causes and then on tangible business outcomes.

*Some recent SaaS valuations have been much higher than 6x ARR, but the argument doesn’t change at 11x or 18x. And many outsourcing/professional services sell for less than 1x annual revenue. CEOs should ask their investors for benchmarks. Many would prefer $150k of real SaaS ARR rather than $600k of development services.