Why Innovation Teams Shouldn't Start With a Clear Problem

By Clara

Last updated April 29, 2026

Research on 579 teams shows starting with an unclear problem can outperform a defined brief. Learn the two-phase model and how to use it.

Every innovation workshop seems to begin with the same command: define the problem first.

It sounds disciplined. It sounds efficient. It also appears to be wrong more often than most innovation leaders want to admit.

According to the content brief built from Johnathan R. Cromwell and Jean-Francois Harvey’s Spring 2026 MIT Sloan Management Review research, teams that began with an unclear problem and clarified it over time succeeded about 80% of the time, compared with about 50% for teams that started with a well-defined problem. That is a sharp challenge to a rule many facilitators treat as nonnegotiable.

The lesson is not that clarity is bad. The lesson is that early clarity is often fake clarity. Teams lock onto a framing before they have earned it, then spend the rest of the project getting better answers to the wrong question.

This guide explains the pattern, why premature problem lock-in backfires, and how to run a better two-phase innovation process instead.

What Team Problem Discovery Actually Is

Team problem discovery is the process in which an innovation team starts with a broad, ambiguous challenge and works toward a sharper problem definition during the project, rather than treating the problem statement as fixed at the start. The problem itself becomes a deliverable of the first half of the work.

That is different from standard design thinking process, where teams usually try to define the problem early and then move into ideation. It is also different from solution-first behavior, where a team quietly starts with a preferred answer and uses the project to justify it.

In practice, team problem discovery asks a harder question than “How do we solve this?” It asks, “What is actually worth solving here?”

That sounds subtle, but it changes the whole rhythm of innovation work. It creates more room for contradictory evidence, competing hypotheses, and reframing. It also demands more tolerance for ambiguity than many organizations are comfortable with.

Why Problem-First Framing Backfires

When a team begins with a crisp problem statement, it usually optimizes for that frame even when the frame is weak. The definition starts acting like a boundary. Ideas that support it feel relevant. Ideas that challenge it start looking off-topic.

This is why so many “well-run” innovation workshops produce such predictable outputs. The brief may look neutral, but often it already contains a preferred solution, a political compromise, or a narrow symptom masquerading as the core problem. The team becomes efficient inside a box it did not choose.

Three traps show up repeatedly.

First, the problem is often a solution in disguise. “We need an app for this.” “We need better onboarding emails.” “We need an innovation lab.” Those are not problem statements. They are preselected answers.

Second, early alignment suppresses useful disagreement. Teams interpret alignment as professionalism, so they stop challenging the frame before they have explored whether it deserves commitment. In cross-functional work, that usually means the loudest or most senior framing wins by default, not the best one.

Third, premature definition narrows observation. Once the brief says the issue is feature adoption, the team may stop asking whether the real issue is poor positioning, low customer trust, weak onboarding incentives, or a mismatch between product and job-to-be-done. That is how teams miss the deeper opportunity hiding behind the visible complaint.

This is why creative problem-solving starts with problem finding, not only problem solving. If the framing is shallow, strong execution just gets you to the shallow answer faster.

The Two-Phase Model: Messy First, Sharp Second

Cromwell and Harvey’s research points to a pattern that is more useful than the generic advice to “stay open-minded.” High-performing innovation teams appear to follow a two-phase model.

Phase 1: Open Exploration

In the first phase, the team works with an ambiguous challenge space. The goal is not to finalize the brief. The goal is to test interpretations of the brief.

That means the work can feel inefficient from the outside. Teams debate. They pivot. They gather signals that do not yet connect cleanly. They compare several possible problem statements at once. They may even look disorganized to leaders who expect quick convergence.

But that messiness is functional. It increases the odds that the team notices hidden assumptions before those assumptions harden into a plan. It makes room for consumer insights, customer needs, technical constraints, and business-model realities to reshape the problem itself.

The key discipline in this phase is not endless brainstorming. It is structured exploration. Teams still need hypotheses, interviews, observation, lightweight experiments, and explicit reframing checkpoints. They just should not confuse early activity with earned certainty.

Phase 2: Convergence

Around the midpoint, the team needs to become decisive. This is where many organizations fail in the opposite direction: they stay vague too long and turn ambiguity into drift.

The second phase requires a real commitment. The team should be able to say: this is the problem we now believe matters most, this is the evidence that led us here, and these are the solution paths we will pursue or reject.

At that point, the work starts looking more familiar. You narrow options. You prioritize. You run ideation against a stronger frame. You validate assumptions through rapid experimentation and idea validation. You stop treating the problem as open terrain and start treating it as a selected bet.

The midpoint matters because it separates productive mess from unproductive confusion. If a team is still arguing about the core problem late in the project, the process has not stayed open-minded. It has failed to converge.

Three Named Examples of the Pattern

1. Pixar’s Story Development

Pixar is a useful example because its films do not start as fully solved narratives. They begin as rough concepts that go through repeated reframing. The team is not just refining scenes. It is discovering what story it is actually trying to tell.

That resembles team problem discovery. The project starts with energy but not full clarity. Through critique, iteration, and intense debate, the team sharpens the real creative problem before it commits to final execution. The quality does not come from perfect upfront definition. It comes from earning definition through exploration.

2. Amazon’s Working-Backwards Method

Amazon’s working-backwards process is often described as a planning tool. It is more useful to think of it as a controlled problem-discovery tool.

When a team writes a future press release and FAQ, it is forced to test what the real customer value is, what objections exist, and whether the supposed problem is meaningful enough to justify a launch. The exercise looks like documentation, but its real value is exposing weak assumptions before build work starts.

In other words, the team is not beginning with a frozen problem statement. It is using a structured artifact to discover whether the original framing survives contact with the customer story.

3. The Standard Corporate Innovation Brief

Now consider a common failure case. A company launches an innovation challenge framed as “reduce returns in category X.” Teams respond with better instructions, better packaging, and a few workflow tweaks. All reasonable. All incremental.

But the brief may have prevented the more valuable question: is the real issue product fit, channel expectation-setting, sales promises, or the wrong customer segment? A clear brief created fast alignment around a narrow symptom. The team delivered competent answers to a mediocre question.

That is the danger. A well-defined brief can produce well-defined mediocrity.

Five Things Innovation Leaders Should Do Differently

1. Start with a challenge space, not a fixed problem statement. Frame the opening brief as a tension, outcome, or opportunity area. “How might we reduce onboarding friction?” is more useful than “build a better tutorial flow.”
2. Create a hard midpoint commitment. Decide in advance when the exploration phase ends. By that point, the team must choose the problem it will solve and explain why.
3. Protect dissent early. In the first phase, someone should have explicit permission to challenge the framing. That is especially important in cross-functional teams, where false alignment can arrive quickly.
4. Score the problem statement, not only the solution concept. Reward teams for discovering a more valuable problem, even when that means abandoning the original brief.
5. Use customer evidence to sharpen the frame. Pull in customer development interviews, observed friction, and behavioral signals early enough that they can change direction, not merely decorate the final recommendation.

What a Good Innovation Problem Statement Looks Like

A good innovation problem statement is not broad forever, and it is not narrow too soon. It starts open enough to allow discovery, then becomes specific enough to guide action.

By the end of the first phase, a strong problem statement usually has four qualities:

• It names a meaningful user, team, or business constraint.
• It is grounded in evidence, not only opinion.
• It leaves room for multiple solution paths.
• It is specific enough to make tradeoffs visible.

That is also why teams should treat reframing as normal. If the best evidence points somewhere else, changing the problem statement is not a failure. It is progress. In many cases, a thoughtful pivot is the real sign the team learned something.

FAQ

What is team problem discovery in innovation?

Team problem discovery is the process of starting with an ambiguous challenge and clarifying the real problem over time. Instead of assuming the brief is already correct, the team treats problem definition as a core part of the innovation work.

Why do clearly defined innovation briefs often produce weaker ideas?

Because they narrow attention too early. Teams become efficient inside the initial frame, even when that frame reflects politics, habit, or a symptom instead of the deeper issue. Stronger ideas usually come from challenging the frame before committing to it.

How long should the exploration phase last?

There is no universal percentage, but the process should include a visible midpoint where the team commits to a sharper problem statement. The point is not to stay vague; it is to give exploration enough time to improve the quality of convergence.

Does this mean design thinking is wrong?

No. It means many teams interpret design thinking too rigidly. Good discovery work already includes reframing, ambiguity, and iteration. The mistake is acting as if the first agreed problem statement must also be the final one.

Closing: Problem Clarity Is a Goal, Not a Starting Ritual

Innovation leaders are right to want clarity. They are wrong when they demand it before the work has earned it.

The best teams do not stay messy forever. They stay messy long enough to discover what they are actually solving, then they become sharply disciplined about execution. That is the real pattern behind better innovation problem framing: ambiguity first, commitment second.

If your last workshop felt productive but produced obvious answers, the issue may not have been weak ideation. It may have been premature certainty.

Explore related concepts:

• Design thinking process
• Tolerance for ambiguity
• Creative problem-solving
• Customer development
• Rapid experimentation
• Pivot

Contributor

Clara @cla_reinholt

Focuses on innovation communication, facilitation, and turning frameworks into team habits.

Clara writes about the human systems behind innovation: facilitation quality, communication clarity, and the routines that help teams move from ideas to decisions. She follows practical team-method sources such as the Atlassian Team Playbook, alongside innovation coverage from McKinsey and Harvard Business Review.

Her contributions often combine editorial storytelling with practical templates that leaders can reuse for team rituals, retrospectives, and portfolio reviews, informed by research and practices from McKinsey on Innovation, Harvard Business Review, and the Atlassian Team Playbook.

Clara tends to ask one recurring question in her drafts: Will this help someone lead a better conversation tomorrow? If the answer is yes, the piece is ready.