jtminor – PM'ing

The PM-o-Matic

At my first software industry job (Cataphora, an enterprise search and NLP startup), the CEO, Elizabeth Charnock, ran an in-house leadership training program, which was mostly just her sharing her thoughts on leadership. One of her main messages was that management was about being willing to make decisions, even though you’re probably wrong. You should try to make an informed, fair, optimal decision, but you very rarely have that privilege. Most people’s decisions are not optimal most of the time, and you should get used to, rather than fear, being wrong. The worst thing you can do in the face of incomplete information was abdicate making a decision. Being afraid of being wrong, and making the implicit or null choice was far more fatal. Her key to getting comfortable as a manager was to get comfortable making decisions even in the face of uncertainty and disagreement.

Fast forward a few years, and I was a first time product manager, in a mid-size mobile startup, where there were no other product managers or pre-existing patterns to follow. People from different functions would come ask me classic product questions, “can this product do this thing we thought of?”, “I need to tell a client this feature will be ready in a month, will it be?”,”whats the status of this bug thats annoying me?”, “can I cut this use case out, it will save days of development”… and so on… and on.

I tried to document and delegate, but when cornered, to answer questions and make decisions the best I could: informed and goal-focused. But I also remembered that leadership training. It was important to me to never abdicate a choice brought to me. Not to always have the answer, but to always be the decider or the delegator. But I also heard, and found to be true, that this was a mentally exhausting way to live. After a month or two my engagement with these small day-to-day decisions began to flag. I also read, around this time, that there is a limited amount of cognitive effort available in a given day, and decision making burns a lot of it. Some execs handle this by wearing identical clothes every day, sticking to strict life patterns, and otherwise trying to minimize the unimportant decisions they make. I decided that my way to handle this would be to take a piece of cardboard about the size of a piece of copy paper, and use a marker to write YES on one side, and NO on the other. Then, when someone came to me with a question, or decision point that I thought was basically a toss up, or where I needed to preserve my mental space and energy, I would flip the PM-o-Matic in the air, like a giant coin, and that would be my answer. Really.

I’m not sure how often it served as just the starting point to a conversation or negotiation, and how often its decisions actually stood, but I do know I felt like I was leading, but that some of the mental burden was off. Oddly, most people didn’t mind, its ridiculousness became a way to diffuse sometimes tense discussions, and mostly they were just happy to have a clear answer.

Two years after I left, I got a text from a former co-worker. It was a picture of the PM-o-matic. She had saved it after I left, and was now leaving too. She said she always appreciated my use of it to resolve questions quickly and with a sense of humor. I don’t use the PM-o-Matic anymore, and it’s certainly not something that would pass muster in a sophisticated product organization. But I’d still recommend it over making no decision.

Essential Cycle Meetings

Although the frequency, length and details may vary, there are some regular gatherings which I think are fundamental to building and maintaining “flow” in a high functioning software team. Here is my list of essential cycle meetings:

Grooming – Triage new tasks from your inbox (your task inbox, I mean). Assign all tasks a priority, and sort into backlog or active development flow. If there are no inbound tasks, review backlogs in priority order, closing or refining tasks only. Grooming can be a PM solo activity, a team leads activity, or open to the full team. Generally, it’s a waste of most people’s time, though. But for PMs and team flow, it is vital.
Planning – I prefer to do this weekly, but bi-weekly can work. This is the core team meeting. You can use it to review planned work, or work in progress. This is also the forum for longer presentations and proposals, and to have medium scale planning discussions. Always track action items and decisions, or have someone who does.
Stand-ups or Syncs – Short meetings to discuss the state of work and identify any blockers to progress. Lots of people like the “yesterday, today, blockers” standup format, where each team member gives a very brief overview of their work yesterday, today and brings up anything blocking their progress on current or upcoming tasks. Slightly longer sync meetings can also be useful. In that format the focus is often on the board and the progress of priority tasks, and burn-down, rather than team member status. This is particularly useful if deadlines are looming or as complex products, features or releases are in the “coming together” phase.
Retros – Facilitated discussions of the good, the bad and the ugly. If your group or organization doesn’t have people who can act as facilitators (scrum masters, project managers, etc), be sure to use a standard format, to avoid the temptation to monopolize the conversation, or play the process “by ear”, and thus bias it. The most important meeting if you want to improve the team, yourself or your product.
Walk-throughs – Walk throughs are a way for the team to “walk in the shoes of the user” together and collectively identify issues. This is especially good for improving “polish” and usability quality, but isn’t necessary for day-to-day changes. See this essay which gets into detail about this process.
1:1s – have at least 30 minute 1:1 with each team member and key partners or stakeholders every week or two. Always have something prepared to talk about, even if its social, but always defer to the other persons agenda, if they have one. Good meetings to have walking, drinking or eating.

Essential Tools

Software development can be a closed loop. The only tools you need to make software are software. Post-its and white boards are great, but what you really need is good apps. Below I’ll rundown the essential categories of apps and their roles.

Task management – A system where you can track work. You must be able to visualize the work of your team. People need clear task lists and priorities to execute your plans effectively. The most important tool for PMs. PMs who don’t intimately know and have a love/hate relationship with their task management software are PMs who don’t know how to operate a team. Know it, work it, customize it.
Calendars – A shared calendar system is key to almost any business. But for PMs it has special importance. Keep your calendar as public as possible and up to date. Set work hours. Always add agendas or at least comments to any meetings you create. Don’t expect engineers to use their calendars effectively. They often don’t accept or decline meeting requests and may not open their calendars very often. Always follow up in person or email, and be patient, as long as they show up when you need them.
Notes – Most people use cloud note systems, although me and plenty of other people I know use draft emails. It works well, and makes turning notes into/out of emails is easy. But whatever works. PMing is a complex job, you need to take notes, or have people take them for you. Notes and note systems are generally the way that passing thoughts and verbal communication make it into the task management system and thus into reality.
Wireframe or prototype tool – This is probably your UX or visual designers thing, but you should be familiar with this key tool. This is how specs and ideas become interfaces, so it matters.
IDEs – Similar to the above. This isn’t where you live, but its good to be a comfortable visitor. Its also good to know, at a high level, what kind of things their tools make easy or hard. Knowing the pain points in the dev chain is also helpful for understanding team flow.
Terminal – (Or Console or whatever command line interface.) It comes in handy. Its not as hard as you think. It buys you a ton of cred with engineers if you genuinely know your way around a command line, even just a bit.
Collaborative documents – Again, this is a tool any business team needs. But so do you. Don’t work on docs, proposals, specs, and so on alone or on local machine-bound word processors. Open your process up for comments and socializing.
Slideware – Decks are the distilled essence of product management. Persuasion, evidence, argument, narratives, and pretty much the whole job in hypercard form. Unfortunately most people are bad at decks, and give slideware a bad rep. But its worth taking classes or at least watching videos about how to create and especially give compelling presentations. It’s a developable skill and usually the primary high level persuasion tool, so it is worth it.
Chat – I hate IM’ing. But when you work with remote teams or from home, it’s your mouth and ears. Luckily, my distaste for synchronous text conversations is not, it seems, common. So you probably don’t mind, or maybe you even like, instant messaging. But if, like me you’re not a texting natural, you’ll need to learn to embrace it. Some people, often introverts, engineers or ESL speakers, are much more effective communicators over text.

Leading without Authority

One of the greatest challenges of PM’ing for people is often leading without authority. Generally, people do not report to you, and in some cases may report to people opposed to you or your goals. How do you get these people to execute? This is something I particularly see more business and analytical PMs struggle with. They know the theory, and they have a vision, but they struggle in the day to day of leading a team. If they can rely on their team leads and the culture, they can still execute, but it makes things hard. So, how do you get people listen to you when you are not their boss?

Power resides where men believe it resides. Its a trick.

There are libraries full of books and years worth of seminars and videos to teach you, but here’s some thoughts, techniques and observations:

Build Trust – This is the most important thing at the beginning. It is a prerequisite for all action and collaboration. It’s a cliche that trust is hard to build but easy to lose. But it is possible to build and rebuild trust: be reliable, be genuine, admit mistakes, don’t gossip or badmouth team members behind their backs, find a common enemy.
Genuinely Listen – If you’ve got a strong outgoing demeanor (a “type A” personality), or a strong vision and sense of self-direction, it can sometimes be difficult to stop, listen and really engage with people. Listen to feedback. Don’t interrupt. Admit where you agree first, before providing any defense. Listen to suggestions with patience, and don’t multitask when team members are giving their suggestions. Listening is not committing, and it is almost always worth the time.
Servant Leadership – It’s a real thing. Be the person who volunteers when no one else does. Clean up after people. Be the first to take blame and the last to take credit. It sets a good example, but it also gets you pile of goodwill.
Persistance – There’s really not much more to it. Be more determined than the others. Outlast any objections, politely declining to give in.
Take People Individually – For example, don’t treat engineers as interchangeable code machines. Learn what people are good at, and what excites or motivates them. Even if you can’t always accommodate them, the fact that you “know” them goes a long way. It also obviously helps in planning and assigning work to have this kind of understanding of your teammates.
The Shit Umbrella – Everyone knows this one, and it’s important to not overly isolate a team that needs context for motivation and planning. But keep out some of the noise of organizational politics. And above all take on the brunt of top down demands and scrutiny.
Trading Goodwill for Favors – Even just among a small core team, in many ways you’re playing very small scale politics. And, like all political systems, the core is the trading of favors. Don’t ask for petty shit and don’t cash in goodwill until you need to. But when you do, don’t be shy or reluctant to do so. Be genuinely kind and helpful, but call in your chits when the time comes.
Handling Dissent – How you handle teammates who disagree with you or your decisions plays a major role in how well the team will collaborate and work with you, rather than for or against you. Never make it personal. If someone is, or is being overly aggressive or persistent, take it to a 1:1, or their boss. Use data and evidence to disagree, when ruling against someone or their position. Never say “because I’m the PM”.
Did I mention persistence? People admire it, as long as you’re also open minded and delegate.

Essentially Metaphor

The intellectual core of managing the development of software is the editing of metaphor and analogy. If you strip away the business and team management components, the job of defining and iterating on a piece of software for people to use is essentially about creating, selecting and enforcing a bundle of metaphors.

This is because software, by its nature, is abstract. Crash Course’s excellent series on Computer Science even has a little recurring animation they play each time they move up a level of abstraction in the computing stack. The fact that this happens so often as to warrant a special bit shows how core this process of intellectual leaping “up” the chain of metaphors is to computing.

From my perspective, as someone trained in cognitive science and linguistics, Lakoff and Johnson‘s observation about the necessity of metaphors in abstract thinking and communication is exemplified in the way computers and humans interface. In this medium, there is almost no physicality (and as voice agents grow, the physical aspect of computing is further reduced into the purely audial). All understanding must map, though metaphors and mental models, to some experience of the real world.

No where is this more clear than the concept of skeuomorphism. This is the application of the visual look of real objects to their software analogs, on the theory that people will recognize and bring their intuitions from the real world into their new experience. This style fell out of fashion, the reasons for which are a whole other essay about dialectics and technology as fashion. But it is the easiest entry point for those looking to understand the importance of analogies to interfaces.

Another pervasive cognitive metaphor used in software is the “___ is a journey” analogy. A user story is a “journey” for the user. This makes some sense, but like all structuring metaphors it has a lot of implications and entailments that people wielding this metaphor are often not aware of. Users may wander on and off the path. They may never make it to a destination and still be satisfied. Not all who wander are lost.

As new interface paradigms become common, or as your UX designer pushes for some new pattern or another flow change, always watch the metaphors. The more consistent and intuitive the metaphor, the more productive the implications, the better. One thing that sets apart “product people” is not necessarily that they are inventive, but that they can crystallize an emergent abstraction. What does that mean? It means they can see the metaphors and analogies others are unconsciously relying on. They can identify the contradictions and tensions between competing analogies. They can empathize with the cognitive effort understanding a metaphor takes, and feel if it serves users well, or just adds confusion. They can look for commonalities, and take stories, features and technologies into a new level of abstraction.

Any Interface Can Be Free

There’s a meme floating around that some interfaces are, by their nature, less open, and will march us further into an easier, but less “free”, technological future. There, the human is cocooned in a machine experience they don’t understand, and have no control over, but which satisfies their every need.

I would counter that this is a choice. Just as GUIs abstract and limit what users can do, compared to the raw command line and programming, it is true that higher levels of abstraction, and simpler interfaces, do move the user away from total control over their computing experience.

And, it may be true that voice interfaces, and smart user agents, are inherently more difficult for a normal user to understand, and control the inner workings of, than it is with GUIs.

But I don’t see the evidence that is inherent in voice technology. I see these technologies, like smart speakers, being built in places, and with motivations, that push them to be closed. It is a logical progression that the user increasingly finds themselves at the mercy of a few companies’ optimization math. But it is a result of the business imperatives, not the technological ones.

Speaking to a computer is no less inherently free, or open, than typing at one. It’s easy for me to imagine recommendation systems, voice agents and other new forms of machine-human interface just as open and free as the web, or as collaboratively sourced as the Wikipedias.

There’s no reason I shouldn’t be able to ask a voice agent to cite its sources, explain its recommendations, or even take correction. There’s no inherent reason I couldn’t really have a free smart speaker, where I could provide my own voice, or specialized vocabulary, or reprogram and remix as I like. There’s no reason ads can’t be separate from information, in the things that are spoken to me by my smart assistant.

When Echo gives me an answer I want to say back “say’s who?”, and get a source.

When Siri gives me the wrong answer I want to say “that’s wrong. Correct it.”

When Google Now gives me a fact I want to ask “how up to date is that?” and get a last edited date and author.

All this is as technically feasible as anything these systems do now. These systems’ closed nature is capitalism’s limitation, not technology’s. It is only our culture and mindset that see self-determination, openness and freedom as an impossible or evaporating dream in cyberspace.

PM’ing in public

I work at a beautifully weird organization. The Wikimedia Foundation is transparent to the outside world in ways most people, even people who know our work (not the projects, but the Foundation) or support it through donations, don’t know.

For a PM, the idea of doing our job in public can be a bit of a challenge. Many PMs operate best in 1:1s and manipulating the flow of information. If things are transparent, not just internally, but, literally, public (as in both free to use/copy and viewable in the internet “commons”), how do you differentiate, prototype or otherwise get the element of surprise, so skillfully deployed by Apple and others? Well, you don’t. You accept that your goal is to be seen and copied, just like our contributors’ photos on Commons, our research, designs and products are to be shared, in the very hope that they will not just be seen and used, but copied and remixed.

But also it means all your tickets, even your teams RETRO NOTES, are there for anyone to see. Dad want to see your teams quarterly update for the executives? Future employer want to see a product proposal you wrote? It’s possible.

At first it weirded me out. I had expected to be reporting regularly to the public (it is a charity, and a place known for advocating transparency on the internet.) I had not expected to have my meeting notes made public by default, or the staff meetings to be streamed live to the world. Now it seems normal. But I had to gain confidence in what I was doing and remember every fucking day that nobody is perfect. My unfinished specs, tasks open and assigned to me way too long, flimsy rationales, sometimes aggressive politicking, they are all there for you to see, but they are not that unique. At least that’s what I tell myself. Plus, what you find is that, like your personality flaws, most people don’t give a shit, or even see the same shortcomings you see in yourself. We’ve had fewer than 50 people ever come comment or get involved with any of the public work my team has produced over 2 years (not counting code contributors). No one has time to read your specs.

And on the other hand, I get to do a job that’s usually among the most “proprietary” in the world, and do it in public. I wish more orgs would let their teams do their process in public. When there is no competitive advantage to secrecy, I think there could be great value to our profession, and the products we create, if more people who make great software could be truly open about their process.

To illustrate the level of transparency I’m talking about, you can see the “dark mode” feature’s development on wiki, Phabricator (our task management system) and public google docs. Not because we set out to do so, but because it is the default. From the planning meeting when the team first prioritized the feature. To the task tree, including the initial design thinking , the interactive prototype, design research presentation, the tech scoping, the implementation and iterations and bugs, the user testing and evaluative research, the QA test plan, the regression testing results, the public mailing list announcement of the beta test, my draft of the App Store text, the release checklist for actually pushing out that version, the clean up tasks in the following bug fix release, a post launch review and analysis I did for my peers, the quarterly report where I took a victory lap for the positive response, and the draft and final the blog post where my team leads wrote about how we approached all this. And that’s not even all the fingerprints of this thing on the public internet. This for a simple (but important) feature. All teams have these kinds of digital artifacts, ours just happen to be public.

If you’re new to product management, curious how it works, or just nosy about Wikipedia and Wikimedia, I recommend checking out some of our easier to digest stuff: our monthly metrics meeting (always streamed live on YouTube), our quarterly meetings, decks and notes, or check out the many links I posted about dark mode. It’s far from a perfect, or exemplary, organization, to be transparent about it. But at least its flaws, like my own as a PM, are all there to be seen, discussed and hopefully improved.

Make the easy stuff easy and the hard stuff possible.

Open source software sux at UX. Why?

Lots of reasons, of course, but one is that these interfaces and their creators are often focused on users abilities, and the full expressiveness of the software’s functionality, not on the users’ needs or capabilities.

For example, often, the free software drive to make everything controllable by the user leads to an approach to interfaces that make all that is possible, visible. They treat all functions equally, since the goal is just to provide all the tools and let the liberated user decide. This equality of features often also leads to interfaces that lack clear hierarchy, or are overloaded with menus, options and configuration preferences. Lastly, in these projects, design and particularly visual design are “extra”, and often not in the skill set of participants. The reasons for that are, really, I think, a separate discussion, touching on the gender of aesthetics and traditional roles in software.

But, all that said, full user control is a value worth preserving as software evolves. It’s something people who focus on licenses and patents as the core of free technology lose site of: if software is truly libré, everything a user wants to do, or change, should be possible, even if it is hard. Software may be freely licensed, but if it is impossible to use, or very difficult, is it really free for all? If it is to be a real practical freedom, free software must also be useable for all.

Finally, for software to be broadly successful, it needs to be not fully featured, but useful. It need not be fully customizable, but it must be intuitive. So how do these tensions get resolved in a way that pushes free software forward?

Larry Wall has a phrase that he applied to PERL, but could also be applied to open software interfaces: make the easy stuff easy and the hard stuff possible.

This is the way to bridge these tensions: make the things people most need from the software easy and intuitive. Don’t make the user invest in configuration, or understanding complex metaphors, or unique interface paradigms. But also, make the hard things possible. Don’t enclose everything in black boxes and “smart settings”. If the user wants to turn something off, let them. If they know better than your recommendation model what they want to see next, let them manage their own queue. For everything you make easy, also make it controllable, and understandable. Then it will be truly free.

Participatory Product Management

The reasons to make your product management and planning processes more participatory is a subject for another essay. Suffice to say, it’s something I think has powerful payoffs and, for me, is a strong cultural preference. By participatory, I mean involving other people in research, planning and even decision making in a real, genuine way. Anyone can ask for feedback, are you confident that you sold your strategy well internally? Let people vote anonymously, it may surprise you.

I’ve been lucky to work as a cofounder, in small orgs and now in a collaboration focused medium sized org, so I’ve had some practice at it. Here’s some tips for making your product management more broadly participatory.

A Few Ideas

I strongly recommend you adopt a kanban[LINK] or similar queue based work process. Don’t be dogmatic about it, but kanban is based on a pull queue and allows skilled team members to manage their own pace and have a sense of ownership of the tasks they take on. At the same time it allows you to maintain prioritiy and context. I believe scrum systems, in particular any system which requires negotiated sprint commitments is detrimental to the PM’s relationship with the team. It sets you outside the team and is focused on a tension (the scope the product owner wants vs. what the team thinks it can do).
I like to have teams perform a product self-evaluation. We pick a set of aspirations for our product or ourselves, (“sticky”, meaning hitting a certain user retention,”stable” which we’ll define to mean a certain crash rate). Prior to long term planning processes, we anonymously rate the product from 1-10 on these aspirations. This allows everyone to see how their peers feel about what they’re building together. It also can help to focus planning discussions if there is obvious consensus on the areas needing most improvement.
No spectators. All team members should participate in as many process meetings as possible. Design, QA, data analysts, ops, research… anyone who builds, rather than sells, the product should be at stand-ups, planning and retros at minimum. Then, run inclusive meetings. Open up the floor to everyone. Call people out in positive ways, especially if they are marginal (ie. not a lead or core member). Don’t let interrupters and loud mouths dominate. Don’t let men talk over women. Encourage introverts and non-native English speakers to follow up over email or in 1:1s where they might feel more comfortable participating genuinely. It takes work to participate, and it can be a great gauge of engagement and commitment. But in enabling and evaluating participation, be very aware of bias and culture.
In very healthy situations you can actually allow teams to vote on their priorities and it doesn’t turn out horribly for everyone! Here’s how it works: you’ll need a team that has a strategy and is bought into it, has some rough consensus (or a couple is okay), and a reasonable ratio of different functions (ie. this doesn’t work if their are 8 backend engineers, 1 frontend and 1 designer). I have used a weighted voting process to mixed effect, depending on the team, but sometimes resulting in a better plan and very high level of team commitment and deliver.It can be done in person or on a hangout, but in person is more effective at the emotional bonding and buy-in. This is a good activity to do at a retreat or off-site.

I do this after status and strategy presentations and discussions. This puts people in the right frame of mind, and reminds them there are shared goals and constraints they are operating under.
I write up potential epics on large post-its and put them on a wall.
The team write their own proposed epics and post them on the wall. People can ask questions about the scope and meaning of the proposals, and posposals might be edited, split or grouped at this stage.
I move any “must deliver” epics into the “approved” area of the wall. Try to limit these to existing/carry-over commitments and executive mandates.
Assign a budget of dots/stickers/votes to each team member. People can then vote by placing the dot/sticker/vote on a post-it. They can use their votes in any distribution they want, so they could put all their votes on their biggest priority or distribute their votes. Seeing how team members assign their votes and how they allocate their budget can be very revealing of people’s priorities and interests. Don’t forget to vote yourself 🙂
Remove any epics that received no votes. Allow each team member to assign one additional vote.
Guesstimate the capacity for the planning period (weeks of work is a good level of estimation). Order the winners by vote. For each do a very rough on the spot scope and estimate (again a week is a good level of granularity). Do not record these estimates and DO NOT USE THEM as commitments. DO use them to determine how far down the list to go. Move a reasonable number of epics to the approved area.
Review dependencies of the approved epics and identify tasks to be filed and next steps for each. Follow through. When you set up a road map, board or whatever manifestation “planning” has for you, be sure to point out the effect of the voting on the resulting roadmap.

Warnings

Don’t waste time being participatory if you don’t need or want to; only be genuine. It’s worse to tell people they have a say but actually dictate than it is to just dictate and be done with it.
These kinds of approaches and cultures are not great for making deadlines. But that doesn’t mean they are slow. In fact, I would posit that the velocity and agility of participatorily planned teams is greater than command and control or scrum-negotiation teams. Particularly for startups or where pay is lower and thus you need alignment via shared intrinsic motivation, rather than carrot/stick compensation and corporate laddering.
Introduce and practice these things cautiously and iteratively. Always retro. I cannot say that enough. But as you practice and iterate, also learn the nuances and tools available to you to subtly manipulate the outcomes, based on your particular skill, personality and context. Be genuine. Respect the outcomes of votes and take input seriously. Don’t try to damn the river. Learn how to channel it.

Contending with contemporary methods in design

If you’ve worked with designers, researchers or product managers who’ve been educated in, or advocate for “user centered design”, you’ll know it is well worth researching and learning about this philosophy and the processes it advocates. If you haven’t, see this standardized summary and this video by way of introduction. The original, complete, user centered design process is quite full and nuanced, and like many development and design systems it is rarely (never?) fully and completely implemented as envisioned. However, many of its methods and ways of thinking are useful, even without full adoption of the entire program.

Below, are some thoughts on some of these methods (not the program as a whole) and the good and bad of them, and how to deploy them effectively.

One of the main related methods of user centered design is user testing. This is the most important thing you can take from this. Watch users use your product. There are services and firms that can help you, but even you (yes you!) can record and observe a user while they use your product. Don’t intervene, don’t let them see you. Then ask them questions when they’re done. It’s never not informative.

I love user testing, and have used, and advocated for it, since I learned about it. But it is focus grouping. It will reduce the risk of confusing or failing the user, but it won’t find a compelling use case. Just as a focus grouped movie is less likely to fail, but focus grouping is unlikely to turn a shitty movie into a hit. You still need the need discovery. In user centered design they advocate for a generative research and prototyping process to achieve this. Personally, I’ve never seen such a process uncover a need that cognitive empathy with a well developed persona could not. But obviously these methods have been quite successfully applied by some. It does provide a lot of evidence for needs, though.

Which brings us to personas. Personas are archetypal users that represents a defined audience or role in the system. Often these read like the product of a marketer’s imagination, and that is indeed their origin. Usually they come with some cheesy name (“The Megainfluencer”, “Soccer Mom”, and so on) and some demographics. Even when developed specifically for your audience, I’ve found these to be of less value than user testing. Often they are good for organizing and explaining the product or its user stories, especially in documentation, but less valuable for decision making, or actual feature development. There, they can help develop empathy, and also help give focus and reality to stories and features. But I’ve been involved in very few systems or contexts where rich personas were more useful than just simple names for roles and user types, and associated needs or stories. I’d also strongly urge caution if using personas without real training in user centered design or marketing, especially if the personas involve people unlike yourself. It is very easy for a well intentioned amateur persona to become indistinguishable from an offensive bundle of stereotypes that reinforce bias rather than develop empathy.