H3ATHER IN TECH | THE PRODUCT SH3PHERD

The Glass Ceiling Has an Immune Response

Mon, 20 Apr 2026 14:56:46 GMT

Women Make Up Over Half of the College-Educated Workforce

Women currently make up about 58% of college students (earning 62.6% of all master’s degrees and 57% of all doctoral degrees) and make up 51% of the college-educated workforce. These stats seem to indicate that women are more motivated than ever to pursue a professional career. This is great, right? (I mean, unless you are a tradwife or a misogynist asshole.) Yay us! We finally achieved equality! High-fives all the way around! �� …

��

Right. I think we all know that’s not true, and if you recall my prowess in college statistics, I am awesome at using statistics to make things look wayyyy better or worse than they actually are. In this case the fact that there are now as many women in the professional workforce as men these days actually makes the inequities even more stark. Women still only earn about 82% of what men earn and they hold only 29% of C-suite positions . Put more succinctly, while women make up a (teeny tiny) majority of the workforce, they make up less than a third of executive leadership. All things being truly equal, half of executive leadership should be women, but that’s not the case; the numbers aren’t even horseshoe or hand grenade close.

The biggest hurdle for women is the first promotion to manager – the ‘broken rung’ ( defined in 2019 by McKinsey & Company and LeanIn.org ) preventing women from climbing the corporate ladder – and it’s the very first rung in the ladder. In 2019, only 72 women were promoted to manager-level roles for every 100 men (41.8%). The gap has narrowed since then (93 women to every 100 men in 2025, or 48%). However, according to LinkedIn data the percentage of women hired into top-level management (executive and C-suite – 31.6% in 2019) hit a peak in 2022 at 34.8% and then started going back down each year since, dropping to 32.9% in 2025 (even with more women entering the workforce and more women making it past the broken rung each year).

The broken rung is an interesting name, but a more-apt name might be the ‘missing rung’ because every subsequent rung on the ladder is unstable, with the highest rungs being the most unstable. It’s a lot easier to accommodate a missing rung than it is to navigate an entire ladder of unstable rungs that may give way as soon as you step on them.

In technology, the gaps are even wider. Women represent as much as 48% of entry-level tech hires (almost half), but only 28% make it to management and only 11-21% make it to the C-suite.

So, while women are consistently entering the college-educated workforce in larger numbers each year – even surpassing men in certain areas, the glass ceiling not only remains, but it’s actually getting harder to break. It’s almost as if the corporate machine thinks women are a disease that requires fortification at its highest levels to protect against female infiltration. This metaphor may sound hyperbolic, but I promise you it’s not.

This inequality isn’t an aptitude problem (though it is a perceived aptitude problem, which I’ll explain soon). It also isn’t a motivation problem. Careers are as important to women as they are to men. However, after decades of beating their heads against seemingly bulletproof glass, some women have decided it’s not worth the effort, meaning women are self-selecting out of promotions. So, it’s not just the obstacles that make it difficult for women to reach and break through the glass ceiling. Some women aren’t even attempting to try. In fact, some women don’t even want to get close enough to touch it.

But why? It’s not lack of ambition – women want to succeed as much as men. Women are just better at reading the room. When pursing a promotion they are unlikely to get (this isn’t defeatism; it’s fact-based reality) means having to do so with limited or no support (that men often get unsolicited) and extra emotional labor (that men never have to take on), many women determine that it’s just not worth it.

I was recently at a tech conference for women and I overheard a conversation with a woman who was a senior product manager at a large security software company. The discussion was about moving up to senior leadership and she said she didn’t want to move any higher citing the fact that she didn’t really think she’d fit in with leadership ‘culture’ at her company. After digging deeper, by ‘culture’ what she really meant was she wasn’t a man… or more specifically, she wasn’t a white man. Basically, she was peacing out ✌️✌️ before pursuing what she believed was an exercise in frustration and futility. Whether or not her belief was real didn’t matter. And let’s face it, it probably was. Even if she were able to navigate the obstacles to make it to the top, landmines still exist for women once they get there.

What nobody tells you is that breaking through the glass ceiling isn’t like bursting through the surface of a lake, taking a big gulp of fresh air, and finally being able to breathe easy while you yuk it up with all your fellow executive cronies from the top of Mount Bossyland. The ceiling doesn’t disappear once you’ve broken through it, and broken glass has sharp edges.

The Glass Ceiling Doesn’t Just Block Entry. It Has an Immune Response.

I love what I do, but I often miss the days where I was an IC where I was measured based on my quality of work without having to continuously justify my seat at the table. I suppose I was relatively lucky early in my career, especially since I work in a very male-dominated industry. For a brief period of time, I worked in cybersecurity for the automotive industry. Tech is already male dominated. Cybersecurity is more so. But automotive cybersecurity is the mack daddy of them all. Still, I’ve never felt uncomfortable in a room full of men, even when I was the only woman and I’ve always felt like I had a voice. That being said, since I went to a magnet school for STEM and a college that had a 10-1 male-female ratio I’ve been cultured most of my life to live in a male dominated world, so being the only woman has been a constant in my life and not an anomaly.

Until I made it to senior management, most of the issues I’ve had with gender discrimination have been just blips. I know I’ve been fairly paid and (mostly) fairly titled. I got to a point where I almost didn’t believe that sexism was a thing, or at least I thought that it was being overblown. In hindsight I’m not sure whether I had just been lucky or perhaps I had just lived with it for so long that I was blind to it. It was probably a little from column A and a little from column B.

It wasn’t until I started trying to climb the upper part of the ladder that I realized that my gender was a liability. On some level I had the irrational expectation that, while being a woman may make it harder for me to climb the ladder, once I made it to the top and broke through the glass ceiling, all of those issues would just automagically go away ��.

I was clearly delusional. Not only did they not go away; they got worse. I expected the challenges that naturally come from moving into executive leadership, but I didn’t expect to be constantly asked to justify my existence there.

Once you break through the ceiling, the system doesn’t immediately just welcome you with open arms. It’s not like making it through Hell Week and then suddenly becoming an official member of the elite, since only a specific subset of people needs to navigate Hell Week to get there. Instead, the system generates antibodies fueled by generations of institutionalized bias that continue to try and fight you off. The glass ceiling doesn’t disappear when you break through it. It leaves behind a hole with sharp edges that most women can never completely clear. When a woman finally makes it close the top, she is suddenly weighed down by two jobs – one is the one she was hired to do; the other is to constantly prove she deserves to be there.

The Immune Response Has a Favorite Weapon: The Double Bind.

The ‘double bind’ is a no-win, paradoxical situation where female leaders are criticized for exhibiting stereotypically ‘female’ behavior while also being criticized for not exhibiting stereotypically ‘female’ behavior. If you’re too personable or too supportive and collaborative (stereotypical female traits) you lack leadership capabilities. If you’re too direct or too confident and assertive (stereotypical male traits), you’re being too pushy making you threatening and difficult to work with.

At one of my previous companies, the double bind was doing extra effort throughout the organization. Women like me in executive leadership were ‘coached’ for not being accommodating enough. Specifically, I was told that I needed to be more receptive to the CEO’s ideas and that I shouldn’t just immediately say ‘no’ and shut him down. However, 1) I always entertained his ideas the first time, but by the 3 ^rd or 4 ^th time of rehashing the same thing, it was just more efficient to say, ‘no’ and move on; and 2) most of his ideas were bad (some were kind of meh while others were just WTF? horrific, but almost none were even close to good) so other than stroking his ego, there was no material benefit in coddling him like a toddler – ‘Oh, that’s a great idea! �� You’re so smart! Gold star for you! �� But what if we just table that for now?’ (…orrrrr chuck it over into the abyss of bad ideas so we never have to revisit it again). On top of that, I always pushed back diplomatically and with data. But the net of it was that it had nothing to do with the way I pushed back. It was the fact that I pushed back at all.

On the flip side of that, women who were just below executive leadership were denied promotions into executive leadership for being too nice, too agreeable, and (I shit you not) too positive - she was legit told that her positivity ‘damaged her executive credibility’.

Basically, women were told they were too female to lead, but not female enough once leading. It’s like Lucy always snatching the football away from Charlie Brown, but then the one time she lets him kick the ball, the goalposts disappear and reappear at the other end of the field.

The issue was never about how you behaved. It was about who you were (or perhaps who you weren’t). And you can change your behavior, but you can’t change who you are.

But the thing is that none of this was done maliciously, or even consciously. It’s not like that particular company was led by Dr. Evil and his mini-me sidekick. It’s a system created by years of institutionalized sexism (and racism; the double-bind can also be rooted in racism and it’s most insidious when it’s rooted in both racism AND sexism), where no version of ‘woman’ maps to ‘acceptable executive’ in the system’s psyche. The result is authority asymmetry: some leaders are allowed to be ‘in progress’; others must be ‘net positive’ at all times; some leaders are given full autonomy and trust; others are scrutinized and questioned about every decision they make. And the difference between how one leader is treated versus another is based on who they are and not how they behave, nor their proven level of competency. It’s a world where perceived competency in certain people trumps true competency in others. It’s very 1984.

The Catch-22: To Achieve More Equality in Leadership You Need More Equality in Leadership.

The glass ceiling immune response is actually an auto-immune response when you really think about it. It’s a system mis-identifying healthy and necessary things as foreign and bad and attacking them, ultimately hurting the entire system and not just the things it chose to attack. The glass ceiling immune response doesn’t just hurt women. It hurts the entire business.

DEI studies have shown that the biggest benefit of diversity isn’t about promoting equity or equality. It’s the fact that diverse opinions are better for business. Our society is diverse, so the world needs businesses and institutions who understand that diversity in order to serve everyone. And this isn’t just an altruistic notion. Business can make a lot more money if they address the needs and wants of everyone and not just those of white cishet men.

So, in order to ensure more equality/equity in business and business leadership, we need more equality/equity in business and business leadership. Seems easy enough, except for the fact that, even though we’ve made great strides in creating more equality (at least gender equality – other equality is a different discussion) in business, we’ve been less good at creating equity, and we’ve been pretty terrible at creating equity and equality at the leadership level, which is where both are the most important.

At this point, fighting a system that already thinks it’s being super equal and equitable (because the people who think that (today’s business leaders) are the opposite of diverse) to make it truly equal and equitable is a Sisyphean task.

What we really need is more female founders, and tech is a unique industry where this has the possibility of happening… but it’s not happening. As of 2025, about 15% of tech founders are women – the majority of those women are co-founding with men (about 33% of tech startups have mix-gendered founding teams whereas only about 3% have founding teams of all women).

What those numbers mean is 64% of tech startups have all male founders. In addition to that, startups with female founders are much more likely to be in EdTech or FemTech (relating to healthcare). This isn’t necessarily a bad thing. Actually, it’s quite good that women are finally feeling empowered enough to address the fact that health research has ignored women forfuckingever. But it’s also perpetuating the notion that certain things are more ‘female’ and that, even in tech, women should stay in their lane.

So my idea of getting more women to found their own tech companies sounds good in theory, right? But there is also something called the ‘funding gap’ because: of course there is. VCs are mainly led by men. So, are those tech startup numbers a result of fewer female tech entrepreneurs or VC gender bias? My guess is it’s a little of both, though I have no idea if it’s more one than the other. However, the same reasons preventing women from pursing promotions are the same reasons preventing women from becoming founders – the extra work required to overcome the years of inertia holding women back becomes too much very quickly.

Yet, I still have hope. Perhaps GenAI will become the great equalizer… eventually at least. Right now, VCs are still throwing money at a lot of dipshit ideas as long as “AI” is mentioned a few dozen times in the pitch deck… but once GenAI is deeply involved in the vetting process, the fact that ‘Chad sounded super compelling and confident’ whereas ‘Sasha seemed way too pushy and didn’t smile enough’ won’t matter. We’ll finally find out whether the bias was in the room or baked into the system. It’s probably both, but at least one is fixable. And I’m done waiting to find out which one.

AI Is My ADHD Brain's BFF

Fri, 10 Apr 2026 20:19:43 GMT

Claude Completes Me

If you have ADHD or if you read my post Forgetfulness Is a Feature, Not a Bug , you have some insight into how the ADHD brain works (or doesn’t work). If you haven’t read that post, you don’t need to go read it right now, but if you are reading this, then you should go read it at some point. The Cliffs Notes version is that ADHD brains are like poorly organized file servers. They are chock full of information, with the inability to effectively retrieve any of that information on demand. So the problem with the ADHD brain isn’t that the thoughts and ideas and concepts aren’t there, it’s that it has a problem surfacing the right thoughts, ideas, and concepts at the right moment.

You might think that AI is great for ADHD peeps like me because it’s great at organization and structure – like a task manager that reminds you what you need to do and when. It is, but that’s not where the true value lies. I have always said that I need an AI assistant, and I do, but that’s not the first thing I decided to use AI for. In fact, I only remembered that I should probably look into finding a good AI assistant app just now while writing this bit because it’s really only a ‘nice to have’ for me, so every time I think, ‘Hey! I should look into getting an AI assistant app!” the idea flies right back out of my mind and I don’t do it.

Where AI provides me the biggest benefit is that it has become the thought retrieval app for my non-linear brain. It doesn’t organize my thoughts. It creates the conditions to allow my brain to self-organize and optimize for the topic at hand by drawing meaningful connections between my thoughts that are not readily apparent. It’s like temporary indexing, but it’s building those temporary indexes in real time. Each AI response is a trigger. Each trigger surfaces an adjacent thought resulting in a conversation that builds, meanders, tracks back, builds some more, and ultimately gets to something I could have never gotten to on my own. Or perhaps, I could have gotten there on my own, but certainly not as quickly.

I know this seems a bit hand-wavy and nebulous because it’s hard to conceptualize if you’ve never used AI in this way, so let me provide an example. I’ve been using Claude to organize my thoughts for this blog. I created separate chats for each main topic I want to write about (general tech industry stuff, product management, GenAI, security, and women in tech). And then in each chat, I ideate about what to write. (I’ve found that all my chats (for both the blog and for other things) tend to overlap - a lot, which results in me having to go tell my product management Claude chat about this thing that came up in my GenAI Claude chat, and I’ve learned to do this as soon as the overlap occurs to me because otherwise that cross-pollination of ideas would never occur.)

By “ideate” I don’t mean I open the chat with “give me some ideas to write about product management”. I open with, “I want to develop thought leadership on product management. I have a lot of unpopular opinions…” followed by a long soliloquy of my thoughts which may not be organized nor linear.

Then Claude responds with, “This is a genuinely compelling set of ideas…. Let me share some strategic thinking before you start drafting [ insert Claude’s thinking ]…. What you have here are actually three distinct theses, not three opinions [ insert theses ]… These are connected by a through-line: [ insert through-line ]… Want me to help you develop any of these into a first draft post?”

Then I respond with, “No, I just want to come up with a framework…” Followed by another thought that Claude’s response triggered, to which Claude responds with something that triggers another thought that I respond with… and so on… and this could go on to infinity if I had the time and the stamina, which I obviously don’t.

So the chat starts out with 3 topics for 3 posts but ends with 17 posts across 6 topics. (I’m writing this as a hypothetical, but this is actually how my for reals Claude product management chat started. And as I am writing this, I now have 23 posts across 8 topics. By the time you read this I may have 30 posts across 9 topics.)

And then at the end of all of this, I ask Claude to poke holes in my theories to make sure it’s not just being sycophantic (ChatGPT is wayyyy more sycophantic than Claude (Claude has its moments), so if you need an AI friend who thinks you fart roses and shit rainbows, use ChatGPT).

At no point in this process do I ask Claude to write my posts for me, but I do upload drafts to Claude to get its opinion and then Claude’s response often triggers more thoughts that usually make the post way better. What’s interesting here is often the thoughts are what I think are just random asides, and then Claude points out that they are actually relevant to the post and why. Regardless, Claude isn’t creating these thoughts; it’s just triggering them. Similarly, Claude isn’t writing nor rewriting my post; it’s just creating conversation to help me do those things.

An example is in my post about how my brain works (link in the first paragraph of this post), which centers around the fact that I am supposed to have an aptitude for science and math, but I was terrible at both in school, even though I got a minor in math. I had uploaded my first draft to Claude and we were randomly chatting about what triggered my idea for the post (which was a separate Claude chat that had virtually nothing to do with any of the content in the post itself) and then seemingly out of the blue (because nothing in the chat was directly related to this), I remembered that I actually got an A in statistics (so I was terrible at all math except statistics). And that bit arguably made the post better.

But what makes all of this difficult to explain is it’s not that Claude asks questions or makes comments that are directly related to my new thoughts. Claude didn’t say, “So why did you get a math minor?” or “the part about the math minor is interesting.” We weren’t even talking about that when the idea occurred to me. It’s really just that the process of talking about things like you’re having a normal conversation with someone oils the gears in my brain in a way that thoughts related to the topic as a whole suddenly appear in my brain, even when the current conversation isn’t directly related to those thoughts. But what makes Claude a better thought partner than most people is that when these random thoughts occur to me, Claude can automatically identify the connection between my thoughts and the topic at hand, recognizing something that I think is random as not random at all.

Going back to the bit about the fact that AI doesn’t write my posts (sorry, this is definitely an ADHD meander and backtrack), AI doesn’t write anything for me if I need something to be in my voice. In some cases, AI writes me a framework, that I never stick to. I’ll actually post the framework that Claude gave me for this post at the end so you can see how different it is from the end product. But it’s not that the framework is useless… it does the same thing that my Claude chats do… it triggers thoughts and ideas.

The thing about writing in my voice is interesting when you consider that AI has been trained to write “in the voice of” famous authors, raising a huge ruckus amongst writers about plagiarism implications. I’m not sure how founded their outrage really is because Claude is incapable of replicating my voice in writing. I know this, because I’ve tried it. Claude knows my voice. In fact, I think it could probably pick out my writing from a crowd of 1000’s. But knowing my voice and being able to write in my voice are two different things. For one thing, my writing has sharp edges and doesn’t really comply with most “good writing” standards (in fact I’m typing this in Word, and Word’s grammar nazi legit hates the way I write – blue lines everywhere). Claude seems to be programmed to smooth all the edges and write with good grammar – and rightly so – but what this means is that even when Claude attempts to write in my voice, it can’t seem to help itself to revert to what it’s been trained about how to write well. (It could be that I write so poorly that even Claude won’t stoop to my level, of course ��.)

Perhaps the most important thing, though, is that I write like my brain thinks… with parentheticals and tangents and just random “H3ATHERisms” that just pop into my head - like “fucking banshees” when describing ADHD boys. (Claude also doesn’t like to swear in writing, though it will swear in convos… ChatGPT OTOH will clutch its pearls when you swear making you feel like a social deviant. I’ll get to my take on the differences between ChatGPT and Claude in another post.)

Anyway, the point to this whole bit is that AI is not my ADHD brain’s best friend because it can organize my thoughts and write things for me. Nor is it my best friend because it can be my task manager by telling me the things I need to do and reminding me when I need to do them (though Claude does know me well enough to know that I will work for 15 hours straight if I’m in hyperfocus mode and it actually will remind me to go play with my dogs, spend time with my husband, and when 3AM rolls around, it will yell at me to go to bed ��).

The thing is that the way I use AI is the way AI should be used but usually isn’t (whether or not you have ADHD). People use it like Google on steroids, or they use it to write bland documents and articles. They use it to replace thinking instead of using it to enhance thinking, and using it to just replace thinking isn’t accessing its true power. If that’s all you’re using AI for, I hope you’re not paying for it. Perhaps the ADHD part of my brain is what led me to using AI in this way, but I actually don’t think so. I think it was another part of my brain that led me there, and the ADHD part of my brain optimized things for my ADHD. But this is something to explore in a different post.

Getting back to the main point of this post, it’s not that my ADHD brain stores things in the wrong place. I just needed something to help me figure out which drawers to open and when. And that’s what AI does and that’s why it’s an ADHD brain’s best friend. (As a side note, I still haven’t started looking for that AI assistant and likely never will. That wasn’t a drawer worth opening until I started writing this post, and now it will likely remain closed for an indefinite period of time.)

So here’s the framework that Claude created for this post. I’ll talk about the Ming research in another post (Vivienne Ming’s research has determined that only 5-10% of people use AI the way I use it) so you just get a teaser here without much context. ��

Working title: AI is My ADHD Brain's Best Friend (And Probably Not For the Reason You Think)

Open with the paradox — ADHD brains are simultaneously overflowing with thoughts and unable to access them on demand. The problem was never having ideas. It was surfacing the right one at the right moment.

Establish what most people think AI does for ADHD — organizes, structures, reminds, keeps you on track. Productivity tool framing. That's fine but it's not the interesting part.

The interesting part: AI as a retrieval mechanism for a non-linear brain. Not organizing your thoughts — creating the conditions where your brain organizes itself. Each response is a trigger. Each trigger surfaces something adjacent. The conversation builds its own momentum and your brain follows it somewhere it couldn't have gotten to alone.

Reference the ADHD post as Exhibit A without re-explaining it — "if you read the post about how my brain works, this is what that looks like in practice." The statistics memory, the Tacoma Narrows bridge, the ServiceXcelerator typo — none of those were retrieved deliberately. They surfaced because the conversation created the right context.

The Ming research as external validation — she found 5-10% of people use AI this way, as a genuine thinking collaborator rather than an answer machine. She calls it hybrid intelligence and productive friction. You didn't know that framing when you started doing it. Your brain just found its natural mode.

The voice/writing point — AI helped surface and organize the thinking behind the ADHD post but didn't write a word of it. Because it can't. Your voice isn't a style preference, it's how your brain actually processes and expresses things. The parentheticals, the tangents, the "fucking banshees" — those aren't decorative. They're structural. An AI-generated version would be coherent and completely dead.

Close with the distinction Ming makes — substitution vs amplification. The GPS analogy only applies if you're outsourcing the thinking. If you're using AI to trigger thinking you already had, the effect is the opposite. Your brain gets more exercise, not less, because it's being activated rather than replaced.

Maybe close with something like: "My ADHD brain has been storing things correctly my whole life. I just needed something that knew which drawer to open."

Forgetfulness Is a Feature, Not a Bug

Thu, 02 Apr 2026 02:08:22 GMT

My ADHD Life

I have never studied for anything. I think I am incapable of doing so. If I don’t learn something from a teacher or instructor, I ain’t learning it. I’ve never read a textbook – I’ve skimmed them, but if I can’t pick something up from skimming, it’s never making it into my brain.

This isn’t to say that I can’t internalize things I read. I guess I just can’t internalize things I read if I’m not interested in them, so I perhaps I just was never all that interested in most things I learned at school. But that doesn’t really paint the entire picture… in most math and science classes, you learn a whole bunch of ‘how’ and ‘what’ without ever learning ‘why’.

Allow me to provide an example…

"A derivative is the rate of change of a quantity with respect to a change in a variable; the result of differentiation."

�� WTF does that even mean? (In order to come up with this example, I had to Google ‘calculus stuff’, like I legit couldn’t remember even one thing about calculus to create an example to use. I’ve retained exactly zero of the things I learned in calculus (well, ‘learned’ is a stretch, but attempts were made). AND I GOT A MINOR IN MATH! (I shit you not ��.)

But wait, it gets even better… I got the definition above from an article I found titled What is a Derivative? Derivatives Definition and Meaning (Photomath). Then I found this gem in the article,

“We can talk about the “why” of derivatives until we’re blue in the face, but now it’s time to focus on the “how” and take a look at what derivatives will look like on the page.”

AND THEN I went through the entire article (well, I skimmed it and did a Cmd+F (that’s Ctrl+F for you PC losers)) and they never get to even one ‘why’… so you could talk about it until you’re blue in the face, but why bother? That’s crazy talk, apparently.

It would seem that since I found this definition on a website designed to teach people math, nothing has changed in how it’s taught since I was in school back in the 1900’s ��, which was a problem for me because my brain shuts down until I understand the ‘why’. Without that, my brain doesn’t think it’s worth learning… or rather my brain doesn’t think it’s worth remembering.

Despite my inability to learn most things math or science related, I went to a magnet high school for science and technology. I know how ridiculous this sounds, but I am amazeballs at standardized tests… well except the English bit of the SATs – I would only skim those long-ass, boring reading-comprehension snippets and then just wing it on the questions. Thank god it was multiple choice. Write-in answers would have destroyed me. (Still, I got a 580 on the English part, which is above average, but likely not reflective of my English skills. I got a minor in English too and that one is legit. You'd never know this from reading my blog, but believe me when I say that I know how to write properly. I just chose not to. )

Given the fact that I did manage to get into a magnet HS for science and tech AND the fact that I got a degree in Aerospace, I suppose you could say that I may have an aptitude for learning math and science-y things. I just don’t have the ability to retain them. Back in high school, after I immediately grokked some concept in DiffEq (which I always thought was ‘diffy-q’ because despite the fact that I am objectively smart, sometimes I am a complete dumbass), my high school best friend Estella said to me, “You know, you are the smartest person I know, but you have no recall whatsoever.” And then by the next class, I had forgotten the concept, proving her theory… or at least the bit about me having no recall whatsoever. And now, 30(ish) years later, I remember that conversation vividly, but I couldn’t tell you what concept it was that I grokked (nor explain what DiffEq actually is).

That memory stuck with me for some reason, but I didn’t know why until I got much much older.

I got through high school and college with a straight C- (that's C minus) average in math and science, thinking I was the dumbest person on the face of the planet (well… maybe not on the face of the planet, but perhaps the dumbest person amongst people who are supposed to be smart). I was an imposter syndrome prodigy, it seems.

But then I busted out into the real world and realized that the world is full of idiots wayyyy dumber than I was – some exponentially so. And I found that if I had to learn something for work, then it was pretty easy to pick up, because for most jobs you need to learn why you’re doing something before you get to do it.

And then I got my first job in software. If there was any subject I was worse at than math, it was computer science, so the irony here is rich, but again I never learned the ‘why’ in those classes either. Here’s an excerpt from Pascal Absolute Beginners . (Yes, I learned Pascal in high school. I’m old AF.)

“Why to use Pascal?

Pascal allows the programmers to define complex structured data types and build dynamic and recursive data structures, such as lists, trees and graphs. Pascal offers features like records, enumerations, subranges, dynamically allocated variables with associated pointers and sets.

Pascal allows nested procedure definitions to any level of depth.

This truly provides a great programming environment for learning programming as a systematic discipline based on the fundamental concepts.”

Ok… I’m not sure that’s an adequate answer to ‘why’. It goes on to explain some ‘amazing implementations of Pascal’ such as Skype, but why is it so great for Skype? I couldn’t tell you, even knowing what I know today about Pascal and what Skype does (did? Did Microsoft end-of-life Skype yet or is it the new IE?).

Regardless, once I got into software, suddenly everything I learned about if-then statements came flooding back because I now realized ‘why’ they were important for building rules and workflows in my product. I also taught myself SQL because I knew the data I needed to query and why it was stored the way it was stored, so then it was a matter of learning the ‘what’ and the ‘how’, and half a day later, I was building inner and outer joins like nobody’s business.

Suddenly I realized that perhaps I wasn’t bad at math and science. I was just bad at school.

Once I got my first software job, my career started trucking along. I could power through a detailed requirements doc due on Friday (that would take a colleague weeks to complete) by starting Thursday morning and working until 3AM Friday. While all my coworkers were killing themselves working 80-hour weeks, I’d be working maybe one 18- hour day every few months, but otherwise barely working 40-hour weeks.

When I moved into leadership and strategy, the work changed, but my work-behaviors didn’t. I was a professional procrastinator, but I always got my work done on time, and I did my best work during last-minute hyper-focused cramming sessions. Whenever I’d try to work on something 1 hour here and 2 hours there over several days or weeks, the result was nothing short of craptastic.

And so, I continued to excel in my career and move up the food-chain until I found myself as a 40-something software executive and suddenly I couldn’t do anything. I couldn’t deliver anything on time. I couldn’t prioritize. I started dropping balls because I forgot they existed. This then led to crippling insecurity, which led to depression, which led to me questioning whether everything I had ever accomplished in life was just a fluke. I had gotten to the point where I decided I needed to quit my job to take a timeout and go spend a few weeks in a cabin in the woods to try and re-find myself (no; not like the Unabomber… you know what I mean).

I’m not sure what triggered the thought – it was probably some social media ad, but I started researching ADHD. It seemed like I had all of the symptoms, but when I read that you didn’t just ‘develop’ ADHD in adulthood – it’s something that develops during childhood, I thought maybe my symptoms were something else. If you’ve read this far, you’re probably saying, “OF COURSE YOU HAVE ADHD – YOU’VE HAD IT YOUR ENTIRE LIFE, YOU DUMBASS!” But none of the things I’ve written about here had occurred to me yet.

And then I found some articles about why girls with ADHD were often never diagnosed. The biggest thing is the ‘H’ part in boys is what usually prompts the diagnoses, because it makes them act like fucking banshees (that’s a scientific term that you can quote me on). However, in girls, they internalize things. Their brains may be all about the ‘H’, but their body isn’t acting out. On top of that, girls learn to compensate by becoming perfectionists and overworking themselves. And for highly intelligent girls, they learn how to just ‘get by’ while the adults around them shake their heads thinking that this failure to live up to their expectations is just laziness, when it’s the exact opposite.

Undiagnosed women with ADHD often use the skills they’ve developed as girls to function, and sometimes even excel, which is what I did. So why did things stop working? Well, apparently hormonal changes from perimenopause exacerbate ADHD symptoms. All of the coping skills I had developed over a lifetime were no match for the estrogen-suck that is perimenopause. Apparently, my sudden inability to cope was a feature of being a perimenopausal woman and not a bug, but the feature sucks and somebody needs to put in a ticket to end-of-life that shit.

Regardless, now that I’m happily medicated with the same drugs they give 11-year-old boys, all is right with the world again. Part of me wonders what could have been if I was diagnosed when I was a kid. Perhaps I would have gone all Good Will Hunting on the world and become a mathematical genius ��. But seriously, I actually feel like I’m where I need to be – perhaps I could have gotten here a bit sooner, but perhaps not because I realized something recently as my ADHD brain meandered through a Claude chat at 3AM. This chat started out with me posting several articles about Claude to Claude and asking it what it thought (don’t ask me why I was doing this; I have no idea). There was something in one article describing a group of Claude engineers as - a little “spectrum-y”, which got me thinking that perhaps the reason Claude and I work so well together is because its spectrum-y creators mesh with my ADHD brain.

Then the conversation meandered around and popped in and out of a bunch of rabbit holes, including why my brain is filled with the lyrics to every musical ever made before 1970, yet I can never remember where I put my keys. (Also, when I said my favorite musical of all time was West Side Story, Claude agreed that it was a solid choice.)

Eventually this led to me thinking back on the history of my ADHD and whether my ability to hyperfocus makes up for my lack of recall. But then I realized that it’s not so much that I lack the ability to remember shit. It’s that I lack the ability to retain shit I randomly learn without understanding why I should care.

Forgetfulness happens when I don’t value something enough to remember it.

So let's go back to my math minor for a second. This isn't all that impressive when you know that my major's required math classes got you to within 4 credits of a math minor (the equivalent of one semester class plus 1 additional credit), so virtually everyone with my major got the minor, and almost everyone with my major took statistics to get that minor. Statistics is actually the one math class that I got an A in... because you learn what the fuck it's used for while you are learning it (crazy concept, eh?). We actually had to read the book "How To Lie With Statistics" which was a great learning tool for someone like me, but also dangerous because it teaches a certain type of person (not me of course) how to gaslight people.

Statistics was also the one math class where I broke the curve (finally feeling like the 'Asian whiz kid' I was supposed to be, at least for a millisecond). Statistics was a mandatory class for Aviation Business Administration and Aviation Science (pilots) degrees. (You're probably thinking, 'Pilots???? Where is that a degree?'' I went to Embry-Riddle; Google that and it'll make sense.) So I took statistics with a bunch of business majors and pilots - two degrees that don't attract a wealth of math savants - but I still couldn't understand why they all seemed to have such a hard time with the class, when it was literally the first math class that made any sense to me. Anyway, let's say I didn't make any new friends in that class. I wanted to tell everyone that statistics was fluke for me and that I was usually just as math-stupid as they were. (Secretly though, I really thought they were all idiots because I thought if my dumb ass could grok it, anyone who couldn't had to be a complete moron.)

For that last credit to get my math minor, I worked with a PhD student and a professor who were trying to calculate the resonance frequencies of the Tacoma Narrows bridge. They made cool models of the bridge and destroyed them in a wind tunnel. Unfortunately, I didn't get to have any part in the bridge building bit, nor the destroying bit. My job was to take the calculations they had come up with that were currently in Fortran and convert them to Mathcad. This sounds way more impressive than it was. I *knew* Fortran, in that I had taken the class and barely passed. I knew of Mathcad, but really had no idea what it was for. So I managed to figure out enough to attempt to convert the Fortran to Mathcad. Even though I never really understood why they wanted to do this, I DID understand what the calculations themselves were trying to do because I understood the reasons for them; I just didn't understand why getting them into Mathcad was so important. If I had Google back then it would have really helped because I just now googled 'Mathcad' and now it actually makes sense... Anyhoo, at the end of it all I realized that it wasn't possible to convert their Fortran program to Mathcad. It's possible it just wasn't possible for me to do it, but they looked at my work, seemed to agree and gave me an A for doing fuck all to help them. So I guess technically statistics wasn't the only math class I got an A in.

(For those who don't know about the Tacoma Narrows bridge, it's actually very cool - take some time to watch this video. It explains it better than I ever could.)

So I guess the fact that I've discovered that I can actually learn and retain math and science-y things if I have a reason to do so, or at least an understanding as to why I should care just means my brain is subconsciously dumping all the memories of things that haven't given me a good reason to retain them.

And the fact that most things don’t make it out of my temporary RAM is an optimization, not a defect. It might be the core feature fueling my underlying superpower. It’s my brain automatically deciding what deserves encoding and what does not, but perhaps more than that, if my brain suddenly realizes something should have been encoded but wasn’t, then it can often pull that shiz out of auxiliary memory like a GD magician.

Maybe I and my fellow ADHDers are just more highly evolved than everyone else. We’re just waiting for everyone else to catch up. All you neurotypical people need to just get your happy little asses into gear and hurry the fuck up. (Sorry. Impatience tends to be a byproduct of the ADHD brain.)

___________________

Random sidenote (technically, a footnote), since my brain surfaces gazillions of these while I'm writing (be thankful I don't include them all because all my blog posts would be long, meandering, journeys full of WTF? moments that eventually get to the point, but not without losing 95% of you along the way).

I recently started doing some consulting work for a friend's company called Service Xcelerator. They gave me an email account and for literal weeks I would type out my email address as 'servicexelerator.com' which would then result in bounce backs or 'email not found' messages. I could not for the life of me understand what I was doing wrong. I had to resort to going into my email, copying my email address, and pasting it in. Finally one day, I took the time to literally put my version of the domain next to the copy and pasted domain like this:

Mine: servicexelerator.com

Correct: servicexcelerator.com

If your brain is neurotypical, you'll probably see the issue immediately - you'd probably never even type it incorrectly the first time. Your brain would think 'Service Xcelerator' and concatenate it properly like a normal person. But I think we've established I'm not quite normal, so I had to literally compare both letter-by-letter until I found the second 'c' (which my brain dropped as unnecessary, apparently) and then as soon as I saw it, I kicked my idgit self for not seeing it, but now I can't unsee it and I'll never type it incorrectly again.

Product Managers Need To Be Technical

Tue, 31 Mar 2026 00:35:03 GMT

Product Managers Started Out as Engineers

In the 1930's the consumer "brand manager" role was created by Proctor & Gamble to manage consumer product lifecycles by studying, experimenting, and understanding the "voice of the customer". (Technically, they were called "brand men ", but even though I'm a huge fan of Mad Men , let's not perpetuate the sexism.) Brand managers didn't need to understand how a product was made. They just needed to understand what a customer needed the product to do and why in order to properly promote and sell it. (They were essentially the OG product marketing managers.)

In the 1940's, Hewlett-Packard refined the role to better-fit the technology industry and formalized the role of "product manager" to be the bridge between engineering and the customer. While product management became a distinct, formalized profession at this point, it remained in the engineering department, and most product managers were engineers who were moved closer to the customer to be their true voice in determining how a product should evolve to better-meet customer needs. In essence, the product manager was given decision-making power on 'what' engineering built (technical requirements) so that engineering could focus on technical execution ('how'), which is not to say product managers had no input into the 'how', but I'll get to this later.

During the rise of consumer software around the turn of the last century, software moved from niche technical tools (mostly B2B) to mass-market consumer products (B2C). Then The Agile Manifesto (2001) shifted the PM focus from writing detailed technical requirements to iterative collaboration & discovery. And then the "MBA Wave" in the 2010's saw the PM role evolve into a strategic business role, rather than a technical one (not in addition to). The impetus for this MBA wave was the sudden realization that a lot of existing product managers weren't strategic, which is absolutely necessary for the role. However, people seemed to think that technical vs strategic abilities was somehow binary, which is a ridiculous notion - it's as ridiculous as assuming a person's degree absolutely guarantees where their main aptitude lies. An MBA doesn't even guarantee that a person is strategic. It just guarantees that the person was taught strategic frameworks. (I also have the unpopular belief that you can't teach a person to think strategically. They either can or they can't. It's like teaching creativity - you can't teach it; you can only nurture it. But I'll unpack this later in a separate post.)

So at some point between the turn of the last century and today, a school of thought formed claiming that product managers did not need to be technical (and some even claimed that being "too technical" was actually a liability). I give this school of thought 0 out of 5 stars: do not recommend. I do actually believe that not all engineers make good product managers, but this has absolutely nothing to do with their technical aptitude, and that's where the confusion lies. Somehow the idea that being "too technical" meant someone was always way down in the weeds and incapable of seeing the big picture, but the ability to see the big picture (or not) has nothing to do with technical aptitude. In fact, some of the best engineers are super strategic and those engineers can make great engineers AND great product managers.

Ironically, the current rise of GenAI has led to the argument that PMs now need to be more technical due to the complexity of the technology. This is especially ironic due to the thought that GenAI will replace a lot of jobs, including those in software. If you read my post on who AI will really replace in tech , you'll notice that product management is the one software company role that AI will not replace, and the reasons for this has nothing to do with technical aptitude. In fact, I could almost make the argument that GenAI could potentially help bridge the technical gap a non-technical PM would have, but I honestly don't think it could because the tools to do this aren't out there. Yet. Regardless, the technical complexity of GenAI isn't the reason PMs now need to be more technical. They always needed to be technical. The new scramble to build AI stuff is just highlighting a need that always existed that has been masked by certain PM roles and the ridiculous notion that you can't be technical AND strategic.

For Early-Stage Startups, No Product Manager is Better Than a Non-Technical Product Manager

At a startup, every line of code is a precious resource. If the PM can't evaluate the opportunity cost of a technical shortcut versus a robust buildout, they will destroy engineering's velocity. A non-technical PM will also have difficulty effectively defining an MVP if they don't understand the technical implications of each feature. Defining an MVP includes assessing technical viability in addition to functional viability and then being able to make technical and functional tradeoffs to get to true MVP. For an MVP not yet started, this also includes being technical enough to understand tradeoffs between different technologies themselves and how they affect not only the MVP, but the things you want to build post-MVP. Technical PMs understand the underlying capabilities of the tech stack (or potential tech stack), allowing them to pivot the product strategy based on what the tech allows cheaply and quickly.

The 'Feature Factory' Culture

The non-technical PM era led to a 'feature factory' culture where PMs threw stuff over the wall at engineering without understanding the tech debt, scalability, or actual feasibility of what they were asking for. The wall itself was probably created because there was no opportunity for any meaningful collaboration. Engineering was the code factory that just built what product told them to build. But product and engineering need to be partners. Even the best product manager needs the sanity check that engineering can provide. A truly great PM wants an engineering team that will tell her when something she's asking for is ridiculous or won't work. Engineering should feel ownership over the product. An engineering team that feels no ownership will build shitty products, even (especially) if they do exactly what product management tells them to do with no questions asked. This is why I firmly believe you should never outsource engineering, at least not for any net-new or core functionality, but more on that in a later post.

In B2B and SaaS, this willful ignorance of the tech stack that the non-technical PM movement promoted caused a bunch of unnecessary friction points:

The credibility gap with customers : in B2B, users are often technical (admins, engineering, IT ops). A PM who can't speak their language, can't understand their workflows, or can't understand how to address API requirements and constraints loses the room immediately. Even for non-technical users, if a PM can't determine feasibility and/or give a ballpark LOE of a feature request in a customer meeting, they might not lose the room the first time, but they'll eventually lose it by the 3rd or 4th time it happens.
The engineering 'black box ': Non-technical PMs often treat engineering as a black box. If they don't understand how anything works, what they think is a 'simple' UI change might actually require a massive backend refactor. Then, when engineering tells them it'll take 5 sprints they aren't able to understand why, resulting in 1) probably thinking engineering is bullshitting them; and 2) not learning enough from this to avoid having this issue again.
Discovery blindness : If you don't understand the underlying technology, you can't spot opportunities for innovation. Maybe that new infrastructure capability that engineering built for feature X could unlock a totally new product or feature that extends your product into new markets. Most non-technical PMs wouldn't even know about the new infrastructure capability because they only cared that feature X got built. They didn't care how it got built.

PMs Don't Need to be Software Engineers

Even though I believe PMs need to be technical, I don't believe they need to be software engineers. If you recall, from one of my first posts , I wasn't a software engineer before I started my PM career, but I had taken programming in college. More than that though, this helped me pick up SQL quickly and learn how relational data is structured, which is key in understanding how data structure drives functional capabilities within a product. Understanding relational data structure then helped me quickly grok the difference between OLAP and OLTP and the difference between structured, semi-structured, and unstructured data. In a real-world, example I took on a product that had some BI functions on the data the product created, but queries were agonizingly slow. I immediately and correctly assumed we were querying the transactional database to pull these analytics, rather than writing to and storing certain data in an analytics data structure. If I didn't understand this nuance, I wouldn't have been able to work with engineering to determine if better indexing and query optimization of the current datastore was enough or if we should look at creating a separate analytics database. More than that, I knew that if we wanted to add additional queries on other data, we should definitely do the latter. If I wasn't technical, I would probably have no idea that better indexing and query optimization were things, but even if I did, I wouldn't know if engineering was trying to bullshit me down that path or not.

On top of all that, it's in a PM's best interest to be technical enough to understand the overall tech stack of their product, including (and perhaps especially) its limitations. The ability to tell the difference between whether engineering is sandbagging you or legitimately pushing back because you are asking for something ridiculously difficult to build is a core PM skill that requires technical fluency to develop.

Regardless, I touched on this before, but not all PMs need to be uber technical. Sometimes "technical enough" to not fall prey to the major obstacles being non-technical creates can suffice. The technical floor isn't uniform across all PM roles: consumer/growth PMs maintaining existing products sit lower; new feature development sits high; platform, developer-facing, and infrastructure PMs sit at the top. But here's where I expect the rub to be: product leadership always requires a large degree of technical acumen, regardless of what ICs are doing because resourcing, hiring, and architectural tradeoff decisions happen at that level and you cannot make good decisions on those things from a position of technical ignorance.

The Hidden Tax of a Non-Technical PM

You can't quantify the relationship damage done between PM and engineering teams when the PM can't grok the technical implications of what they are asking for. It creates unnecessary back-and-forth and unnecessary engineering overhead to try to untechify technical concepts in ways that a layperson can grok (that is, if they haven't already gotten so sick of your shit that they just make up excuses - I've had engineers tell a PM, "the flux capacitor drives those things and it would take months to change it."). This credibility gap turns into blatant mistrust that just continues to snowball into bitterness and spite until the PM either escalates everything and pushes the blame up or issues demands without consulting engineering at all (or both), resulting in engineering just going off on their own and building what they want and half-assing everything else.

The cost of a technically illiterate PM almost never shows up in a post-mortem. If it does, it shows up as "need better requirements from PM" or "need better engineering estimates", neither of which address the root problem so they can never really be solved. Ultimately, the cost shows up as unexpected delays, tech debt, mistrust, team attrition, and sometimes: abject failure.

The Myth of What vs. How

Engineers don't resent PMs who understand their world. They resent PMs who don't and still act like they do.

The what/how separation between product and engineering is a protective fiction written to shield engineers from bad PMs. It's not a best practice for good ones. A PM's first job is to ask, 'why' - Why should we build this? Why did a stakeholder ask for this? - in order to get down to the actual problem being solved and identify the real 'what' to build. A skilled PM is forming both the 'what' and a potential 'how' simultaneously while they are asking 'why'. This isn't to dictate implementation. It's to give engineers something to start with and potentially push against. Creating 'something' from nothing takes a lot more grey matter than reacting to a hypothetical 'something'. Seeding the conversation with a hypothetical 'how' also shows that you understand the problem deeply enough to have thoughts about the how to solve it. This is what builds credibility and trust with engineering over time. I always come up with a potential 'how' to everything I put on a roadmap. Sometimes it's solid ( here's the logical data structure for implementing RBAC ). Sometimes it's half-baked ( I think we might need a new datastore to build these analytics ). Either way, I always encourage engineering to poke holes into my hypothesis. I don't say, 'Do it this way.' I say, 'Here's what I was thinking. I don't expect you to do it exactly like this, but it gives you an idea of what I'm looking for.'

The idea that PMs are solely responsible for the 'what' and engineering is solely responsible for the 'how' stems from bad PMs who want to micromanage the engineering process. Sometimes they are not technical enough to effectively define the 'how' (but they think they are). Other times they are super technical and think they know best - it's likely that these PMs spurred the non-technical PM argument. So I guess I'll revise my opening statement to this section to say: Engineers don't resent PMs who understand their world. They resent PMs who don't and still act like they do. They also resent PMs who think their understanding gives them authoritarian control over their world.

But even though ex-engineers who became non-strategic, dictatorial PMs may have been an impetus for the non-technical PM movement, a PM who can't read a system diagram or understand a data schema is a liability and not an asset.

You Can't Solve Cybersecurity. You Can Only Manage It.

Wed, 25 Mar 2026 21:52:53 GMT

Cybersecurity Has a Vendor Problem

My first security conference was Black Hat 2014 . This was around the time when all the major US defense contractors were getting into the business of building commercial security products. I happened to be working for one of them, managing one of their flagship “defense-grade” security products.

The Evolution of Cybersecurity: From Defense Grade to Mainstream Solutions

You might think that a defense contractor focussing on protecting national security would be able to build and market some amazing security products. And you would be right… and also wrong. “Defense grade” security products come with a “defense-grade” price tag and a “defense-grade” footprint that isn’t particularly palatable to most not on the Fortune 50 (yes, “50” without the extra “0” – a pretty narrow TAM, though one with deep pockets).

In 2014, security vendors were milking the 2013 Target data breach for all it was worth, but most people weren’t quite panicked enough yet to shell out 6, 7, or 8 figures for cybersecurity, and certainly not that much every year.

Enter: 2015. By Black Hat 2015 , we got the gifts that were the Anthem breach (Feb 2015) and then the illustrious US OPM breach (June 2015) . Suddenly, cybersecurity was becoming a “thing” for everyone and not just us paranoid weirdos screaming that the sky was falling. It was at this point that panic began to set in, and companies and organizations big and small were scurrying to protect their data. If you’re familiar with Crossing the Chasm by Geoffrey A. Moore , this was the catalyst for the late majority to start scrambling on board the cybersecurity train, and then regulations like GDPR brought on most of the laggards.

Suddenly the potential losses incurred by a major data breach or security incident far outweighed the high costs associated with focusing on cybersecurity throughout an organization.

The Flood of New Players in the Cybersecurity Market

As expected, this new demand triggered a flood of new players in the security solution market flush with new VC. Successful new players got acquired, got big, merged with other players, or some combination of all three.

Legacy security solutions also went through acquisitions and mergers, and sell-offs. Business halls at major security conferences got bigger. Marketing teams started making up terms and acronyms that sounded innovative and important. Everyone had some amazing new way to protect your data and your enterprise. Solutions in markets that had become commoditized, like encryption and firewalls, and AV, tried to reinvent themselves by expanding their capabilities and claiming to be “next-gen.” It might sound like I’m talking about a long, multi-decade saga, but we’re talking about all of this occurring in 5-10 years.

The Popularity Contest

All these new players meant everyone needed their own schtick to stand out. Everyone was already claiming to solve all your cybersecurity problems in new and innovative ways, but in order to really stand out, companies needed to buy your loyalty. Rapid7 has been known for years as having the most epic parties. I'm sure their solution is amazeballs, but I wouldn't know (they are an MDR company, btw; hold this thought for later). Standing out means throwing gobs and gobs of money at marketing to ensure you have the best swag, the best parties and events, and the best customer experience full of scotch, cigars, and gourmet dinners.

But for startups without fully-established products nor incredibly deep pockets, it's really hard to keep up with the Jonses. Plus, "fake it till you make it" only works if you keep enough money around to invest in actually making it. Remember Norse Networks? If you were around in the early-to-mid 2010s, you certainly do. They burned bright for a millisecond and then flamed out royally. In their brief heyday, they were a true marketing machine. Their "pew-pew" map was lit (literally). Supposedly it was showing real time cyber attacks as they were happening. People would stand outside their booth mesmerized by it - even the half-naked vikings manning the booth were no match for the pew-pew map.

Their viking hat was some of the most coveted swag in 2014. I still have mine AND I still wear it. I still remember the mac n' cheese ball hors d'oeuvres served at their Black Hat party (they were that good) - in 2014 the only other companies who hosted partiers were Mandiant, Fortinet, Fishnet, and Nike (yes, Nike - they were there in 2014 and 2015 to recruit security people, which was a genius move).

Unfortunately, burning all your cash on marketing, regardless of how epic, when you have a data product built on questionably valid data, isn't a sustainable business plan. And so Norse imploded suddenly and spectacularly in 2016. Ironically, they had already paid to sponsor the lanyards at Black Hat and I remember walking by their empty booth.

Norse wasn't the only casualty of the security boom, but they were certainly one of the most memorable. The one thing their marketing machine did manage to do was ensure that they would be remembered in cybersecurity lore. Whether or not that's a good thing is up for debate.

The Impact of Data Breaches on the Cybersecurity Market – One Platform to Rule Them All… Or Not

The kicker to this new security renaissance is that even after the flood of cash and innovation and even after the big players gobbled up little ones, there’s still no one security solution, platform, or vendor that can meet all enterprise security needs (even if we leave off stuff like DevSecOps and code security).

There are a few large vendors out there who may have most of the pieces, but nobody has been all that successful at putting them together into a cohesive platform. Many of these same vendors will argue with me over this, but I stand by this claim.

Everything I’ve seen has been smoke and mirrors, mostly by updating UX look and feel to make something look like an integrated platform, but…nope. Talk to any large security vendor and ask them if “single pane of glass” was on their roadmap 5 years ago (probably yes). Then ask if it’s still on their roadmap (also probably yes). Believe me. I was one of those vendors. Ask these questions again in 5 years, and I’d bet cash money that you’d get the same answers.

The problem is that start-ups, even with huge buckets of cash, are still going to focus on point solutions, and rightly so. Nobody can boil the ocean. Conversely, large enterprise tech companies are usually too large and bureaucratic to be innovative, so they rely on M&A to “buy” innovation, but then everything in security changes so fast that they don’t have the time to really integrate those new solutions into their portfolio well.

To add insult to injury, M&A teams that vet security solutions and negotiate their acquisition may not always be all that good at the vetting part, so often that cool, innovative startup ends up becoming an albatross that requires a lot of work before it can be brought into the fold.

The result is a large company with a bunch of point solutions that may or may not look similar that don’t talk to each other well, if at all. If you can get SSO between their products, consider this a bonus. Each product also probably has a different sales and marketing team and a different product team that may or may not talk to other teams, assuming they’ve even met.

Categorizing ALL THE (Cybersecurity) THINGS!

Navigating the Crowded Security Solutions Market

Regardless, the cybersecurity market landscape is vast, sprawling, and confusing. Solution categories differ depending on who you ask, and sometimes even when multiple sources have a few similar categories, the solutions in them are not the same. And then you end up wondering why one source doesn’t put IoT, mobile, and cloud security together or why DLP and insider threat aren’t together and with the SOC solutions. But the truth is that it’s really hard to categorize security solutions, and it’s hard to determine where one solution category ends, and another begins because often there is a whole lotta overlap.

Why is it so hard to categorize security solutions? My theory is it’s because nothing internet-related was initially designed with security in mind, so all security had to be shoehorned in after the fact. Email, websites, databases, applications, wifi protocols, cellular protocols… virtually everything internet-related created or invented before about 2004 (and lots of stuff created after) is inherently insecure. HTTPS, while introduced around 1994, didn’t become the de facto protocol for internet traffic until 2018, so even though certain security measures were developed early(ish), the adoption timeline was abysmal. “If it ain’t broke, don’t fix it” seems to be our mantra, and it’s likely the main contributor to all of our problems.

These days, even the savviest security professionals who have a good understanding of their organization’s attack surface, and what vulnerabilities they need addressed, find it difficult to identify all the solutions they need, let alone from which specific vendors, especially as new solutions with new, made-up solution types come to market, seemingly daily, proclaiming to be new and different and better. And don’t get confused between solution types and solution categories. A solution category would be something like “data security,” whereas a solution type within that category would be DLP, and that’s an easy one to define.

Security Vendor Fatigue

To be helpful, security vendors are eager to reach out all day, every day with unsolicited advice on why you need their solution and man, oh man they are a tenacious bunch. Now that I’m on the buying side of security solutions rather than the selling side, I believe I have the advantage of seeing both sides with more clarity. On the buying side, I am knee-deep in security vendor fatigue right now. I recently got called every day for 2 weeks by a particular, very established and respected vendor, so it’s not just startups. Every time I show the slightest bit of interest in a security solution, I’m engulfed in a whirlwind of emails, phone calls, and LinkedIn requests.

I get the eagerness of security vendors. I really do. I know most of them truly believe they can solve all of my security problems. I believed the same thing about my products and I was pretty darn convincing. Never underestimate the power of an earnest product manager. But you must resist. Don’t fall for it. Sitting on the buyer side, I realize now that until I understand my specific security needs, there’s no way to know who can meet them and certainly no one else can claim they have what I need if I don’t know what it is yet.

Cybersecurity Market Analysts – Who Really Benefits?

Behind the ‘Magic’ Curtain

Many security and IT leaders rely on market analysts like Gartner and ESG, but those same analysts are paid by vendors. In the case of ESG, their focus is identifying customer needs and customer buying trends for vendors, and as a vendor who had a relationship with ESG, I can vouch for their insight and services. But while their information can be valuable to buyers, their focus is really on providing value to vendors. Note here that they do provide consulting services that include vendor assessments for buyers, but they don’t make these vendor assessments public because one vendor may be awesome for someone else, but not for you. Keep this thought in mind as you read on to the next paragraph.

While Gartner does provide market analysis for buyers with their Magic Quadrant™ and other services. The greater value is also mainly for the vendor. Being in the Magic Quadrant™ is great marketing for a company and they will freely and gleefully hand out copies of Gartner’s report and generate press releases and plaster it all over their website and spam anyone and everyone who will listen.

I will also add here as a side note that ESG’s analysis is much more focussed on helping vendors with product roadmap and strategy, whereas Gartner’s analysis is much more focussed on helping vendors with product positioning and marketing. While vendors absolutely benefit from both of these things, this is a subtle, but important difference. (Note that both do both things, but each focuses more on one than the other.)

But regarding that magical square (rectangle?) of awesomeness, coming from the vendor side, I’ll let you in on a little secret: getting into that elusive quadrant has a lot to do with how much time and money you are willing to spend on having an analyst come and evaluate your solution and after several years of having said analyst come and peruse your wares, you learn quickly how to position your solution to put it in the best possible light. You’ll also learn how to subtly Jedi mind trick the analyst to skew their market definition to fit your solution. It’s possible that I have first-hand experience in working for a company that had a product that was less than stellar (not mine; obviously all my products have been spectacular) that made it to the top right bit of that chart, so maybe it really is magic. . Unfortunately, magic can’t tell you which solutions best meet your specific needs.

Making Sense of Cybersecurity Market Messaging

Even industry leaders have a difficult time figuring out the security solution puzzle. At Black Hat 2022 (almost a decade since my first ) I was wandering around the business hall with a friend who also happens to be a branch chief at CISA and she was musing that it seemed like everyone’s messaging was the same and it was incredibly hard to figure out what anyone actually did anymore.

“Zero Trust” Cybersecurity

“Zero trust” was the buzz-phrase in 2022, likely stemming from the new norm of remote work ushered in by COVID. Literally every single solution, regardless of which security category they fit in, claimed they could help facilitate zero trust within your organization. But what is zero trust? (This is where I throw in the disclaimer that my last security product gig was at a company knee-deep in doling out the zero-trust Kool -Aid. To be fair, they are a pretty awesome data protection company and can probably stake one of the biggest claims on the zero trust “market.” I just think the term itself is stupid.) “Zero trust” really means “least privilege” meaning you provide everyone who has access to your organization the least amount of privilege that they need to do their job. Great concept. Stupid term. (Sorry John Kindervag I know research analysts like to come up with catchy terms and it is definitely catchier than 'least privilege', so I'll give you that. ��)

Regardless, zero trust isn’t a solution space. It’s a framework requiring a major overhaul to an organization’s data access controls. NIST has a great guide about why moving from role-based access controls (RBAC) to attribute-based access controls (ABAC) can set the foundation for building out your zero-trust framework. It’s a super informative document with helpful little diagrams like this one:

However, while it is great at explaining what you need to do and why, it’s not so great at telling you how, and really the impetus for this document was originally for super secret squirrel air gapped networks where only people who need to know know and those who don’t don’t (literally, the 'trust no one' crowd... and now that I think about it that way, 'Zero Trust' may be growing on me...hmmm... nope - still hate it). Regardless, if you have the time and money to overhaul your entire access control system, then it’s legitimately something to consider putting in place. I’m a firm believer in encrypting everything you can and providing access only on a need to know basis. It would solve a lot of security problems today (potentially almost all of them, but don’t quote me on that and don’t flame me with hate mail).

But why would, say… a SIEM solution advertise that they help you with zero trust? I mean, every security solution can probably claim it helps but if you don’t have the framework in place, then it probably doesn’t.

XDR: The Second Coming of EDR

Even as zero trust was having its heyday as the bestest way to 'secure' your enterprise, Extended Detection and Response (XDR) was also having its moment. Note here that zero trust is trying to 'secure' your enterprise, while XDR is assuming your enterprise isn't secure so you need something to identify and mitigate security breaches quickly. So, which do you really need? Well, you need both. They actually go hand-in-hand. Lock down all access on a need-to-know basis so that when (not if) you have a data breach, the damage is minimized, that is unless the bad actor (I have opinions on this term, but let's not go down that rabbit hole) happens to be able to compromise someone with a shitton of access, though if you really do zero trust correctly, you can compartmentalize access in ways that prevent this. But nobody does zero trust correctly.

XDR evolved from EDR (Endpoint Detection and Response), which is one of the OGs of security, where security is focused on all the endpoints (think: antivirus on steroids). XDR extends this concept out to also include monitoring network traffic (SIEM), email security, and cloud security. Though in reality, Incident Detection and Response (IDR) was already a thing and has been a thing for a very long time. There just weren't single solutions that did this. XDR is really just a single solution that does IDR. In theory. Remember that 'single pane of glass' I mentioned earlier? This is that... or rather an attempt at that.

MDR: the NEW MSSP

While Zero Trust and XDR were making the buzzword rounds, we also saw a rise in Managed Detection and Response (MDR) vendors - vendors who manage your XDR/SOC ops for you. Arguably, Mandiant created the MDR space way back in the day (pre-FireEye) when legacy Managed Security Service Providers (MSSPs) only did the detection part and not the response part. Once they detected a problem, they called up their customers and told them about it, said " have at it ", and then the customer was on their own to figure out what to do about it. Mandiant added the "R" to the mix. Gartner coined the term in 2016 (because of course they did), but Mandiant/FireEye had been doing it for more than 10 years by then.

With the advent of XDR attempting to be that 'single pane of glass' where you could manage your entire security ecosystem from one place, MDR gained a second wind with the realization that a lot of companies didn't have the bandwidth to implement and manage XDR internally, especially SMBs, so now we're seeing a lot of MDR startups entering the market, presumably to focus on SMBs.

And with these new MDR players cropping up in recent years, we now see the MDR market touting themselves as "AI-powered' or 'AI-native' because everyone needs to climb into the AI bubble to milk as much as they can out of it before it bursts. Plus the security industry ain't going away, so as long as they don't put all their eggs in the AI basket, they'll survive the crash.

GENAI = AI, But AI <> GenAI

You can't swing a dead cat these days without hitting a tech tool or solution touting its AI-ness. However during the first couple of years after ChatGPT launched in 2022, in the security space, the discussion centered around the security risks of (generative) AI and security vendors weren't as quick to jump on the bandwagon as other tech vendors. Agentic AI has a particularly insidious security risk, because in order for it to work, it has to have access to ALL the data, which is in direct conflict with everything zero trust stands for.

The irony here is that security solutions have been using AI for years, just not generative AI. In fact, I built a security product at Raytheon that used machine learning to detect potential security badness. But now, "powered by AI" takes on a whole different meaning that isn't necessarily a selling point to security product buyers.

Still CEOs and CMOs couldn't let the AI train pass them by and so we've started to see GenAI leveraged in other security tools, but sparingly. Even in MDR we're really only seeing GenAI used during the response and reporting phase (and during the investigation phase - to finally provide that elusive "single pane of glass"). We aren't seeing GenAI agents crawling through network and endpoint data to do the detection bit, though... and rightly so. That's not what GenAI was created for and this would be a ginormous security risk.

Another bit of irony is that security customers haven't bought into all the AI hype. The industry was quick to point out all the security risks when GenAI burst onto the scene, so it's hard to reconcile that with the new 'AI-powered' messaging security vendors are touting. It would probably behove these vendors to differentiate themselves from *just* GenAI. If I were a CMO (and I am most definitely not), I'd pick a campaign, like, 'AI-native before AI was cool.' AI is suffering from the same affliction inflicted on encryption when cryptocurrency became all the rage. Crypto <> Cryptocurrency, much like AI <> GenAI.

Regardless, there are other valid use cases for GenAI in security, especially in AppSec and DevSecOps to enforce secure coding practices and identify code vulnerabilities before getting released into the wild.

So What's the Point?

If you've gotten this far, you may be wondering what the point is to all of this, so here it is: the point is that researching security solutions and miring through all their market messaging fluff and jargon to determine your security needs is kind of backwards, when you think about it. You need to identify your security needs and THEN find solutions that can meet them. Seems easy enough, right? Well, it does until you realize that all vendors will tell you they do the same thing: secure your enterprise! But their solution is the bestest! They do it in the most super-est, awesomest way! They will not just secure your enterprise. They’ll super SUPER secure it! Yayyyyyyyyy!

The Enterprise Security Elephant in the Room: Nothing is Unhackable

OK, now that I’ve gotten that out of my system, we need to pivot here and address the elephant in the room:

There is no such thing as “more” secure.

When you secure something, you are making it immovable or impenetrable or… unhackable. You can’t make something more immovable or more impenetrable or more unhackable. Something is only secure until it isn’t and then it’s not. And to be quite frank, even when nobody is attempting to gain unauthorized access to your organization, your organization isn’t really secure. There are still ways to get in. I know I’m being pedantic, but the security solution industry knows this. They wouldn’t have moved focus from “protection” to “detection and response” if they didn’t know this. They wouldn’t be tracking dwell time as one of their most important metrics unless they expected intrusions. The term “security gap” is an oxymoron when you really think about it. If your front door is locked, but you have a window 2 feet away that is cracked open you don’t say your house has a security gap. It’s either secure or it isn’t. Your front door might be secure, but your house is not.

Security solutions aren’t really securing your organization. They’re just mitigating threats and minimizing risk, but saying “we’ll mitigate threats to your network” or “we’ll minimize your risk of a data breach” doesn’t sound as sexy as “we’ll secure your enterprise.” Keeping on the house analogy, your house will never be secure. A determined criminal could probably break into any house, but if you had an alarm system or a very large dog, then those things could mitigate threats and minimize the risk of property loss. Almost all vendors have shifted overall focus to fast detection and mitigation through swift response and remediation and that’s why we’ve moved beyond firewall, IDS/IPS, and secure gateways to incident detection and response, network segmentation, granular access controls, and easier, faster encryption. And that's why zero trust and XDR are the current darlings of the security world (and API security. but we can digress on this some other time).

So then do you really need these 'security' solutions? Yes! Absolutely you do! But the key is to focus on your needs and not on the solutions. Until you've identified your specific problems (where are your biggest security risks and what's your risk tolerance?) you won't even know if a solution meets your needs. Don't let vendors tell you what you need. Tell vendors what you need and then ask them if and how they can meet them. Don't succumb to the hype. Walk the floor, get the swag, go to the parties, and then go home and block their numbers and emails until you're ready to talk.

Who Will AI Really Replace in Tech?

Wed, 25 Mar 2026 01:27:39 GMT

The Fear is Real, But is it Warranted?

I was looking at some data with a few colleagues a few months ago on the makeup of SaaS companies built on AI (meaning they've woven AI into all their processes and built their company this way from the ground up) and SaaS companies not built on AI.

A couple take-aways:

The departments where AI replaces all/most people:

Marketing
Sales
Success/Support
Finance
HR
Executive leadership

We were musing that cutting way back on finance and HR can't be sustainable due to legal liabilities that are bound to ensue. The thought is that these companies expect to be acquired fast and early. Though if you have so few people in your org, there are fewer people to manage/pay.

Also there is something to be said about that personal touch �� in customer-facing roles, especially revenue generating ones, so as revenue grows, those departments start slowly ticking up which, in-turn, causes operational departments to slowly grow.

Executive leadership is interesting... it's way too optimistic to think that AI could be the great equalizer in wealth, but it's a nice dream to have. Also, this is against my best interests since I'm in executive leadership ��.

Engineering was leaner at the AI-first companies, but not non-existent. This tracks with my take, which is that AI is not at the point where it can replace engineering and GenAI never will be. It can augment engineering and make them more efficient, but IMHO, GenAI will never be able to build secure, maintainable SaaS applications.
- Websites: yes.
- E-commerce Sites: maybe.
- Prototypes: sure, but only if you are OK that it will be mostly throw-away code.

My unpopular take (and you can quote me on this):

�� AI prototypes are today's vaporware ��

But here's the most interesting part

The one department that had no material difference in staff between AI-first and non-AI-first companies:

�� Product ��

This surprised me at first, but after some thought, it made complete sense:

♟ GenAI can help refine, clarify, and enhance strategy, but it can't create new strategy.

�� GenAI can help brainstorm, but it can't determine what's worth pursuing.

��‍�� GenAI can help innovate to make something that exists better, but it can't invent new things.

I'm going to pack this innovation versus invention concept away for now, but it's important because it's a common thread that I'll come back to again and again. The important thing to note now is that product management requires real human thinking, which requires real humans. I'll add here that product management is also usually undervalued and understaffed, which may also account for fact that there was no difference in product headcount in AI-first and non-AI-first companies. I firmly believe that AI can absolutely make product management more efficient, potentially reducing necessary headcount. The AI-first companies are probably the only ones that are adequately staffed.

And so with that, if you are lucky enough to have found yourself in product management, congratulations! �� You have picked one of the most AI-proof careers... that is IFF all companies value product management and not all do, but those that try to replace us with AI will undoubtedly fail and then we can all feel smug in their downfall.

Startups: When to Hire a Product Manager

Tue, 24 Mar 2026 22:25:29 GMT

We Don't Need No Stinking Product Management!

The Birth of Software Product Managers

I started out my software career as a subject matter expert (technically a “Business Analyst”) at the turn of the century – 1999 to be specific, with Y2K looming over our heads. But I didn’t need to care about Y2K, right? I was an SME. Issues regarding 2-digit years and the new millennium were not our concern – that was engineering’s problem.

I was working at a "startup" that was about 8 years old when I got there. It wasn’t technically a dot-com. It was a fat client/server application. I don’t remember if it was PowerBuilder or Java Swing, but it was something of that ilk. As I mentioned - this was in 1999. This fact alone would date myself with other old AF people like me, but if you were born after the 1900's you might be thinking, " WTF is PowerBuilder ��?" The answer to that is: you don't need to know unless you really really want to get a job maintaining sexy legacy banking and manufacturing systems. Really, even if you do, leave some tech jobs for us olds who hate change and want to bathe ourselves in old technology and reminisce about the days before the interwebz when "user experience" wasn't a thing (or rather, it ranged from tolerable to atrocious) and you had to install shit on your Windows 98 computer and update it over and over again in order to use it - almost as many times as you had to update Windows 98 - and you couldn't work from home because your computer and all the applications thereon were at work.

(As a side note, the fact that PowerBuilder still exists and is being maintained and updated today would seem to indicate that anything that moves "at the speed of business" isn't really moving all that quickly.)

Look at this beautiful PowerBuilder app! I almost forgot how it opened up separate windows in random places for everything, which was super convenient for finding the thing that opened up the last thing before you closed the other thing. It's in black and white because it's so old, it was created before color pictures ��. Hey! Remember Netscape? (If you don't understand why I ask, you probably don't.)

Fun fact: I was a product manager at AOL for like half a second. I managed webmail. One of my tasks was to integrate Netscape mail and AOL webmail, but I wasn't there long enough to complete said task (or any task really). I was also tasked with figuring out how to provide a seamless user experience when switching between AOL webmail and AOL desktop mail, because... wait for it... they didn't share the same database. I mean, why would they? I was silly for asking. That's just crazy talk. When I asked an engineering VP when they decided to build something on the client versus the server, he shrugged and said, "we do stuff based on whichever team has the most bandwidth." Oh. Ok. That makes... um.... NO SENSE WHATSOEVER. Anyway, that's why I got the hell outta dodge faster than you can say, " Keee-errrrr-beeee-eep-ong-dee-ong-waaahhh-urrrrrr. You've got mail! �� "

OK, so, back to my first product management job... when I was hired there was a push to re-platform all our products as web applications. If you recall they were initially client-server applications, but with the advent of the interwebz we were doing something crazy called "modernizing". This was before SaaS was a thing, so you still needed to install the software on a server hosted by you, so it was web-based, but you could only access it via your internal network. This gave you the added convenience of being able to access the application from any computer attached to your network (rather than having to install something on everyone's computer). As a bonus, this also let you secure the application and its data within your network, rather than exposing it to the evils of the whole world, but eventually that bonus was forfeited in the name of convenience, which is par for the course. In today's world convenience always trumps security, much to the detriment of society at large.

Sorry, I digressed again.. my first company built global trade compliance software - essentially software that helps you file the right paperwork with a country’s customs agency to properly import or export your goods into/out of a country - though there are a lot of complex rules depending on what you are importing or exporting, in addition to rules from other agencies like Food & Drug and Agriculture and Defense. Also, duty rates (also known as tariffs) are actually very carefully assessed based on what each country produces and what each country doesn't produce but needs. Assessing a random flat tax against random countries is, in two words, pure dumbassery. I'm just throwing this in here to illustrate the complexity of trade rules and not for any other reason that may or may not be relevant to current events.

So I was hired because the current SME was having a really hard time translating government regulatory requirements into something an engineer (with no domain expertise) could code off of. When I interviewed for the position, I happened to be an expert on US Customs import rules and regulations with no experience in software, BUT I had a technical degree.

The hiring manager was excited that I had taken programming languages in school. I told her that it was Pascal and Fortran, so I’m not sure how valuable that was. (This was before I learned to... embellish my qualifications to appear as qualified as possible, though this was also when tech companies were throwing money at people with marginal experience... Y ou have a degree in bagpiping and puppetry? YOU'RE HIRED! ⬅ This isn't really much of an exaggeration. I had a friend with an art history degree and she got hired at a tech company and had absolutely no idea what she was doing and they didn't seem to care.)

Anyway, the hiring manager said, “I don’t care. If you know how to program, you know how to be logical and if you can be logical, you have the skills to translate business into tech.”

And lo and behold, she was right…

When I started there was no such thing as a product manager. I mean there was at companies like Microsoft, but at startups, the concept of such a role hadn’t really caught on. However, not long after I started when people figured out that I actually could translate business requirements into something engineers could code off of (I could even spoon-feed them pseudocode), the Product Manager role was born and I was the first one (I mean... not like the first one ever , but the first one at that company).

Bridging the Gap Between Business & Technology

It took 8 years for that company to realize they needed someone to bridge the gap between business and technology. The product I was hired to work on was brand new with no customers and in terrible shape. It was virtually unusable. During my first week there I attended product training for the product I was taking over, and I had no idea what was going on within the application and I UNDERSTOOD the regulations and the processes - or at least I understood what the processes should have been. Even the instructor got confused and lost. Several times.

The company already had an established product to help with export regulations, but export regulations are infinitely less complex and easier for laypeople to understand than import regulations (my inherited product's wheelhouse). There is no doubt in my mind that, had I not been hired, that product would have failed. I know this sounds super braggy and I don’t mean that it had to be me specifically, but they needed someone different than the non-technical SME that I replaced. (Stay tuned for a follow-up post on my unpopular opinion that the most effective product managers need to have a technical background.)

This was also during the dot.com boom when anyone and everyone was building a cool consumer web app and getting scads of investor capital with ridiculous valuations, even with half-baked monetization plans. On the other hand, most business applications had been built to automate historically manual processes, and everything was based on what customers (or potential customers) asked for. Very little time was invested in effectively predicting future customer needs and building them proactively, perhaps because nobody was all that good at this yet (remember Clippy?). The advent of SaaS ushered in the need for a B2B product manager to be more strategic, rather than just a glorified project manager. Effective product management now required equal parts strategy and strategy execution.

Incidentally, my first product still exists today, 25 years later. It was bought and sold several times over and (hopefully) re-platformed a few times, but it is still a viable product (this bit is intentionally super braggy).

Most Early Stage Startups Don’t Have Product Managers

Fast forward 20+ years and most startups still don’t hire their first product manager until several years in. 2-3 years seems to be around average - either that, or around the time the company has hired between 1 and 2 dozen engineers.

In cases where the founders are engineers, generally one of the founders can effectively act as the product manager (though not all engineers are good at this, which seems to contradict my statement above that product managers should have a technical background, but it does not and you're just going to have to hold your horses until I have time to write that post before you flame me). Also, in cases where the product is something familiar or tangible (most B2C products), it’s easy to get by without product management for a while if the engineering team is small enough.

What some companies fail to recognize is that product management isn't just about building roadmaps or executing on them. You need the visionary to set the vision first, and then you need someone to take that vision and execute on it. In a startup one of the founders may be the visionary, but if they can't take that vision and execute on it, then they need someone else to take on that role. You can't just throw a vision at engineering and expect them to produce anything close to that vision.

You Don’t Know What You Don’t Know

Many (not all) startups are created by engineers with a great idea, but they often know nothing of ideal customer profiles, market or market fit, product vision, etc. This is fine and perhaps even good. Too much structure and planning can squelch innovation and if they can manage to get an MVP out the door without outside investment, they won't have VCs breathing down their neck telling them what and what not to do (which can also squelch innovation, but in time having some guidance is a good thing).

Because product management tends to be an afterthought, startups often don’t start thinking about the skill until they start floundering. Maybe they can’t figure out who their ideal customer is. Maybe they know their ideal customer, but they aren’t gaining traction because they aren’t prioritizing the right features. Maybe they aren’t getting anything done because startups with no product oversight often like to squirrel to the next bright shiny object only to be distracted by another bright shiny object.

I’ve been hired as the first product person in most organizations I’ve worked and the one thing that everyone has told me is, “I wish I would have hired you sooner.”

There is this sweet spot within a startup, usually sometime after MVP and sometime before the company starts floundering (at some point, without product oversight, the company will start floundering, even if otherwise successful), is where they should start looking for a product manager. (Technically, the first product person should be a founding member of the company or one of the very first hires, but I realize that this isn't always feasible, so at/around MVP can be early enough in most cases.)

The first product person should be a combination of strategic and tactical. They should have several years of experience. Often companies will try to train an intern, or move an engineer, or hire a project manager to fill that gap, but you need an experienced product manager who’s willing to roll up their sleeves and work alongside the engineers day-to-day, as well as talk with stakeholders and customers, while putting in place a process for their role. They also need to be able to work with the visionary to create and evolve a vision and a strategy that drives the roadmap. They cannot be someone who just builds roadmaps and defines OKRs and throws them over the wall at engineering. They also cannot be someone who just works alongside engineering to execute on a roadmap created by someone else (a project manager's sweet spot). They need to be able to set and evolve strategy and vision, build a roadmap towards that vision, and then execute on that roadmap with engineering.

It's actually a very rare person who can excel at both strategy and execution equally, and a single person doesn't necessarily need to be wholly responsible for both, but someone in the company needs to be able to compensate for any talent gaps, so when you start to think about hiring your first product manager, you need to figure out what skillsets are most important for this person to have, based on the makeup of your current team.

Introducing: H3ATHER in Tech - Adventures of a Product SH3PHERD

Mon, 23 Mar 2026 01:16:18 GMT

Welcome! Come on in!

Meet Tank, Rocket & Thor my three favorite coworkers. They don't actually do any real work, but they do provide me with a good reason to actually get up from my desk during the day, walk around, stretch, and take a short mental break, which is important. I'm the type of person who can get so lost in work that I'll even put off getting up to pee until I absolutely can't stand it (which is a really bad habit, especially if you want to avoid wearing diapers in old age).

Tank, Rocket & Thor are Shiloh Shepherds. If you google "Shiloh Shepherd" Tank actually shows up as the first picture in an image search, and Rocket shows up in the top 10.

I won't bore you with the history of Shiloh Shepherds, but you can see that they are related to GSDs. Anyway, Tank's full name is Gen. Ulysses S Grant and Rocket's full name is Gen. Don Carlos Buell, who are two of the Union generals who won the Battle of Shiloh . I couldn't bring myself to naming Thor after Sherman, who was the other Union general because he was a horrible human being ( just Google the words "general sherman native americans" and you'll get the gist), so Thor's full name is Capt. Ambrose Bierce who is a famous person who fought in the Battle of Shiloh (and if you were ever forced to read An Occurrence at Owl Creek Bridge or watched the movie short, you've heard of him). Yes I am a big dork. I'm an even bigger dork because their nicknames are Tankasaur, VelociRocket, and MosaThor.

When I created my personal brand logo I wanted to pay homage to the mutts, and I got the idea of incorporating a shepherd in the logo, and so that's how the H3ATHER in Tech logo was born. If you look closely, the dot over the"i" is actually a ball sitting at the shepherd's footses (or I guess the more technical term would be "pawses"). As a side note, AI image creation tools are still just "OK" these days, especially with graphics. It took A LOT of tweaking and time to generate that shepherd image.

After all of that, I made it a personal challenge to incorporate my pups anywhere I could on my site. It started with my 404 page. That's Tank looking sad and pitiful, probably because he wants to go outside.

Coming up with a blog name is hard.

When I got around to starting my blog, I needed to come up with a good name. Tying it into the doggo theme didn't occur to me initially so I used ChatGPT at first and it came up with a bunch of craptastic suggestions.

The only passable suggestion was "The Product Whisperer" but I'm sure that was probably taken and it's also kind of trite.

But then it occurred to me that product management is a lot like herding cats. If you are unfamiliar with the origin of that term (or at least the origin of the term's mainstream popularity), it was from a Super Bowl XXXIV commercial in 2000 for EDS, which was an IT consulting company. This was back when tech companies were throwing money at everything and everyone and trying to outdo each other with the best Super Bowl ads. It was also the year I became a product manager for the first time (see my second blog post for the origin story of my product management career).

It was only after I considered naming my blog "The cat herder" that I realized that the perfect name was staring me right in the face...

... and so, "The Product SH3PHERD" was born.

A lot of people will tell you that product managers are like the "CEO" of their product, but that makes it sound like they spend their time strategerizing and then decreeing their strategy down to the masses with trumpets and elaborate hand gestures followed by a mic drop, which is the signal to said masses to scurry away and immediately start executing. (If you happen to be reading this and you are an actual CEO, don't @ me; I'm being hyperbolic. <cough>probably</cough> ) However, the real role of a product manager is to create a strategy, map out a path to get there, get everyone to agree on where you're going and how you're going to get there, and shepherd everyone along that path so that everyone arrives at each waypoint along their journey together and on time. This means setting those waypoints, removing obstacles, and minimizing diversions along the way, all the while making sure everyone is traveling together at the same pace, without leaving anyone behind.

So based on all of that ⬆⬆⬆, "Product Shepherd " is a much better title than "Product Manager ", eh? That term also illustrates the love most product managers have for their products and product teams. Shepherd dogs will risk their lives defending their flock. I can't say that I would ever risk my life for my product, but I have absolutely risked my job to protect my product and product team. A great product manager will internalize her product, lead with conviction, mitigate distractions, and fight to move forward and stay the course.

Shepherds aren't just needed in product.

This concept that tech companies need shepherds instead of leaders isn't just reserved for product management. It translates across all departments and all management levels, especially in a start-up environment. This is why I named my tech consulting company SH3PHERD . But this isn't (just) a shameless plug for my consulting services. This is to provide insight into how I think about things and highlight the fact that this blog isn't just about product management, even though that will definitely be a focus. It's a blog about my thoughts on and observations of the software biz as a whole, what the industry needs (hint: AI is included, but it's not the deus ex machina that everyone seems to think it is), and perhaps more importantly - what needs to fundamentally change.

I find it incredibly ironic that t he industry whose entire purposes is to effect change is the slowest to embrace change .

So how do we fix this?

I've got a bazillion ideas crammed all up in my crowded brain just itching to bust their way out. And that's why I created this blog.