A Model for Managing Multi-Partner Collaboration - or: why we put our partners ahead of our customers.

I've been thinking about this topic for some time, so I'll apologize in advance for a long-ish post.

Many projects that I have worked on, and the one I'm currently working on, have the problem of multiple partners having input into a single system. This is not uncommon and, in fact, it seems that in the days of SaaS (software as a service), it's ubiquitous. Heaps of articles and management books deal with this common problem so I won't waste time recapping all those things. Instead I'll try to attack the problem from a less common point of view.

The main problem with multi-partner collaboration is that the customer's interest gets lost in the shuffle. It's true that everyone believes they have the customer's goals in mind (or at least, they should otherwise you have even worse problems) but how often do we see companies delivering features and products that no one really wanted? Is this because "the competition is stupid?" No. It's because our intuition leads us to incorrect conclusions and then our entrenchment in our position becomes more powerful than our interest in our customers.

Let's assume you have multiple inputs into a single system (a), (b), (c) and (d). Each of those represent an analysis of user behavior and then an interpretation of user value. Those can manifest in a "feature list" that is distinct for each one of those inputs. Let's say that each partner discovers 3 high value user features based on their interpretation. So you end up with:
(a) 3 features
(b) 3 features
(c) 3 features
(d) 3 features

So now you have 12 feature requests all coming from the desire of each parter's users.

Your job as the project manager is to figure out how to prioritize those features across all partners in such a way that each partner is satisfied and still keeping the development pipeline running smooth.

Let's say, for the sake of simplicity, that all these features have equal value and that your development pipeline can maintain 4 features per release (release time is relative, but let's say 4 weeks). So you now have 3 months of feature development. How do you prioritize?

In THEORY you would value all 12 features based on maximum user value and make sure those get done first, but that violates a critical reality of partner behavior. If you do that and it turns out that (a)'s features are ALL important while (d)'s features are unimportant, you now have to weight the partner relationship value against the user value. In other words, user value and partner value are in conflict. Now any good manager out there is going to call foul on that. Of course we wouldn't sacrifice user value for partner satisfaction! Or would we?

Well, we would never do that explicitly, but we would hold long meeting to determine the value of the 12 features during which partners would jocky for their features and try to squeeze in as many of theirs as they could. The reason? They know the development pipeline is lean and they know that if they don't get their features in now, they may never get them in. Worse, the person who is representing their features may be "scored" at their own organization based on their ability to drive the priority of their features. Few people would assume that their 3 features could be LESS important than someone else's list. Of course they are important! We know our customers better than anyone! We must be right! Or are we?

Let's assume that each featureneed 3 hours of estimation and 1 hour of discussion for prioritization. Total cost of estimation and prioritization is 36 hours + 12 hours, so 48 hours of work to evaluate the complexity and prioritize those features. Those hours create a lot of commitment to individual partner's positions. It's very hard to change course when you've spent hours and hours discussing and planning things. So after these 48 hours where are we?

We've got a plan for the next 3 months of features. We've prioritized the tasks for what we believe is user value (although there's probably a lot of partner satisfaction trumping user value going on, but we don't measure that well, do we?). We've got "sign-off" on priority from all interested parties. We've got good estimates from our developers. We've got a green light. Everyone is aligned, right? But what about the customer? Is she aligned? Did she "sign off?" Does she have a "green light?" How do we know?

This is pretty fail in my opinion. Why? Because the true user value is buried under several layers of management decision making. How can we be sure we're really working on the right thing? We've focused on partner satisfaction, estimation and prioritization - scoring "points" instead of building value.

Why did we do this?

Exposure.

Our partners are "in the room" with us - or in the virtual room. They are pressing their position, they are challenging our assumptions, they are asking questions about what is possible and why. They are shaping our decisions and our world on a minute by minute basis while our customers are patiently waiting for their increase in value. In effect, the more partners we have representing our users and the bigger and more complex our project becomes, the more likely the customer's value is to get lost! Our customers don't have the same exposure to us. It's much easier for us to disappoint our customers than it is to disappoint our partners, and we created a system to ensure this is so. This is all backwards.

It's like one of those reality TV dating shows. In the context of the contest, the participants will kill themselves and each other to be with the person. Then, once the cameras go out, and the competitors are defeated, that dream date doesn't look so good anymore. We want to win so badly we forget the value of the actual prize. This behavior goes all the way up to hot-shot managers on multi-million dollar projects.

I can see the post-mortem now:
"Bob. Why on earth did you spend all that time fighting for that feature that no one wants?"
"Well, it seemed really important at the time."

Oops!

 

 

Our model for collaboration must force us and our partners to put our customer's experience at the center. There's a lot of ways to do this:

1. Force all feature requests to tie back to measurable user value.
2. Estimate value based on total development cost in relationship to user value (instead of difficulty and partner value).
3. Force parters to weigh their own and each other's requests based on measurable user value.
4. Directly ask your customers which of ALL features they value the most - and then force all partners to work together and prioritize.

That's all well and good - and I'm sure you can come up with more, but that's not the point.

The point of all of this is to remind partners that they and we must protect each other from losing sight of customer value. Our natural inclination will be to satisfy each other and to win points for our respective organizations. It's everyone's job in management to build systems that optimize around customer value: how to measure it, how to protect it and how to increase it. I think that's one of the major reasons small companies disrupt big ones. Less people and less layers between developer and customer lead to greater development efficiency - not in terms of time per feature, but in terms of time per unit of customer value. Small companies don't have time or money to spend on "professional research" or "marketing analysis" (both extremely useful, btw) and instead have to rely on their customers directly. This direct dialog is, itself, of huge value and makes it hard for them to ignore their customers. Also, small companies have fewer resources so if they ignore customer value, they go to the graveyard very quickly and don't survive to write award winning books on management strategy.

I would force partners to be customers. Force your partners to use your software IN the planning and strategy meeting. Force everyone to see what is good and what is bad. Grab the "top list" of "important features" and make sure they pass this test. It's AMAZING how frequently really important things suddenly are reduced to piles of trivia and incredibly high value customer facing features are ignored. Is that new billing interface REALLY more important than the annoyance of having to scroll to find the submit button? Maybe to the guy trying to make his sales numbers, but not to the guy submitting the form... Who is more important?

So... in all your important strategy and planning meetings, please don't forget about the customer value... and, more importantly, don't forget how easy it is to forget about the value. Ask your partners to help remind you. When in doubt, grab all the partners, sit down and use the software for a while or, better yet, watch someone else use it. Then have that prioritization meeting...