I have struggled with personas for most of my career. Not because I think they’re useless, I actually really like personas. I’ve used everything from specific industrial roles like “Picker” to consumer personas like “Modern Mom” and “Tech-Obsessed Tim.” They can be a great way to understand who you’re designing for: their environment, motivations, technical literacy, habits, expectations, and all the other context that makes someone a real human being instead of an abstract “user.”
The problem is that eventually, personas always seem to collect too many jobs.
Imagine you have someone called a Robot Wrangler. They monitor a fleet of robots, intervene or troubleshoot when something goes wrong, do basic maintenance, operate or drive the robot when necessary, and occasionally change how the robots are configured. That’s a perfectly reasonable description of a real person at a real facility. It’s also five or six distinct relationships with your product hiding inside a single title.
At Customer A, that might be exactly how the work is divided. But then you visit Customer B and discover they don’t have a Robot Wrangler at all. Monitoring belongs to an operations lead. Maintenance belongs to a technician. Operating belongs to a floor monitor. Configuration belongs to an automation engineer. Troubleshooting is shared across all of them. Customer C divides the work differently again.
Eventually, I realized I was trying to force the customer’s org chart into my product model. What I actually cared about was much simpler: What are the verbs?
Someone monitors. Someone operates. Someone troubleshoots. Someone maintains. Someone configures. Someone does the work the robot is there to support. Those aren’t necessarily people—they are things people do. One person might do five of them in an afternoon. Five people might do one each. The same person might switch between several of them in an hour.
I started calling these roles Actors, mostly because I needed a working term. The useful part wasn’t the label; it was separating who someone is from what they are doing with the product right now.
Scaling Breaks Mental Models
Working in industrial robotics is where I first ran into this wall. You start developing and testing with anywhere from five to 15 or 30 or more people interacting with a fleet of a couple dozen robots. At that scale, you know everything. You know the facility. You know the people. You know why that one technician does that weird workaround every morning. You know exactly who to call when something goes sideways. And then it works.
Within a year, you have more than a thousand people interacting with 5,000+ robots across 30 sites worldwide. And if things are going well, nobody is interested in pausing deployment so product can clean up its taxonomy.
This isn’t just an enterprise problem. Startups can run into this fast when something built for a handful of pilot sites suddenly gets picked up by a major customer, or three, and have to operate at an entirely different scale. That transition is frantic—and it’s a terrible time to discover that your mental model of “the customer” was actually just your mental model of three people at your first site.
The beauty of separating the work from the person is that it’s cheap to do early. Keep your personas. Keep all that rich context. Just ask one additional question: What are they actually doing with my product in this moment?
That is the piece that scales. An Actor is a mode of interaction defined by the work performed rather than the title held. One person can perform as several different Actors throughout their day, and one Actor role can be performed by people with completely different titles across different customers.
What Verbs Look Like on the Floor
A few years back, I spent a week shadowing our on-site team across four consecutive ten-hour shifts. The team usually started out monitoring the system. If an anomaly surfaced, they were suddenly troubleshooting. Once they diagnosed it, they briefly stepped into an operator role to recover the machine. Next, they logged an escalation or summary report to hand off to someone else. Later in the shift, they might tweak a configuration parameter so the issue wouldn’t happen again. Depending on how the technology performed for the first half of the day, they may call in some extra hands from another department, or vice versa. And when the night shift showed up to relieve them, they clocked out and became bystanders to the very technology they were just running.
Their job titles never changed, but their goals did. That’s invaluable information when designing a product:
- What does someone need while passively monitoring versus actively troubleshooting?
- Can they move from “something is wrong” to “here is what is wrong” without jumping between three tools?
- Do they even need to know root cause, or do they just need to know the recovery steps?
- Once they know what’s wrong, do they have the right permissions to act?
- How do they know when they are done, and what happens next?
Understanding both the immediate verb and where it sits in the larger workflow has been far more useful to me than asking one persona to carry the entire weight of the product experience.
Calming Down Feature Whack-a-Mole
Once you have multiple customers, feature requests quickly turn into a game of whack-a-mole: “Can you add this status?” “Can I get an alert for this?” “Can this person have access to that?” “Can we add another report?” “Can I change this myself instead of calling you?”
You can take those requests literally and build a massive, disjointed backlog. Or you can ask: Who is trying to do what?
Maybe six apparently different requests from four customers are all coming from people trying to monitor the system. Now you don’t have six missing features; you have one poorly supported piece of work showing up six different ways. Maybe the information exists but is impossible to find. Maybe they can see that something is broken, but the handoff from monitoring to troubleshooting is clunky.
Sometimes the answer is still, “Yep, we need the alert.” That’s fine. The point isn’t to explain away customer requests. It’s to recognize patterns so you aren’t treating every ticket as a net-new problem. It also gives UX and product design a coherent problem to solve rather than forcing five new buttons wherever they happen to fit.
Sharper Roadmaps and Validation
This structure brings immediate discipline to user research, validation, and roadmap planning:
- Transferable Capabilities: In robotics, the person doing the work or using the feature often begins with engineering, migrates to deployment specialists, and eventually hands off to the customer. Instead of writing a vague roadmap item like “Make configuration self-service,” you can ask: What prevents a customer from doing this work today? Does the tooling assume you can write code? Are error logs cryptic? Are permissions missing or dangerous? The roadmap stops being an abstract milestone and becomes the concrete guardrails required to make that capability transferable.
- Recruiting by Action: Instead of recruiting participants based on job title, you recruit based on the work performed. Two people called “Maintenance Technician” might interact with the software completely differently, while a field technician and a customer lead might perform the exact same task.
- Real Validation Coverage: If a feature impacts monitoring, operating, and maintenance, you can check whether testing actually covered all three verbs. Talking to six people doesn’t give you full coverage if all six only ever operate the system.
Keep the Personas, Just Track the Verbs
Whenever I explain this, someone eventually asks: “Isn’t that what personas were supposed to do all along?”
Maybe. I’m completely open to the possibility that I’ve spent my career around personas that were used improperly and ended up reinventing part of the methodology. I’m also sure this abstraction is uniquely vital in complex industrial environments—where workflows cross hardware, software, shifts, and organizations—compared to simpler consumer apps.
Call them Actors. Call them jobs-to-be-done. Call them personas, or something better.
What matters is asking: What are the verbs? Who is monitoring? Who is troubleshooting? Who is operating? Who is maintaining? Who is deciding? Where do they transition between them? And where does your product sit in that journey?
Keep your personas to remember who your users are as people. Just don’t overload them with all the jobs.
