The Gorilla Product Owner: It takes a village

“Bob,” Jake’s tone was almost plaintive. “You’re killing me here. I thought we had this all sorted out. Didn’t we just spend three days doing ideation work?”

Bob looked pained, he wasn’t happy and it showed. “We did and I thought we were sorted as well.” He gave a shrug, “Sales got wind of the requirements and threw a royal fit that we weren’t addressing performance on the OutDate hardware.”

“They do realize it’s a fifteen year old platform?”

Bob nodded, “And they insist it’s a must have to support ‘key’ customers.”

Jake grumbled, “fine, that explains that. What about this other stuff?”

Bob winced, “My boss isn’t happy with the strategy, he wants to alter course.”

I glanced over the new proposal. I made a note to talk to Bob about the concept of the word ‘alter.’ This plan was nearly a 180 from the previous one.

Jake threw his hands up in the air, “I give up. Every time I think we’re settled and I can start planning, the entire model changes again. Who the hell is in charge of the business plan?”

I could see Bob stiffen at that one. He didn’t respond, even though I could see he was rankled by the comment. I think he didn’t respond because he knew he really wasn’t in charge, even if his job description said that he was in charge. He had tried to put together a business plan and now, every time he turned around, someone was sticking a hand in and changing it.

“Sounds like you need to start the project before you start the project?”

“What is it this time, Hogarth,” I asked with no small amount of dread. Turning to face him I continued, “I’ve got Bob fully engaged with development, they’ve been meeting regularly. I’ve got an honest to goodness PO led product backlog for the first time ever.” I waved at the business plan on the screen, “and it’s all been tossed out the window. What’s the point? We are halfway through development and this is a huge shift in direction.”

Hogarth nodded, “Which is why you need a project before the project.”

I blinked, “Wait, what? That’s Big Design Up Front! We’re agile here!”

Hogarth gave me a huge, ivory filled yawn. “We covered this already, remember? Garbage in, Garbage out?”

I pointed a finger at Hogarth, “look here, I did that. Bob went through the whole process. We even brought in Jake and his team to look at some of the requirements. Our backlog was built on real requirements this time!”

Hogarth nodded, “And who else helped?”


Hogarth gave a long stretched before fixing me with his dark gaze again. “You wouldn’t design the features without the agile development team, why design the business plan without an agile business team.”

Blink, blink. Well dang…


 A Product Owner is Not an Island

Experienced agilists will of course be saying “duh” right about now. Product owners are supposed to work with the team and collaborate towards a final product. This is good and effective, and the PO can still be an island if they do this. He just has seven other cast-aways, from his three hour cruise, on the island with him.

Beyond even the question of “how do you prioritize the business value of the backlog,” are questions like “what’s the business model,” “what’s the product concept,” and “where does the product owner get his requirements from in the first place?”

The product owner is not an island. He doesn’t sit in some ivory tower and imagine great ideas, which he then transports to the development team in a puff of smoke smelling faintly of brimstone. Our product owner, still called a product manager by many companies, instead is sometimes reduced to nearly the level of a scribe collecting all the inputs from other parties and trying to justify how to have the product be “fast”, “ultra-secure” and “cheep.” The product owner must work and take inputs from a wide variety of sources in an often dizzying array of inputs and conflicting priorities. When every organization is clamoring for their little slice of the feature pie, you can end up with a product that looks more like Frankenstein’s monster than Brad Pitt.

 That’s just the way it is, you can’t expect that to change.

 It can if you make a village.

In Garbage In, Gorilla Out I propose a new model for the early stage of a product. In what most lifecylces would call the Concept and Planning Phases I propose an iterative, agile driven, style that takes you from product ideation (vision) all the way to a well ordered backlog that the agile development teams can plan their iterations from. While I don’t speak to this in the GiGo blog, in essence, what I am espousing is an agile project where the finished product is a product or release backlog. So if GiGo is an agile project, where is the team?

In GiGo I briefly touch on the idea of the GiGo project team. It is not just the product owner that moves through the GiGo project. With her on the journey are representatives from her key stakeholders. This is not a fixed team and will vary from company to company. Ideally it won’t be more than seven, plus or minus two people which may require some team members to then go off and work with an SME team of their own. For example a representative from Technical Support might have their own Support GiGo team where they review and bring back final “product” to the primary GiGo team.

Who should be on the team? Other than the product owner, again it depends. Below is a list of common team members based on the most common roles to contribute to traditional requirements documents.

Product Sponsor Customer  (or voice of the customer)
Related product managers Technical Support
Technical Architect* Marketing
Agile coach or Facilitator Sales

While the product owner is the final decision maker, she is not the only person to have input into the creation process. When the PO works with a village, they prevent the customer, sponsor and team from getting PO’d at them.

Do you have your village?

Gorilla Risk Impact- The "what" is more important than the "if"

OR: Probability just tells you how likely it is to hurt, not how bad it will hurt.

 “We have to fix it!” Carlos leaned forward in his seat, hands griping the table.
Decaf, man, decaf, I thought. “We’re a week from launch. Making changes to the code now is absolutely impossible.”
As Carlos turned beat red and began to splutter, I wondered if it was a common trait of Customer Service people or something they learned on the job. I’d lost track of the number of frothing support folks I’d dealt with in my time.
Carlos managed to keep his voice calm. “It’s a severity one issue. Complete and irrecoverable data loss. They get taken to bare metal. Support can’t approve this release.”
“Carlos,” I said, putting on my best “teacher” voice. “It would have to be a blue moon, in Australia for this bug to happen. It’s such a fringe case it makes the guy on the street corner with ‘The world will end tomorrow’ sign seem like a sure thing.” I closed the lid of my laptop and began to stand up. “I think we can put a pin in this one and move on, don’t you?”
I left Carlos spluttering at the table. He was saying something about stopping the release. I didn’t really pay attention. After all, he was in support, no one was going to stop the release over something customer support said.
I was opening the door to my office, when I heard a voice from within yell, “Duck!”
The paper airplane smacked me right in the eye, before I could even register what was happening.
“Ow! Hogarth!” I never realized how well those two words went together.
Through tear streaked eyes I saw my gorilla lumber towards me. “Hey, sorry about that. What are the odds of that happening, eh? I mean, here you are, back from your meeting ten minutes early. That never happens. Who would think you’d open the door just as I tried to hit it with a paper airplane.”
I shouldered past Hogarth (okay I bounced off Hogarth, into the door jam and then into the room. He is an 800 pound gorilla after all) and strode to my desk. “Well you should have thought! You could have put my eye out. Anytime you’re dealing with possible life and limb you should be planning for it.”
Hogarth turned to follow me. I could feel his eyes on me and I just knew I’d been set up. It always happened this way. “Here’s a question for you,” he said. “What are the odds a rain storm will cause a mud slide on Devil’s Slidethis winter?”
“Close to 100%, there is always mud coming down off the hills.”
Hogarth nodded, “Okay and what’s the impact to your commute?”
I rubbed my chin, trying to see where he was going. “An hour, maybe and just one time. They have crews on standby just for that contingency.”
Hogarth smiled, “And what’s the probability of an 8.0 or greater earthquake hitting the region?”
I shrugged, “Who knows, once in every fifty years, maybe.”
“I see,” Hogarth picked something from his fur and popped it into his mouth. “And what would the impact be?”
“Ugh!  An 8.0 would be huge. It took years to recover from the Loma Prieta. It was only a six nine and look what it did.” 
Hogarth’s eyes twinkled, “So which one do you want to build a survival kit for? The one hour traffic delay, or the life changing earthquake?”
Damn it! He’d done it again.


Tell me if you’ve heard this before, “It’s a fringe case,” “There’s a low probability of it occurring,” “What are the odds of that happening?”
I was once poor Carlos. When I worked in global support organizations I faced risk all the time. I learned a lot about risk management, how to plan for it, how to communicate it, how to mitigate it and most of all, I learned that most of the time the focus wasn’t on the “What” it was focused on the “If.”
“If that happens, we’ll have issues.”
“If the user pushes that button, sure it will crash.”
“If they are using Windows NT, who uses that anymore?”
Taking this approach is like lumping a $500 payout lottery scratcher ticket with winning the $500 Million Powerball lottery. The odds of both are slim indeed. Only if you win the $500 Million lottery, the impact of the win is going to be MUCH different.
To often we focus on “If” something will happen, when we really need to start with “What will happen.” If the odds of a database crash are only 15%, that might seem like it is fairly minor. If the database crash will cause a cascading network failure that brings the entire eBay auction site to its knees, eBay isn’t going to care if the risk only happens 15% of the time. It happened to them.
In my years I’ve come up with two tools to help with properly addressing Risk Impact.
LIKELIHOOD CHART: The first is more visual and is designed to get agreement and understanding from the team (see the image, below. Click to zoom in). The Likelihood Chart was something I came up with while still working in support. It mapped customer Severity to the Likelihood of the problem occurring. Then cells then had what the action item was for each combination of four severities and four Likelihoods.
This snapshot is an example of one use of the chart. The Likelihood meters can be adjusted up or down depending on the companies risk tolerance, Severity can be replaced by any impact scale the team agrees on and the action plan for each cell can be changed to suit the project and team agreement. What shouldn’t be flexible, is when you set this up. This should be agreed to as part of the project charter/kick off. Get everyone to agree before you have show stopping bugs.
RISK REGISTER WEIGHTING: The second was a simple bit of math I applied to my risk tracking spreadsheet.
 On the surface, this looks like an ordinary risk register. Impact and Probability are both a ten point scale with 0 being the highest impact/probability (unknown being riskier than any known because you don’t know) and 10 being no impact/mitigated. The magic is in the Total Risk Score. Here’s the “math.”
As you can see in this next image, Impact gets a higher weighting score than Probability. This means you can have a 100% risk even with a probability score of 4-Med. (For those doing the math, I have an excel formula that limits the maximum number in the Total Risk Score column to 100).
These are not silver bullets. I keep telling you, there are no silver bullets. Besides the one day you actually find the silver bullet will be the day you end up facing a vampire (you need wooden bullets for vampires). What they are, are two tools I’ve used in helping to make sure Impact (Severity) is the first thing the team focuses on.
Remember,  if their data center is an oozing puddle of goo, eBay doesn’t care if it was only a 15% chance edge case
Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla? Send me an email,
You can follow me on twitter, @JBC_PMP

The Agreeable Gorilla: the power of "And"

But we can’t do that.”

Not my best opening line, but Jake had caught me unaware. I tried again. “Look, using the Saskatchewan office to do the testing is a great idea, but it won’t work because we haven’t set up any network infrastructure with them.”
Jake gave a shrug. “Well we just need to get that set up then.”
I nodded, “we could, but that means working with IT on prioritization. You know how much fun that is.”
Jake asked, “Isn’t this project the key corporate goal for the year? We just need to explain that to IT, right?”
“Yes it is. We absolutely can explain this to IT, but I don’t think it will help much. They’ve already planned out their infrastructure work for the next four quarters.” I don’t think Jack was getting just how hard what he wanted to do was. The number of hoops we (I’d) have to jump through was staggering.
“Okay, I understand.” Jake was staying remarkably relaxed through all this. “We can still make the request though, right?”
I gave a shrug, “Sure we can, but they won’t say yes.”  Jake nodded but kept silent. “Okay, Saskatchewan is off the table, any other ideas?” I looked around the table hopefully but no one said anything. Sigh it was going to be a long meeting.
And  why do you think there are no more ideas?”
Sigh, the only thing worse than a long meeting, was a long meeting with Hogarth kibitzing at me. “I don’t know  that. Ask the engineers, they’re supposed to be the brilliant ones.”
And didn’t you just ask them?”
“Yes, but they’re sulking because their pet idea didn’t fly.”
“They are disappointed, I agree. And do you think your negative response might have contributed to that?”
Sigh, “Yes I suppose it could have, but you know how unlikely IT would be to agree.”
“Certainly, IT has been a bit rigid of late, and if you don’t ask, you will never know, right?”
Sigh, “Yeah, you’re right.”
Hogarth nodded, “Isn’t it so much easier when your not being butted to death?”
Blink, blink… But, but, butAnd, “Oh my.”
The power of “But”
Have you ever stopped to wonder at the power of this simple little conjunction? With three simple letters you can entirely negate everything that came before it and utterly replace it with what ever you say next.
“Certainly it looks like a beautiful day, but it’s nighttime right now with no moon so I can’t see a thing.”
See the power? If alchemists could harness the power of the mighty “but” then surely they would learn the secrets of turning lead into gold. After all, we all know that “but” really stands for “Behold the underlying truth!”
This one little word has the power to destroy communication.
And I believe that communication is one of the cornerstones to any team. Good communication will make the team better. Bad communication can completely ruin a project. “When you said blanco I thought you said you wanted the walls painted black. I didn’t know blanco meant white.”
Good communication also relies on collaboration. Nothing breaks a collaborative environment faster than a lack of trust. And how much are you going to trust the guy who keeps shooting down your ideas? “That’s a great idea, but I don’t think it will be practical to implement.”
Are you a but-head? Grab a pen and a piece of paper. Go to your next meeting and listen to everything you say. Every time you say “but” make a hash mark. You may find yourself very surprised. Now have a friend do this exercise for you. Odds are, there will be even more hash marks. We are so ingrained in the use of the word that we don’t even hear ourselves saying it. I’ve been aware of the dangers of this word for years, and I still catch myself going to this word at least three times a day. 

The power of “And”

Let us take in contrast the power of the lowly “and
“We could go to the beach, and after that grab a bite to eat.”
“I had a peanut butter and jelly sandwich.”
“That sounds like a good way to boost DB performance, and if we use pair programing we can reduce bug count also.”
It is simply amazing how much more open your communication becomes by substituting one three letter word for another. You take a conversation from a conflict, to a collaboration. From an either/or decision point to a “cake and eat it too” cooperation. 
Which do you think is more positive?:
“We were going to go to the movies, but we decided on going to dinner instead.” – This makes it sound like a bad thing.
“We were going to go to the movies, and we decided on going to dinner instead.” – Was there conflict?
Simple Team Exercise: Try this simple and fun exercise. It’s called the “Yes, and” story game and actors use it a lot for practicing improvisational theatre. Seat the team in a circle. Tell everyone you are going to tell a story together. The rules are simple. The first person says one to four sentences of a story. Then they stop and hand it to the person to their right (or left, but pick one direction and keep going that way). The next person continues the story. Only they have to start their story by saying “Yes, and.” They then continue the story from there for one to four sentences before handing it off to the next person who starts with “Yes, and.”
We have the power to change communication. With a simple substitution we topple even the biggest gorilla in the room.
Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla? Send me an email,
You can follow me on twitter, @JBC_PMP
A Month Passes Addendum: I’ve spent the last month paying attention to the use of “but” around me. I’m absolutely amazed at how common the word has become. In one recent coaching session, my client used “but” two times in a “sentence,” creating a very conflict laden run-on sentence. I was editing some writing and found no less than three “buts” in one short paragraph. The writer had meant it to show how flexible something was, only the end result was to create a series of conflicts of what something could do. Reminded me of the old Ginsu steak knife commercials, “but wait there’s more!” Are you a steak knife or a can opener? Make up your mind!
And I noticed another word, that is insidiously creeping up to supplant “but” while being no less controversial. When someone says “Actually, it’s white, not black” do you have the urge to smile and agree or reach out and smack the offending words from the person’s mouth?
There is enough conflict in the world without adding to it with the use of such ineffective words. So take the pledge with me. “I will actually make an effort not to say but.”