One of the main causes for this team-wide dissatisfaction was our product development process, which at the time looked like this:

The Executive team made new feature requests; PMs helped prioritize these ideas and fleshed these out into requirements. We then sent requirements to the designers, who then cranked out designs. Exec-approved designs then went to the engineering team, who built the feature according to spec and tested it. Once everything was working correctly, we launched it to users. Rinse and repeat.

This approach (let’s call it the Product Development Assembly Line) created a few serious problems.

We all talk about working collaboratively and agile-y, but the process Zhu describes is far more common than we care to admit. The problems with the Assembly Line are mainly personal: the team has reduced visibility and control over decisions (becoming “pixel pushers and code monkeys”), and so lose motivation.

The new process Zhu suggests is not complicated or revolutionary. The challenge is persuading people that this (less obviously efficient) workflow will produce better results.