Beyond Product Management · 2026-08-27 · 13 min
Key moments - from our scoring
Substance score
27 / 100
Five dimensions, 20 points each
Least privilege is commonly understood as a security principle, but Heather Miller argues it's fundamentally a product decision masquerading as an IT issue. From security, the logic is straightforward: every access point is a door, and fewer doors mean less attack surface and lower blast radius from compromised accounts. From product, the question differs entirely - it's about enabling people to do their jobs well by mapping access to roles and actual responsibilities, not theoretical future needs.
Miller highlights a critical gap most organizations miss: access creep. Employees accumulate permissions over years as they move between roles, get promoted, or take on special projects, but rarely have old access removed. This creates permission structures that no longer reflect reality. The "just in case" trap - where IT grants broad access to avoid future friction or product teams copy outdated permission sets - masks deeper role definition problems. She provides a practical six-point framework: map access to roles (not people), ask "what's the job" not "what could they need," treat just-in-case requests as role gaps, audit on schedule, remove access during role changes, and make every access decision active rather than inherited.
Least privilege means giving people only the access they need to do their job, reducing attack surface and blast radius if passwords are compromised or accounts are misused. Every door or system access a person has is a potential risk, so fewer unnecessary access points means less exposure.
It's tempting because granting access now feels easier than handling new requests later, and nobody wants to be the bottleneck blocking a new hire. But it creates unmanaged risk (security side) and masks undefined roles (product side).
Access creep occurs when employees accumulate permissions over years as they change roles, get promoted, or take on projects, but the old access is never removed. After five years, someone's account may have permissions across 12 systems when their actual job only touches three, because each past role left a residue behind.
Map access to specific job responsibilities and roles, not to hierarchy or theoretical future needs. Ask 'what does this person need to do their current job well?' rather than 'what might they need someday,' and treat every just-in-case request as a sign the role hasn't been clearly defined.
Don't wait for someone to request access - audit on a regular schedule. Also remove or adjust access whenever someone changes roles, gets promoted, or moves to a different team, not just when they're offboarded.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode delivers a competent explainer on least privilege but never moves past foundational concepts that any security-adjacent product manager would already know. The dual-lens framing adds mild value, but the ratio of novel ideas to explanatory padding is low for a 13-minute runtime.
Over provisioning isn't generous. It's usually a sign that nobody did the work of defining the role clearly in the first place.
Access creep. We talked about it just a second ago.
The security-plus-product framing is the episode's only real angle, and while it's a fair reframe, it isn't developed into any counterintuitive or first-principles argument. The 'jobs to be done' application to permissions is mentioned but not pushed anywhere surprising.
Security asks what's the risk? Product asks what's the job? Both questions land in the same place.
Think about it like when an old kingdom used to have a fortress built.
Solo host episode; the host cites nearly two decades in product and a security consulting practice, but there is no verifiable evidence of large-scale practitioner experience and no guest to bring independent credibility or depth.
I'm also the CEO, co founder and security and business strategist at PDRM Consulting
the lens I spent almost two decades living in before I started PDRM Product
The episode relies entirely on a single composite hypothetical (the marketing coordinator scenario) with no named companies, real breach examples, metrics, or dollar figures anywhere in the transcript. Every claim is asserted without evidentiary grounding.
Picture a mid sized business bringing in a new marketing coordinator.
someone whose actual job touches three systems, but whose account now has permissions across 12
Solo monologue format makes it impossible to evaluate interviewing craft; there are no questions, follow-ups, or pushback moments. The structure is a tidy lecture with a six-point checklist but no conversational tension or depth-generating exchange.
I'm flying solo again, so it's just you and me digging into a topic
Run through those six and you'll catch both the security risk and the product confusion
Computed from the transcript - who did the talking, and the words that came up most.
Least privilege isn't just a security rule - it's a product decision. In this solo episode, Heather breaks down access control through two lenses that don't usually talk to each other: security (reduce risk by limiting who can touch what) and product (give people the access their role actually requires, no more and no less). She walks through why "just in case" access requests are tempting - and wrong - from both sides, how access creep quietly builds up over years, and closes with a practical six-point checklist you can run on your own team's access setup.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Welcome back to Beyond Product Management, where we look beyond the day to day of product work and focus on the real stuff that fuels your career. I'm Heather Miller, your host. I'm also the CEO, co founder and security and business strategist at PDRM Consulting, where I help entrepreneurs and business owners step into the strategic, visible, and impactful roles they deserve. Whether this is your first episode or you've binged them all, I am so glad you're here today. I'm flying solo again, so it's just you and me digging into a topic that's come up almost every client I've worked with lately. Least privilege. If you've spent any time around cybersecurity people, you've heard this phrase. But I want to do something a little different with it today. I want to look at it through two lenses I live in every single day, security and product. Because it turns out, this isn't just a security role. It's a private decision. And when you look at it from one side, you miss half the picture. So grab your coffee, get comfortable, and let's get into it. I'm so glad you're here. So let's start where most people start. Security. The principle of least privilege, from a security standpoint, is simple to state one the people who need access should get access and have the access. Every person, every account, every integration you add to a system that's a door, and every door that doesn't need to be an open is a door that's just sitting there as a risk, right? This isn't theoretical. When you reduce the number of people who can touch sensitive data or critical systems, you reduce your attack surface. You reduce the blast radius. If a password gets phished, if a laptop gets stolen, if a disgruntled former employee still has a login, they shouldn't. Fewer doors looks less exposure. That's the whole logic. Think about it like when an old kingdom used to have a fortress built. The the less entry points, the safer they were, right? From a pure security lens, the answer to should this person have access? Defaults to no until proven otherwise. Access is a liability you take on, not a convenience you hand out. Access isn't just about who can get to the file, but also about what they can do, right? Sometimes you only want certain people to be able to read and view, but not edit and delete. We've all had this happen. You get it as read only. And yes, it can be inconvenient, but it's necessary. That's lens one, necessary. But as we're about to get into incomplete on its own. So we're going to flip to the lens I spent almost two decades living in before I started PDRM Product. From a product perspective, the question isn't how do we minimize access, it's what does this person actually need to do their job well? That's key. To do their job well, right? Access from this angle isn't just risk, it's enablement. If someone's role requires them to see certain data, use certain tools or make certain decisions and they don't have access to do that, you've just built friction into your own product, your own team and your own workflow. This is where product people think in terms of roles and jobs to be done. Not what could this person theoretically touch, but what does this specific role require on a day to day basis to actually function? A uh, sales rep needs different access than a support agent. Uh, a contractor working on one project doesn't need the same footprint as a full time employee. Access should map to the work, not to hierarchy, not to convenience and definitely not to just in case. And here's the part that surprises people too much. Access is also a product problem, not just a security one. When people have access to more than their role requires, it creates confusion about ownership. It makes systems harder to reason about and it slows down onboarding because nobody can articulate what a role actually needs. Over provisioning isn't generous. It's usually a sign that nobody did the work of uh, defining the role clearly in the first place. And defining a role is necessary because just throwing everything at the wall is just as bad as not giving anything to everybody. So the product lens agrees with security's conclusion. Less is more. But it gets there by asking a completely different question. Security asks what's the risk? Product asks what's the job? Both questions land in the same place. And access should be intentional, not automatic. That's if we're both doing our jobs correctly, right? We're trying to get there through good reasoning. And that's where we're having this conversation. So now let's talk about where the break breaks down in real life. Because it does. Constantly. I want to walk you through a scenario I've seen some version of over and over with clients across different industries. And I've seen this in corporate world as well. Picture a mid sized business bringing in a new marketing coordinator. Her role really only requires access to the content management system and a couple of analytics dashboards. But when the IT ticket goes in, someone on the op side thinks well, she might need access to our customer database at some point for a campaign, right? And adds it someone else thinks, let's just give our access the same access as the last person in the role so we don't have to keep going back and forth and copies over a permission set that's three years out of date and was already too broad when it was created. Now she has access to systems she'll never probably touch. And nobody made an active decision about it. Just happened by default. Because saying yes was easier than asking why. But that old marketing coordinator came up through the ranks. She was support before she was doing all these other jobs. She wore many hats, right? Her just in case. This is the just in case trap. And it's tempting for both sides of the table. From the security side, it's tempting because it feels easier to grant access now than to have someone come back in three weeks asking for more and relitigate the request from the product or OpSite. It's tempting because nobody wants to be the bottleneck who's blocking the new hire from doing their job on day one. But here's the thing. It's wrong on both sides. From security, every just in case grant is m unmanaged risk sitting on the books. She doesn't know what she's doing. What if her password got hacked from product side? It's a sign the role was never actually defined. Right? You're patching a process gap with a permission setting. If you don't know exactly what someone needs, that's not an access problem, that's a role clarity problem. And giving them broad access doesn't fix it, just hides it. Here's the thread that I think gets missed the most. Because it doesn't happen in one dramatic moment. It happens slowly over time. Access creep. We talked about it just a second ago. Remember our marketing coordinator with her access that was just copied over from the previous marketing coordinator that came up through the ranks. Someone starts in one role and gets the access that role requires, then gets promoted. Or they move to a different team. Or they pick up a special project for six months. Each time, new access gets added. What almost never happens is anyone going back and removing access. Right? That role no longer needs. So five years later, you've got someone whose actual job touches three systems, but whose account now has permissions across 12. Because every past version of the role left a residue behind nobody ever cleaned up. Multiply that across an entire company and you've got permission structure that no longer reflects reality anymore. Nobody can look at someone's access and tell you what their job actually is because the access tells a completely different story to what now exists. This is exactly why least privilege can't be a one time setup decision. It has to be a maintained state. Access is not set it and forget it. It has to be revisited as roles change, not just granted as roles begin. Right, so let's make this practical. Whether you're doing this for your own business or you're the one asking your IT or OPS team to do it, here's a checklist you can run through on your next access review. 1. Map access to roles, not the person for every system. Can you say exactly which roles need access and why? And I want you to really think about the why. If the answer is everyone kind of has it, that's your first red flag. Number two Ask what's the job? Not what could they need. When someone requests access, the question isn't what might be useful someday, it's what does this specific current responsibility require? I really want you to think about that word require. 3. Treat every just in case request as a role definition gap. If you can't articulate why someone needs access, don't grant it. Go to find that role first. Number four Audit on a schedule, not just on request. Don't wait for someone to ask for access to review it. Set a recurring cadence to review who has what and whether it still matches their current role. Number 5 Remove access when role change roles change, not just when people leave promotions. Lateral moves project rotations should trigger an access review, just like offboarding does. 6. Make access decisions Active, not inherited Stop copying the last person's permission set as a shortcut. Every grant should be a deliberate yes, not a default. Run through those six and you'll catch both the security risk and the product confusion that comes from access that's drifted away from what people actually do. You know what? That's the least privilege from both sides of the table. If this got you thinking about your own team's access setup, I'd love to hear about it. We have a mini audit where we help you look at your biggest security issue from your perspective. It's fairly new, but it really does help us deep dive into one issue. If you would find this useful, find more information in our show notes. We would love to chat more and I would also love to chat more on LinkedIn or Instagram about what you found when you looked into your own systems about least privilege. Find me on LinkedIn or Instagram. Thanks for listening to Beyond Product Management. I'm Heather Miller and I will see you on the next episode.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
#19 - Brooklyn Zelenka: UCAN, Beehive, Beelaylocalfirst.fm · on Role-based access control100 / 100
Governance Is Functions: Why Your AI Won't Scale Without Discipline by DesignDisambiguation · on Role-based access control87 / 100
Securing AI Agents in the Enterprise: NanoClaw, Zero Trust Guardrails, and Governance at ScaleThe Enterprise AI Show · on Role-based access control78 / 100
Reducing Attack Surface & Evaluating Efficiency in Agents - Itamar Apelblat, David Goldschlag - ASW #389Application Security Weekly · on attack surface reduction78 / 100
How a Solo Dev Hit 10K MRR by Selling to UniversitiesThe Indie Hacker Podcast with Fexingo · on Role-based access control76 / 100
Operationalizing Marketing as AI-tooling evolvesMarTech Podcast ™ // Marketing + Technology = Business Growth · on Role-based access control60 / 100Managing It All (When You Actually Can't)41 / 100I Know I Can Help You. I Just Don't Know How to Tell You That37 / 100When No Is the Most Strategic Thing You Can Say37 / 100Why We're Pivoting - And Why It's the Best Thing I Could Do for You39 / 100What Real-Life Travel Teaches You About Running Your Business36 / 100