I’m sometimes pulled into difficult discussions with CEOs, where I’m trying to describe systematic product-side failures that directly conflict with how the CEO sees the world. Even after dozens of similar discussions, I have only moderate success. But it seems worth framing this leadership-level challenge from both sides.
For me, this is typically at a company in a heavily tech-dependent business (ecommerce, banking, medical devices, gaming…) that’s not directly selling software for revenue. Or an early-stage enterprise software company with a hard-charging sales executive in a first-time CEO role. Or where the CEO has very deep market/segment experience but isn’t familiar with (or deeply interested in) how building software is radically different from manufacturing physical goods or selling consulting services.
Two of those tough discussion:
- The CEO is massively overloading the technology team. Too many initiatives, a dozen #1 top priorities, “this one is easy,” a strong belief that we must do everything that’s important, “figure out how to get this done by September 15th.” This creates a downward spiral of shuffling staff from half-done project to half-done project, massive productivity lost to context switching, missed deadlines, deep frustration, and staff departures among engineers and product managers.
In parallel, deep frustration and accusations of development incompetence from the executive team — and calls for ever-deeper reporting on exactly where every development hour is going. “I don’t get you guys. My sales team has metrics that let me tell at a glance how every single individual is doing. I just want to know how much development capacity we have available.” - CEO and stakeholders believe that their short-form ideas and one-line project charters are complete enough/correct enough for the whole company to execute against. Product managers and engineering leaders push for much deeper analysis – validation interviews with actual end users; separating problems from solutions; insisting that new projects must prioritized ahead of (or behind) other projects; technical architecture reviews; quantitative outcome metrics; rough sizing and phasing; mockups/experiments/pilots with real users – but can be seen as lacking urgency or process-heavy or not understanding the business. These CEOs believe that business-side “specs” and demands are complete, thoughtful, and obvious enough that more competent folks would leap directly into coding.
Notice that these are conflicts about core beliefs: how we get things done, how easy (hard) it should be to schedule software delivery, who makes semi-technical prioritization decisions. We (development/product-side folks) think it’s completely obvious that stakeholders often misunderstand end user needs; that PostIt notes are not solutions; that complex systems interact in complex ways. But I observe that what’s obvious to product managers isn’t necessarily obvious to CEOs. And vice versa. One side’s “obvious” may be deeply counter-intuitive to the other.
Buzzword-y technical lectures (“that’s waterfall, not agile” and “we should shift from sales-led to product-led growth” and “we get too many P1 interrupts” and “that’s going to run up a ton of technical debt” and “the teams need more psychological safety” and “creating software is more like playing jazz than building fences”) may sound like excuses or philosophy or techie BS. We lack shared context. If our executive team doesn’t already have a deep appreciation for software development as a complex craft rather than an assembly line, these land as meaningless phrases from overpaid, whiny, privileged snowflakes who lack work ethic and business savvy. After all, the company needs to get everything done on time. And we’ve promised the Board 35% revenue growth this year. GSD. (“Instead of excuses, tell me exactly what the existing team is doing and how many developers we’re short. I’ll open up more positions.”)
So What Do We Do?
I don’t have a perfect magic recipe. And this doesn’t always have a happy ending. (Sorry.) But some things I’ve tried with partial success:
1. Bring heaps of empathy to difficult product-with-executive discussions. It’s easy for technical/product folks to demonize non-technical folks and executives: to think of them as stupid, or intellectually lazy, or somehow impractical and unworthy. (Hint: GTM folks may have nearly identical beliefs about the development organization.) We’re most effective when we bring a generosity of spirit, an appreciation for what other groups do, a sense of the pressures they are under. (Most salespeople are paid and rewarded and promoted for being short-term thinkers who beat their current-quarter targets.) Talking down to our execs makes us sound like Sheldon Cooper.
2. Assume they don’t see the pattern, but they might if we identify specific instances with specific business impact. I’ve rarely gotten a CEO to agree that “Sales and exec team keep breaking the roadmap with urgent surprises.” It lacks credibility, sounds like whining, and directly contradicts what the CEO demands of our sales teams. (“Yes, we closed Goldman Sachs for $4.5M this quarter, which is a huge win. Yes, I personally approved sending that whole sales team to President’s Club and gave a Tesla to the account lead. Yes, I’m pushing for many more deals just like it. Tell me why we should have walked away from seven-figure deals because of a few little feature requests.”)
Instead, I build a list of specific instances where particular CEO interrupts pushed out things of higher value to the company… where we’ve forgotten about the pain while celebrating the win… where I can relentlessly (but humbly) frame development as an exclusive OR process with big new demands inevitably delaying current commitments.
- “Remember when we took on that big currency conversion feature for Citibank? We pushed the SOC2 audit back two quarters. As predicted, the renewals team thinks that will cost us a dozen other bank customers.”
- “And we pulled the database team off merging our two CRM systems to support Toyota’s proprietary data import structure. So Marketing won’t be able to reach half of our inactive customers until next year and our renewal rates will continue to suffer.”
- “And Business Development signed a partner/reseller agreement with Accenture, which is great. We didn’t do any technical due diligence, though, and Accenture has a long series of integration demands for our Marketing Automation workflow. That’s a direct conflict with the SEO improvements and lead qualification that Sales/Marketing say they need to drive an incremental $15M-$20M next year.”
- “And we spent $1M over 5 months improving the admin panel for Deutsche Telekom, which was a surprise and made us miss Apple’s deadline for new iOS privacy features. Turns out we lost that deal anyway, while thousands of consumers are submitting iOS help tickets each week.”
- “And… and… and…”
Note that I’ve directly tied business impact to deprioritized work. If there’s no business-side cost to piling on more stuff, then this comes across as grousing about decision-making authority or a quality-of-techie-work-life-balance problem. Identifying a series of instances gives our CEO a chance to see the underlying pattern. (“OK, let’s talk about how we get product/development involved earlier without losing deals.”)
Similarly, we can frame the “idea on a PostIt isn’t a product plan” problem with company-specific instances:
- “We skipped discovery on the patient record integration project, and delivered exactly what was requested exactly on time. But Compliance shut it down because it’s not HIPAA compliant, and we’re using an outdated API. We should have spent a few weeks digging in before we committed full development.”
- “And… giving Customer Success their own BI reporting tool would have brought down our database during peak times. We sat with CS, unpacked their real needs, wrote and optimized 4 reports for them, and finished in two sprints. Saved a year, $150k in license fees, and a ton of training. Implementing their original request would have been disastrous.”
- “Adding more new products to our ecommerce site may make sense. But we’ve sold almost none of the last three products we added. Saw none of the anticipated revenue boost. Not sure if that’s an internal issue or a lack of consumer interest… a few weeks of discovery would help identify what’s broken before we sign new distribution partners and repeat the cycle.”
- “The marketing team chose a new email campaign product without input from product/development. Looks good from the outside but doesn’t integrate with our CRM may have GDPR shortcomings. Marketing is committed to cutting over this month, but Sales and Support and Engineering all have big concerns.”
- “And… and… ”
Systematic cross-departmental problems look small individually — but crush us in the aggregate. So a long-enough list makes it harder to write off single instances as not-so-bad or doesn’t-happen-very-often or just-this-one-time or yes-but-this-worked-out-OK. If we can’t generate a solid list, then the problem may be elsewhere.
3. Have a Product Leader in the C-Suite. Product managers are deep in the organization. Individually, they often lack visibility and access to senior management. Subtle arguments and long-term concerns are buried in monthly slide decks and one-line status. Getting face time with executives is tough, awkward. Product managers are called in when something blows up, but rarely invited to share good news. And arguing with the CEO about business priorities can be a job-ender.
So IMO having real product representation in the C-Suite is essential to making good product decisions. Having someone who pushes for more inclusive processes; who spots problematic partnerships long before contracts are drafted; who fights for external customer value ahead of departmental reward structures; who humbly dismembers a poorly considered proposal. Someone who directly manages and mentors and protects individual product managers, appropriately elevating their concerns. Great product leaders are bilingual: able to talk as cogently about revenue recognition and go-to-market strategies as usability and application security.
Titles vary. It might be a VP Product or CPO or VPEng/CTO with excellent product chops. But if no one consistently embodies good product thinking in the room where it happens, we’ll always be a day late and cleaning up one preventable product mess after another.
And if there’s both a VP Product and VP Engineering, I fervently believe they must be shoulder-to-shoulder in larger executive meetings. Aligned, synchronized, having their own difficult discussions behind closed doors. Otherwise the CEO can pit them against each other in the “is it Product’s Fault or Engineering’s fault that we get so little done?” game. A sure way to lose trust and start hemorrhaging talent.
Sound Byte
CEOs and go-to-market executives are mostly not product folks and may have radically different viewpoints on how software is created. As product managers and product leaders, we need to understand our internal audience and find good tools to advance our positions. A long list of specific problems (and their business impact) may be more effective than philosophy or buzz phrases.