NOTE: This blog has been moved to

Saturday, September 08, 2012

Three Key Principles to Operating as a LeanUX Team

Coaching teams here at PayPal on what it takes to operate like in a LeanUX manner. I have typically boiled it down to just 3 key principles.

Three Principles

1. Maintain a Shared Understanding at All Times

This was key when I was at Netflix and I see it even stronger now. A lack of a shared understanding means you will have have to lots of documentation. Having documentation that is predictive in an iterative environment is problematic. It is not realistic since you need to be able to change assumptions and solutions early in the cycle. Historical documentation becomes more necessary as teams downstream need them.

A good way to alleviate much of the documentation normally needed is to pull the teams that are normally downstream (like QA, Localization QA, Localization, etc.) and bring them up further in the earlier cycles. Additionally you can create tools earlier in the process that proxy for these teams and reduce the number of those representatives you will need. Tools downstream should be automation driven as much as possible.

In a recent LeanUX project I kept referring to a/b testing. At some point it became apparent that not all the team understood what I meant by a/b testing (remember this is what I ate, drank & slept at Netflix). It was an easy solve to get us a shared understanding, but the mistake was assuming we had one already on all topics.

2. Collaborate, Collaborate, Collaborate

Walls between teams get erected whenever teams get big, become overly specialized and work in isolation. Agreeing to work as a team, trust each other and make collaboration the underpinning of the team's ethos will ensure the walls will come down.

It's not easy. We like to retreat back to the comfort of going solo or dictating to another the way things work. How can you tell where the walls are? It will be at those hand-off points that happen across disciplines. Collaboration is the opposite of this toss it over the wall mindset.

It's ok for teams to take time to work separately or have sessions to reflect. But if you are doing this to avoid working as a team then watch out. Trouble is already at your door.

3. Build/Test/Learn -- or Get to the Customer Early & Often

This is the secret to getting rid of team politics, getting rid of the prima donna, getting rid of analysis paralysis. Getting to the customer in usability tests, research, a/b testing and so on and doing it on a weekly or bi-weekly basis if at all possible keeps the team pure. It is the difference between a stagnant pond or a clear lake fed by streams. User data & user feedback will keep the team focused on the customer and the real goals of the product. 

Believe me this really works. It is astonishing to see how much ownership takes over the team when they sit in all the usability sessions as a team and watch the successes and failures of their work. I have seen the full team time & again go out of a session that didn't go so well with a renewed determination to nail it next time. Customer feedback is the elixer to what ails you (now I just have to mention that all of the standard practices of how to gather this feedback and what to do with it still apply).

It's Pretty Simple

Fragile is often the name given to agile projects that are busted. I have used the term "Lean-Fall" to describe that ugly mix of waterfall & LeanUX. When I talk with teams that are struggling to work in an agile manner it could be a host of issues. There is a lot of machinery from an agile practice standpoint that might need tweaking.

But frankly, over and over I have seen it come down to one or more violations of these three principles. If you don't have shared understanding, collaboration and continuous customer feedback, no amount of scrums, scrum of scrums, agile coaches, etc. is going to make a difference.

View what you are doing as a team in light of these principles and see if it doesn't give you a fresh perspective on acting like a startup.

If you like this article, you might want to check out my Anti-Patterns for LeanUX presentation.


obsurvey said...

I really hope you have success with you usability work. Because every aspect of PayPal seems to have appaulingly bad usability. For example It took me 15 minutes just to cancle some subscriptions, even after reading the help file on how to do it ,it was hard to do because of the very strange menu structure.
Also the entire UI is extreemle slow, to the point of almost being useless.
And don't get me started on the PayPal API and the "documentation" on the API.
I really hopy you have success, seems you have your work cut out for you.

Bill Scott said...

Obsurvey: you nailed it. Thank you for candid, truthful comment.

I have been unabashed in my ranting about our UI being old, tired, uninspiring and frankly just bad on so many levels.

I have the privilege of being part of a new breed of experience but I can say that it is frustrating since you don't turn around an organization as big as paypal in a day.

Sometime in the future when this is accomplishes and the proof is in the pudding I will write up a why did paypal suck article. I have lots of forensics.

We do have some indicators of where we are going. Look at when you are signed out. Or try the new PayPal mobile app. I think you will see a stark contrast.

We are working feverishly on every major part of the experience. Stay tuned!

nothingistrue said...

Great guidance, and largely reflects the steps we are taking to collaboratively morph our Lean-fall design & dev process into healthy LeanUX cycles. Our small dev team is also internationally distributed, so inclusive communication is a constant struggle, but we always work to improve.

By the way, I overlapped with you for a short time during your first stint @ Netflix, for a few weeks before I left for Europe. Thanks for providing great public access to the learnings and evolution of your methodologies.