Killing the Product Development Assembly Line

The Before

Several years ago, at one of the previous places where I worked, we had major issues with product designer turnover and engineer engagement. Even though the company paid generously and had a good reputation, our software engineers would sit in sprint planning meetings, saying little and bolting out the door as soon as the meeting ended. New designers lost interest within a matter of months, and were usually gone before the year was up. 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:

• Churn and delays during design and implementation: Because we didn’t loop in Engineering and Design together from the beginning of the project, we wandered far down paths that were too technically challenging to implement. For example, designers would spend weeks building pixel-perfect Invision prototypes, complete with animations and hover states, only to discover that their solution required a refactoring of the entire underlying data model. When that happened, we had to go back to the drawing board in order to come up with a more feasible solution, wasting precious time and slowing down the overall project.
• Total lack of investment in the features we worked on: With the assembly line approach, team members had no impact on the preceding step in the process. Designers had limited input on the requirements, and engineers had little say on either the requirements or the designs. Almost nobody (including PMs) bothered to contribute new feature ideas because we had little faith they’d make it into the roadmap. We treated our team members like pixel pushers and code monkeys, and unsurprisingly, they ended up not caring about the product.
• Uninformed feature suggestions: Without contributions from designers and engineers to the product roadmap, we often ended up working on the wrong set of features. At the time, our feature suggestions came largely from our Executive team as opposed to the people who spent the most time with our product and our users. Ensuing problems included delaying critical tech debt issues until our backend was on the verge of falling over, and failing to take user testing feedback into account when prioritizing features.
• Stunted professional development and personal growth: For many engineers and designers, progressing along their respective career tracks means participating more deeply in the product development process. For a senior engineer, this may include advocating for tech-driven initiatives like speeding up performance, while senior designers might want to emphasize recurring themes from user interviews. From this perspective, the Product Assembly Line does all team members a disservice; when everyone is just supposed to keep their heads down and stay in their lane, no one gets the experience they need to advance in their careers.

The After

Luckily, we eventually came to the realization that our product development approach was broken, and we overhauled it completely. Instead of ideas moving linearly from one functional role to the next, we adopted a much more collaborative approach. Let’s call this process the Product Development Loop.

Cross-functional squads

The foundation of the Product Development Loop is the the Cross-functional Squad, which consists of a product manager, engineers, designers, and even business stakeholders (depending on the circumstances). Squads have an overarching goal that may vary from quarter to quarter — an example goal may be to increase monthly active users by 15%. All squad members play an active role in coming up with ideas for how to hit those goals, prioritizing what to work on first, and executing on high-impact ideas. (Best practices on this topic will be the subject of an entire standalone post, soon to come.)

Feature Development Loops

The process diagram for the Product Development Loop looks way more complicated than the Assembly Line, but it’s actually fairly simple. Basically, it just involves circling back with the cross-functional squad and checking after every major step in the process. In practice, the steps break down as follows:

• Project Kickoffs: Begin each project with a group discussion around the user problems you’re trying to solve and aligning on a high-level approach.
• Product Briefs & PRDs: PMs then flesh out more detailed user stories and requirements based off the approach, and then check in again with the squad.
• Wireframes, User Testing, & Technical Designs: From there, design and engineering work in parallel — designers build low-fidelity wireframes and conduct usability tests (if applicable), while engineers write a technical design document and solicit feedback from peers.
• Alignment: Cross-functional squad reviews wireframes, asks questions, and confirms that they satisfy the requirements without presenting a major technical challenge.
• High-Fidelity Designs & Implementation: Designers turn the wireframes into high-fidelity designs and present them in a developer-friendly format (think Invision Inspect or Zeplin), while engineers break down the technical design into discrete tasks and start working on the backend and preliminary frontend. Once high fidelity designs are complete, engineers can finish with styling and polish, collaborating closely with design to reduce iteration and churn.
• Pre-Launch Checks: Business stakeholders receive an end-to-end walkthrough of the feature, especially if their team has to use it post-launch (think a CMS or other internal tool). The cross-functional squad thoroughly dogfoods the feature, and everyone signs off on launch.
• Post-Launch Analysis: PMs work with data teams to make sure that reporting is in place and conducts analysis (both qualitative and quantitative) X days post-launch to measure impact.
• Debrief & Reflect: PM shares findings on impact with the rest of the squad and the team reflects on what areas of the feature are working well, and what areas can be improved.

While this approach may not work for every team — some product teams may not have any designers, for instance — the general process and philosophy hold true for most organizations. At its core, the Product Development Loop seeks to give everyone on the team a seat at the table and a chance to make their voice heard.

Epilogue

A few months after we introduced the new process, employee turnover decreased and we noticed ourselves wasting less time on preventable churn in our work. In addition, we received a lot of great feedback from the team that they felt more ownership over the product as a whole.

However, the Product Development Loop is not a perfect solution. There will always be times where an assumption turned out to be incorrect after we started working on a feature that required us to go back and change things. But as a whole, teams are a lot more forgiving of mistakes when they feel like they’re appreciated and doing meaningful work. And ultimately as a PM, you’re only as effective as your team, so the more you can empower them and make them feel invested in the outcome, the more successful you will be.

Killing the Product Development Assembly Line was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.