You Promised Them What?! Balancing Vision and Feasibility in Product Development

Product Insights

Pete Whiting
#
Min Read
Published On
March 13, 2025
Updated On
February 5, 2026
You Promised Them What?! Balancing Vision and Feasibility in Product Development

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

Author headshot
Written by
Pete Whiting
Head of Growth and Client Service
, The Gnar Company

Pete Whiting is the Head of Growth and Client Service at The Gnar Company, where he leads business development, marketing, and client service activities to help companies build high-quality custom software. With over a decade of experience at the firm, Pete specializes in driving revenue growth and ensuring high utilization of development teams through strategic go-to-market and product marketing initiatives.

Prior to joining The Gnar Company, Pete held executive roles in operations and marketing at firms such as Dispatch and MeYou Health. He also spent five years at Vistaprint, where he served as Director of Product Marketing and Strategy for the Asia Pacific region, accelerating annual revenue and gross profit growth through data-driven planning and multi-channel marketing. Pete’s career began in engineering and management consulting, including seven years at Deloitte Consulting leading growth strategy and post-merger integration for global industrial and high-tech clients. He holds an MBA with honors from UCLA Anderson and both a Master’s and Bachelor’s degree in Materials Science and Engineering from Brown University.

Related Insights

See All Articles
Engineering Insights
Anthropic Dropped OpenClaw Support. Here's How I Replaced It With Claude Code.

Anthropic Dropped OpenClaw Support. Here's How I Replaced It With Claude Code.

Anthropic's TOS change killed OpenClaw overnight, taking businesses built on the ecosystem with it. But for end users, Claude Code's new channels feature offers a viable path forward.
Product Insights
We Turned a Phone Call Into a Working Product in 48 Hours. Here's Exactly How.

We Turned a Phone Call Into a Working Product in 48 Hours. Here's Exactly How.

Watch what happens when a one-hour phone call becomes a working application in 48 hours. We walk through exactly how Context-Driven Development turns a single conversation into a competitor analysis, feature prioritization, full PRD, and production-grade software with Stripe billing, user accounts, and an admin dashboard—using AI-assisted agentic development with a human architect in the loop.
News
Is Your Team Ready for AI? Here's How to Find Out in 2 Minutes

Is Your Team Ready for AI? Here's How to Find Out in 2 Minutes

Most teams aren't getting real value from AI tools — not because the tools don't work, but because their foundations aren't ready. Discover the five factors that predict AI success and take a free 2-minute assessment to find out where your team stands.
Previous
Next
See All Articles