TBM 359: Process Person

I admit it. I’m a process person, in that I’ve intentionally designed processes throughout my career. Some of those have been baked into external products, and others have been internal.

Reflecting on my career, I remember many situations where I implemented bad processes. Most of the time, this was due to a lack of experience or contextual awareness.

One situation early on stands out. I was creating a template for a team. I did a lot of research and dutifully added different sections and instructions. I handed over the template and asked people to fill it out before each initiative. The problem? Depending on the context, only some of the information was required.

At first, people were too nice to let me know. They did their best to fill out each section. But eventually, someone did me a huge favor—they explained the problem and answered my questions. Together, we crafted a new template with more flexible prompts, examples, and an introduction that laid out core principles. The idea was that it would become a living document, not a form people filled out just to get through a phase gate. Everyone was appreciative, and the advice has stuck with me since.

However, there have been other situations that were nowhere near as clear-cut.

I observed a team in one part of the organization struggling, so I tried to set up what I thought was a lightweight way to ease the burden and help them anticipate upstream work. It "worked" for them, but other teams found it "too heavyweight." Lightweight and effective for some, heavyweight and wasteful for others.

Or the opposite. Sometimes, try as I might, I couldn't persuade one group (legal, say) that something less formal and structured might achieve their desired outcome—and meanwhile, even the less formal approach was too formal for product managers. It's hard to keep everyone happy in product ops.

Or I used an explicit process to teach and guide.

I worked at a company once that was just starting to figure out how to do structured, more inclusive discovery. As a UX researcher, my job was to structure these "design sprints" in a way that helped people go through the motions and learn how to work together in a new context. It was intricately planned out with a lot of structured activities. We had to plan in advance.

I learned recently from a friend that the team eventually "grew out" of the structured approach. They rebelled against it. Now, they do much more "freestyling" based on the challenges. To me, this is a signal of success. We needed to go through the motions to get to this point, and the rebellion was the right thing to do. I also matured my understanding of why and when to use certain approaches.

Process is also sometimes a necessity given current constraints.

Suppose you're short-staffed on designers and expect them to participate in discovery. In that case, you'll need to either synchronize schedules, get visibility across workstreams, respect their limited availability, or hire more designers. Of course, if possible, the goal should eventually be to remove constraints.

When our needs are met, we praise the process (maybe by another name). When something is a drag, we vilify it. If I attend a product offsite with expertly facilitated activities, I "love the process." I hate it if I'm forced to do something with no apparent benefit other than populating a report no one ever looks at.

I spend a lot of time interacting with people who are designing things to nudge or guarantee some sort of behavior, output, or result. Most of them avoid using the term "process" to describe what they're building. But what is a product, if not a structured set of interactions and constraints, designed to produce certain outcomes? Just don't call it a process.

The deeper issue—especially in product organizations—is that process design happens whether people acknowledge it or not. Sometimes, it's led by people without training in behavior design, service design, or systems thinking. Sometimes, it's led by trained people who lack domain knowledge or access to real research and perspectives. A non-trivial number of company operating systems are designed in haste by overworked chiefs of staff "in private" because people worry the team won't agree on how to work. Countless product processes are defined in a silo by a functional team without considering everyone's needs.

And sometimes, it's just a doomed attempt to satisfy everyone in an environment where no one is willing to make trade-offs, purchase decent tooling, or make an unpopular decision.

Leadership might ask for biweekly reviews of workstreams in slide format but won't invest in tools that make it easier to collect the data—or even question why it has to be slides in the first place. So teams trudge through a manual copy-paste exercise and performative status checks.

I met someone from a 2,000-person organization that spends $4 million a quarter ($16 million a year) on salary devoted to quarterly planning. The NPS is "less than zero."

Surely there's something-but-don't-call-it-process that could be improved? No? Make it easier to participate? Figure out how to get people aligned around the same information? Delete the hoops that don’t work?

So, to all the people out there intentionally designing that-which-shall-not-be-named…