Elizabeth Holmes learned it with Theranos. Billy McFarland learned it with the Fyre Festival.
You can’t put toothpaste back into the tube.
Once you’ve gotten people excited about the next big thing, you better be able to deliver.
Now, imagine being Holmes’ scientists or the organizing team for McFarland’s Fyre Festival - “You told them we could do what?!”, it’s an impossible spot to be in.
A process that accounts for expectation setting - and brings the right team into the planning process at the right time - can be the difference between a successful product launch or a flop (or jailtime!).
There are two extremes to product development.
On one end, you have the Theranos/Fyre Festival model where product visionaries design the entire output with almost zero outside input. Then they hand off their plans to the team and expect perfect delivery.
On the other end, you have the bureaucracy model. Everyone’s priority and opinion is heard from the beginning so you end up with…(checks notes)...nothing fast.
If you want realistic and impactful product development, you need to take a blended approach. Here’s how we see it.
There are four connected phases that require varying degrees of technical involvement.
Discovery:
Discovery is about defining scope and should be led by the product and design teams. This phase is about understanding user needs and what is being solutioned for. The focus here shouldn’t be on what will be built, but on the key user flows that need to be accounted for. Engineers involved should be prepared to play a passive role at this point, only gathering context to benefit future stages where they have greater involvement - while understanding that decisions here are being written in pencil, not pen.
Wireframe:
The wireframe phase is where the “how” starts to take shape. This is still led by product and design in the form of low-fidelity wireframes. It’s also where technical involvement begins to increase. Product is still setting direction, but engineers should be looped in to assess technical feasibility and effort. That’s especially important before stakeholder meetings. It’s key that product, design, and engineering are aligned before stakeholders see what’s being created. The limited involvement here isn’t about gatekeeping. It’s about being conscious of everyone’s time and focus.
Design & Prototype:
This is where engineers and developers should be at peak collaboration. The design team should be trying to excite users and the technical team should be making sure a first look is setting the right expectations for both stakeholders and end-users. You don’t want to show them a Rolls Royce when you know you can only build a Toyota given their time and budget. This is essentially the “application blueprint” that the development team will use to estimate the time and resources needed to build the solution.
Development:
Here’s where the engineering team takes over. In an ideal situation, all parties - product, design, development, and stakeholders - have a shared vision and expectation for the output. That allows for optimal heads down work and progress. That doesn’t mean collaboration ends, however, you still need regular check-ins and demos with stakeholders to ensure progress is meeting expectations.
Culture Plays a Key Role
Trusting your team to make decisions that are going to impact your work can be challenging. But having strong processes in place - like great retros - helps to build that rapport and trust.
There’s no one size fits all process for design and development collaboration, that depends on your organization. The one thing that is almost always true, however, is to make sure your team - including the stakeholder - has a shared vision. It’s the upfront work of communicating, prioritizing, and making the right technical choices that create the best end products. Also, if you liked this article please subscribe to our newsletter