Opinion: Why you need to get rid of the ‘developer handoff’ in your product life cycle

Photo credit: Matthew Henry.

One of my biggest gripes with the modern product life cycle is the forced compartmentalization of specializations.

If I was hired for design, that should not mean that I’m a design god who can magically turn every business objective into a successful feature on my own. My domain expertise may center around design, but I also have eight years of experience doing product marketing and writing. I also “code,” though I wouldn’t remotely call myself a developer. I’ve also done sales, business development, and support.

My point: Most techies have a diverse set of experiences and skills that can add value to multiple specializations, not just their core competency.

The developer handoff

The same goes for developers. They are not just implementers of ideas; they are the originators and catalysts of these.

The most wasteful product life cycles simply give “handoffs” to development—design, business, and product do all the research and feature design, while the engineering team just implements them.

This initial handoff typically has three purposes:

• Specs: Devs are tasked with arranging the specs and conducting a feasibility assessment for the proposed designs.
• Timelines: Devs must spec a timeline for product building, testing, and deployment that meshes with the business’ goals.
• Implementation: Devs must build and implement the designs.

Consequences of the handoff

The handoff may seem like an efficient, linear step in the product life cycle. But the modern product life cycle is not a linear process. It’s circular, iterative, and dynamic. So, what are the human implications of this handoff?

When they are not involved in the design process, devs can feel:

• Disconnected from the rest of the team and from the ideation phase
• Unappreciated because programming is hard and good programming is harder, yet they had little input in the overall product scope
• Uninspired because they aren’t able to harness their product and life experiences to creatively solve problems from a feature perspective
• Burned out because of having little control over what they implement and having to implement feature sets that they do not truly believe in

Developers as designers

Instead of the handoff, we should be incorporating devs in the entire design process—from ideation, sketching, prototyping, to implementation. This doesn’t mean that we should force devs to storyboard concepts and conduct extensive user research. We just have to give them a seat at the table.

The design-minded developer brings the following:

• Functional perspective: What functional frameworks do we have available? What unique tools can we harness? What toolkits do we have to work with?
• Constraint framing: What technical constraints does the project have from a systemic perspective? Can we really handle the implementation of an advanced animation for our millions of users? How will certain things possibly impact system performance?
• User perspective: Devs are people too and represent a unique segment of the population, so use their perspectives and ideas to inform how the product is delivered.
• Great ideas: Devs have transformative ideas. They are extremely intelligent and creative problem solvers (that’s their job, after all).
• Bluntness: This is one of my favorites. Devs tend not to sugarcoat feedback and tend to challenge ideas upfront. They demand that you explain the “why” and “how” of an idea and don’t just give superficial feedback. This bluntness helps drive creative conversation, not hinder it.

Overall benefits