80% of Teams Don't Involve Engineers in Ideation — Are We Building the Wrong Way?

[product_david]

Atlassian just dropped their first-ever State of Product report, surveying 1,000+ product professionals across the US and Europe. Most of the findings are predictable — 85% say they have a seat at the strategic table, 45% are focused more on profitability metrics than three years ago. Standard stuff.

But one number stopped me cold: 80% of product teams don’t involve engineering during ideation, problem definition, or roadmap creation.

Let me say that differently. Four out of five product teams design what they want to build — the problems worth solving, the solutions worth pursuing, the roadmap worth following — and then hand it to engineering and say “build this.”

I’ve been a PM for 12 years. Google APM program, Airbnb, now VP Product at a Series B startup. And I have to be honest: I’ve been part of this 80% for most of my career. Not because I didn’t value engineering input, but because the incentive structures and workflows I operated in made it the path of least resistance.

When Do Teams Actually Involve Engineers?

The Atlassian data breaks down where engineering enters the picture:

Stage	% of Teams Involving Engineering
Ideation & problem definition	20%
Concept validation	32%
After product discovery	25%
After design finalization	21%

That means 46% of teams don’t bring engineering in until discovery is done or design is finalized. By that point, most critical decisions have already been made. The solution space has been narrowed. The PM has already sold leadership on a direction. The designer has already invested weeks in a UI.

And then the engineer says: “This would take 6 months to build the way you’ve designed it. If you’d asked me 3 weeks ago, I could have told you about an approach that gets you 80% of the value in 2 weeks.”

I’ve had this conversation more times than I’d like to admit.

Why We Exclude Engineers (The Uncomfortable Truth)

I can identify at least four reasons PMs keep engineers out of ideation, and none of them are flattering:

1. Speed anxiety. Ideation sessions with engineers can feel slower because engineers naturally think about constraints, edge cases, and implementation details. PMs want to stay in “possibility space” and worry that engineering input will prematurely narrow it.

2. Authority preservation. The PM-engineering relationship has a fundamental power imbalance — PMs don’t have org chart authority over engineers. Involving engineers in ideation means sharing ownership of the “what” and the “why,” which some PMs perceive as threatening to their role.

3. Workflow mismatch. Engineering teams run in sprints. Product discovery is messy, non-linear, and doesn’t fit neatly into two-week cycles. PMs often feel like they’re “wasting” engineering time by pulling them into open-ended exploration.

4. The Jira waterfall. Despite all the agile rhetoric, most organizations still operate as spec-to-build pipelines. PM writes ticket, designer creates mockup, engineer builds it. The tooling and processes reinforce sequential handoffs even when we claim to be cross-functional.

What Changes When Engineers Are Involved Early

At my current company, we shifted to a “Product Trio” model 8 months ago — PM, Designer, and Tech Lead participate in discovery together from day one. The results:

• 30% fewer “surprise” technical constraints surfacing during sprint planning
• Faster time to first prototype — engineers suggest implementation shortcuts during ideation that designers and PMs would never think of
• Higher engineering engagement — our last engagement survey showed a 22-point improvement in “I understand how my work connects to business outcomes”
• Better solutions — engineers regularly propose approaches that are technically simpler AND better for users, because they understand the actual problem

The Atlassian report actually backs this up: teams with dedicated Product Operations functions show a 19-point advantage in involving engineering from ideation, and a 30-point advantage in feeling empowered to lead strategy.

The Uncomfortable Question for PMs

If 80% of us aren’t involving engineering in ideation, and the data shows that involving them earlier produces better outcomes — why aren’t we changing?

I think the answer is that involving engineers in ideation requires PMs to fundamentally rethink their role. It means admitting we don’t have all the answers. It means sharing ownership. It means being comfortable with “I don’t know how to solve this yet” in front of the people who will eventually build whatever we decide.

That’s scary. It’s also the job.

[alex_dev]

David, I appreciate the self-awareness here. As the engineer who’s been on the receiving end of the “build this” handoff more times than I can count, I want to share what this actually feels like and why it’s not just a collaboration problem — it’s a waste problem.

The Feature Factory Experience

Here’s a typical cycle at my last job:

Week 1: PM presents a fully designed feature in sprint planning. Beautiful Figma mockups, user stories with acceptance criteria, detailed PRD. The team spent 3 weeks in discovery.

Week 1, hour 2: I raise my hand. “This design requires real-time sync across devices. That means WebSockets, a message queue, conflict resolution logic. Have you considered that the same user experience could be achieved with optimistic updates and a 5-second polling interval? It would take a week instead of two months.”

Week 1, hour 3: PM says they’ll “take it back to the team.” This means re-engaging the designer, re-presenting to stakeholders who already approved the original design, and losing a week to re-alignment.

Week 4: We build the simpler version. Everyone agrees it’s the right call. But we lost 4 weeks — 3 in discovery without engineering and 1 in re-alignment — that could have been avoided with a 30-minute conversation in week 1.

This isn’t a one-off. It happens routinely. And the cost isn’t just time. It’s trust erosion. Every time this cycle repeats, engineers become more cynical about the process. We stop engaging thoughtfully during planning because we’ve learned that the decisions are already made. We just execute.

Why Engineers Stop Offering Input

David identified four reasons PMs exclude engineers. Here’s the engineer’s side:

1. We’ve been burned. I’ve spent hours in ideation sessions where my technical input was listened to politely and then completely ignored in the final spec. After enough of those, you learn to save your energy for the implementation.

2. The incentive structure. Engineers are evaluated on shipping, not on ideation. If I spend 3 hours in a discovery session instead of writing code, my sprint velocity goes down. My manager asks why my story point throughput dropped. The system literally punishes me for participating in the product process.

3. “You’re overcomplicating it.” When engineers raise constraints or edge cases during ideation, it’s often perceived as negativity or obstruction. “Don’t think about the how yet, just focus on the what.” But for engineers, the what and the how are inseparable. Telling us to ignore constraints is like telling a financial analyst to ignore costs.

4. Discovery theater. Some PMs invite engineers to “collaborative” sessions that are actually presentations with a Q&A at the end. That’s not collaboration. That’s a briefing with extra steps.

What I Actually Want

I don’t want to attend every brainstorm. I don’t want to do user research (though I should see the results). I don’t want to own the product roadmap.

What I want is embarrassingly simple:

• A 30-minute technical feasibility conversation before any design work starts. Not after mockups. Before. Just: “Here’s the problem we’re trying to solve. What are the technical options and tradeoffs?”
• Access to the ‘why’ behind features. Not the Jira ticket. The actual customer problem. The business goal. The metric we’re trying to move.
• A channel to suggest alternatives that won’t be perceived as “pushing back.” Sometimes there’s a better way to solve the problem that nobody considered because nobody asked the person who understands the system.

The 80% stat doesn’t surprise me. What surprises me is that anyone thinks this is a new insight. Engineers have been saying this for decades. The Atlassian report just put a number on what we already knew.

[eng_director_luis]

Both David and Alex are articulating real problems, but I want to challenge the framing a bit. As a Director of Engineering managing the PM-engineering interface across 6 teams, I’ve seen both sides fail — and the solution isn’t as simple as “involve engineers earlier.”

The Involvement Paradox

Here’s the problem nobody talks about: not all engineers want to be involved in ideation, and not all engineers should be.

When we ran our first “engineers in discovery” experiment, I sent all 42 engineers an open invitation to join product discovery sessions. Know how many showed up consistently? Seven. The other 35 either came once and didn’t return, or never came at all.

Their reasons were telling:

• “I’d rather spend that time coding” (most common)
• “I don’t feel like my input changes anything” (Alex’s point — and they’re often right)
• “I don’t have context on the customer problems to contribute meaningfully”
• “My manager tracks my velocity, not my product contributions”

The 80% stat from Atlassian is about teams, not individuals. And the uncomfortable truth is that even in the 20% of teams that do involve engineering in ideation, it’s usually one engineer — the tech lead — not the whole team.

What Actually Scales: The Tech Lead as Product Partner

After 18 months of experimentation, here’s the model that works for my org:

The Product Trio (PM + Designer + Tech Lead) collaborates on discovery weekly. This is the 20% that Atlassian’s report highlights. But the magic isn’t in the meeting — it’s in what happens after.

The Tech Lead’s job is to:

1. Translate technical constraints into product language — not “we can’t do WebSockets” but “real-time sync adds 8 weeks and requires new infrastructure. Here’s what we could do in 2 weeks instead.”
2. Bring the team’s perspective — they represent 5-7 engineers’ collective knowledge without requiring everyone to attend
3. Identify technical opportunities — sometimes the system has capabilities the PM doesn’t know about. “We already have event streaming for this data. We could build this feature in 3 days, not 3 weeks.”
4. Shield the team from meeting overload — most engineers don’t want more meetings. They want better meetings, attended by the right person.

The Incentive Problem Is Real

Alex called out that engineers are evaluated on shipping, not ideation. This is the structural issue that makes all the collaboration frameworks ring hollow.

At my company, I changed how we evaluate tech leads:

Before:

• Sprint velocity
• Story points delivered
• Bug count

After:

• Features shipped that achieved their business outcome metric (not just shipped — worked)
• Technical feasibility input provided during discovery (measured by PM feedback)
• Number of “better alternative” proposals accepted
• Team satisfaction with product clarity

The result? Tech leads now actively seek out product context because it’s part of how they’re evaluated. They push for earlier involvement because they’re rewarded for it.

But here’s the catch: this only works because I aligned with the VP of Product on it. If engineering leadership changes the incentives without product leadership changing theirs, you get engineers showing up to discovery sessions that PMs don’t want them in. That’s worse than the status quo.

The Real Fix Is Organizational, Not Procedural

You can’t fix a 80% problem with a new meeting format. You fix it by:

1. Aligning incentives — both PMs and engineers are evaluated on outcomes, not outputs
2. Creating the right role — the Tech Lead as product partner, not just technical manager
3. Building trust incrementally — start with one team, show results, let other teams adopt voluntarily
4. Protecting engineer time — involvement doesn’t mean “more meetings for everyone.” It means the right person in the right conversation at the right time.

The Atlassian report highlights the gap. Closing it requires both sides to change.

[data_rachel]

I want to add a dimension that nobody’s addressed yet: we can actually measure the cost of excluding engineers from ideation, and the numbers are damning.

The Rework Tax

I manage an ML engineering team, so I sit at the intersection of product, data science, and engineering. We started tracking a metric 6 months ago that I think every org should measure: rework percentage attributable to late engineering involvement.

Here’s how we calculate it: for every feature that required re-scoping, re-designing, or re-architecting after engineering was brought in, we tag the rework hours and the root cause. The categories:

Root Cause	% of Total Rework	Avg Hours Wasted
Technical infeasibility discovered post-design	34%	42 hrs
Performance constraint not considered in spec	22%	28 hrs
Data availability assumption was wrong	19%	35 hrs
Existing system capability not leveraged	15%	18 hrs
Security/compliance constraint missed	10%	31 hrs

Every single one of these categories would have been caught by a technical feasibility review before design started. Not a long meeting. Not a formal process. Just someone who understands the system looking at the problem statement and saying “here’s what you need to know.”

For our team of 14 engineers, the rework attributable to late involvement costs roughly 380 engineer-hours per quarter. That’s 2.4 FTE-months. Per quarter. Essentially, we’re paying for 2 extra engineers who do nothing but redo work that should have been scoped correctly the first time.

The ML-Specific Version of This Problem

In ML engineering, the gap between product ideation and technical reality is even wider than in traditional software. Here’s why:

A PM comes to us with: “We want personalized recommendations on the dashboard.”

What they imagine: A magic box that shows relevant items.

What it actually requires:

• 3-6 months of data collection before the model has enough signal
• Feature engineering pipeline that may need new data sources
• Model training infrastructure (GPU costs, experimentation pipeline)
• A/B testing framework for recommendation quality
• Monitoring for model drift, bias, and performance degradation
• Fallback logic for cold-start users

If we’re brought in after the PM has already promised “personalized recommendations in Q2” to stakeholders, we have two options: disappoint everyone by explaining the timeline is Q4, or build something mediocre that technically counts as “recommendations” but delivers no real value.

Both outcomes are worse than a 30-minute conversation 3 months earlier.

The Atlassian Report Is Missing the Measurement

The report says 80% of teams don’t involve engineers in ideation. What it doesn’t quantify is the cost of that exclusion. I’d argue that’s the more important number.

If the rework cost at our organization (~380 hrs/quarter for 14 engineers) is representative, then for a 200-engineer company, you’re looking at roughly 5,400 hours of rework per quarter — about $2.7M annually at a $200/hr fully loaded rate — directly attributable to excluding engineering from ideation.

That’s not a collaboration problem. That’s a line item.

What Changed When We Fixed It

After we started sharing the rework data with product leadership, two things happened:

1. Product stopped arguing about whether engineers should be in ideation. The data was undeniable. 380 hours of waste per quarter is not a philosophical debate.
2. Engineers got selective about which discovery they join. Not every ideation session needs an engineer. The ones that involve new data sources, new infrastructure, or ML capabilities? Non-negotiable. A UI copy change? The PM can handle that solo.

The key was turning a values argument (“collaboration is important”) into a business argument (“we’re wasting $2.7M annually on preventable rework”). Values are debatable. Waste is not.