Aza Raskin on Cooperation Throwing Things Over the Fence

In today’s post, Aza Raskin tackles a reader’s question about Product Management, cooperations with other groups, throwing stuff over the fence, why large teams generally suck, and political in-fighting and politics.

I work as a product manager for a technology company in the valley.  In large companies like mine, the department of Product Management, Software Engineering, and Customer Experience work together, but in a clunky way, to build a product.  What is the best way, in your opinion, to infuse the Humane Design Principles in a hot political environment?

For example, the classic problems of: product will define a feature based on market research and define the personas.  Engineering feels like we define something and “throw it over the fence” to them to develop.  At the same time, Customer Experience is bothered that Product Management didn’t involve them, etc.

Be sure to read our other interviews in our leadership series.

My question is turning out to be more of a human resources question than about design, but wanted your thoughts.

Maybe you should start an “Ask Aza” column, like a Dr. Phil segment, or something.

Successfully bringing a product to market is a holistic endeavor.  User requirements drives customer experience; customer experience drives marketing; marketing drives user requirements.  Nobody should feel that a set of requirements has been “thrown over the fence”.  When this happens, the recipient-of-the-throw is beholden to an abstract deliverable and is no longer connected to the end-user.  That’s a real problem.  Combating this requires a tight-feedback loop which is most easily created with a small team: engineering gets to see the market research come in, and the usability people can guide engineering throughout the actual creation process.

In an ideal world, everyone on the team would have a foot in engineering, design, and marketing.  Unfortunately, this isn’t always possible.  What is possible is that we can create small, tight teams that collectively have intimate knowledge of all three disciplines.

The small-team idea is by no means new.  In the book In Search of Excellence, Tom Peters explains over-and-over again that it’s the small groups; skunk works, home-brew projects, and strike teams that drive innovation at companies both large and small.  The most successful teams are those of 10 people or less — preferably between 4 and 8 — that include people from the required disciplines.

By keeping teams small, products don’t get commitee-ized.  The team is directly responsible for success.  Success is dependent on making a product that meets the needs of the user and to the user, the interface is the product.

P.S.,  I like the idea of an “Ask Aza” column: Anything that’s alliterative must be good!

Aza’s point above about team size is important, and one that I’ve discussed before.  Quantitatively, we can show why, in general, large teams aren’t the best way to go.  Here is what I wrote back in Ocotober 15, 2006:

Other articles in the “Ask Aza Raskin” Series:

1. Aza Raskin discusses the infinite scroll approach to Google search results.
2. Aza Raskin shares his thoughts on Feature Bloat (aka, Featuritis)
3. Aza Raskin describes the concept of Quasimodal Design.
4. Aza Raskin explains the role of Poka Yoke in the User Experience