Christina, Astutely Obtuse staff writer, and dear friend sent me this rant:
The PO sends me this screenshot of a shopping cart for some online retailer with the comment “can we add this to (inventory control system). Nothing was called out on the page, the only thing that stood out was the maroon and white dress in the shopping cart. We’re wrapping up testing on (the new inventory control system), with the expectation that we’ll deploy it in two weeks. We had to stop everything in order to figure out what he wanted. We’re coming up on a year late on delivering the new system because he keeps doing things like this. He sees something he likes online and demands that we incorporate it somehow.
When I first started on this article, I titled it “your PO is a fucking child,” but thought it was too aggressive. It then changed to “your PO is actually a goldfish with ADHD," but that’s not fair to goldfish, nor individuals with ADHD.
I settled with the current title because I want to teach you about a concept that is the root of many frustrations between PMs and POs/clients… “Colomboing.”
Colomboing is based on the famous line from Peter Faulk’s character Detective Colombo: “oh, just one more thing.”
My personal experience with Colomboing was updating to a new version of an internally developed app, where we spent months discussing the user experience, workflows, the development of an on-rails process, uncovering functionality that had to be included, should be excluded, and wasn’t necessary but would be nice to have. Months… everyone signed off on the design and functionality. Tickets were created, work began, and then… it started… Colomboing.
Things that were determined to be excluded suddenly became a deal breaker if they weren’t included. The app was taken off rails and updated to what could only be referred to as a choose-your-own-adventure-style design (including dead-end routes where a Grue eats your family).
When we called out that we should focus on at least getting parity before making huge changes, the PO demanded that we give them what they want, so we did. Brand new functionality was added, a complex ranking system was built into the back end, and entire segments were being removed (all of which had dependencies that broke when we removed the sections [although, I should note that it didn’t matter because the PO wanted us to add most of the segments back in]). Even with all these changes, the delivery date stayed the same. We had a drop-dead date, that we had to meet.
His defense: he wasn’t paying attention during the planning phase because he was thinking about quitting.
As part of my graduate program, we discussed at length how to mitigate scope creep. A key strategy to mitigate scope creep is to have high levels of stakeholder engagement.
This is great for many instances where scope creep is a problem. Engaging early and frequently can really aid in stopping the death-by-a-thousand-needles effect of the little requests made that expand the scope throughout the project lifecycle. However, Colomboing is a different problem. Colomboing comes from high levels of stakeholder engagement to the point that they are always making tweaks, they are involved with every facet of the project, always adding things that they hadn’t thought of, or just saw online, or read in a magazine somewhere, etc. What can be done?
Step 1: Control the Engagement
It always amazed me how the villain of the week could have gotten away with things, had they just not engaged with the detective. We can’t —not—, interact with our stakeholders and POs, however, so this isn’t a valid strategy. Instead, we employ a bit of psychology.
I polled how PMs interact with their PO when they are looking for feedback, generally, they would simply send over the work that was completed, and then ask what they thought.
This is begging for a PO to Colombo the hell out of the project. Instead, you need to focus on how you frame the request for feedback. Don’t send over the work with a broad request for their thoughts. Instead, call out the specific work that is done, and always, always, frame it in reference to the POs' specific request.
Based upon the input we received from you last week, we’ve added the maroon and white dress to the background of the inventory entry page and changed all the typefaces to comic sans, 48 pt, and canary yellow. Does this match what you envisioned?
What we are banking on here is twofold. One, we are playing to their ego. We fulfilled your request, do you now think that your input was good and made the program better? Secondly, we are focusing on what the feedback is on. We are not soliciting more things to be added, we want to know what they think of the horrid font choice and the new background.
Step 2: Contextualize EVERYTHING
A former colleague believed in placing all new requests in the context of their impact on the existing work. I believe we can do better. Even if you have specific numbers to back up the impact, it’s still a bit nebulous when discussing it with someone outside of the project team, that is to say, it can just create more confusion.
Instead, discuss things in the context of the end-user. “Some of our users only have a 14-inch monitor, so a 48-point font can make things difficult to read,” or “we might have people with color vision problems, so canary yellow might be a bad choice for the font.” Accessibility concerns are always a good choice when trying to contextualize their request, as it frequently requires them to actually stop and think about what they are asking for.
How the request affects the end-users' typical workflow or any potential edge cases that should be addressed is also an important context to discuss. It should be pointed out that none of this is suggesting that you say no, it’s just a matter of forcing the PO to examine their request that goes beyond the gut response of “it’ll save us 30 seconds per interaction” or “it’ll save us $3.50 per week.” It also goes a long way to stop potential strategic misrepresentation.
Step 3: Introduce a Cooling Off Period
The reason I initially had called this “your PO is a fucking child” is because of a phenomenon that I’ve seen a lot (not only with POs but also C-Suite individuals). That is, they see something, they want it, they demand it. My fun example was a time when a division president heard about third-party software at the morning meeting. By 2:30 that afternoon, a "hot-ask" had come down demanding this third-party software be integrated into our system by the end of the day. We didn’t have any documentation, it hadn’t been signed off by info-sec, and no one had even talked to their sales department about what would be needed to add this software.
The solution comes from staff writer Christina. The solution came as a result of dealing with her own Veruca Salt PO.
Whenever a request comes in, she listens, repeats back what they want, then says “I’m going to need to discuss this with the project team, it should be fine, but there might be some complications. How about you give me a few days and we’ll meet back on it next week to finalize the request so we can move forward.”
It sometimes doesn’t work, but usually, it does. By the time you meet back with them, the fresh newness of the request has worn off, and they’ve moved on to the next thing they saw when trolling a shopping site that is populated with text that was clearly run through Google Translate one too many times.
Even when it doesn’t work, it’s still incredibly valuable, as you are now assured that the PO has serious buy-in, it’s not just some new whim.
Step 4: Don't be Afraid to Push Back
This should only be deployed extremely selectively, but sometimes you have to say no, or at the minimum, not right now.
Sometimes the request is so absolutely batshit insane, that you have to tell them no. Their request is poorly thought out and they should feel bad. I’ve never personally had to give someone flat-out, no, but I have had to say to them not right now and push the work to a later iteration/phase. Times when you would need to say no: It violates regulations, creates potential security problems, causes accessibility issues, can be costly or damaging to the organization, etc.
There is a gray area between no and not now, and that relates to when it doesn’t add any value. Many people would argue that if the project doesn’t add value, then it shouldn’t be undertaken. However, I would argue that instead, it should be “not right now.” Especially if it isn’t a huge request. Put the work in the backlog, and if the team has time, they can work on it. It doesn’t add value to the organization, but it keeps a stakeholder happy and that adds value to the project team.
Colomboing is a major source of frustration among project teams, but it doesn’t have to derail a project. With a strategic approach to your interactions with the undercover Colombos, introducing a cooling off period to all requests, and pushing back when appropriate a PM can ease those frustrations, and in the end, push out a quality product without the added junk that was shoehorned in.
Or you could just work with your PO avoid this problem. Your manipulating them. Bad advice.