Concept review
A concept review is a structured meeting where a team presents early-stage product ideas to stakeholders for evaluation and feedback. The concept might be a new product, a major feature, or a significant change to existing functionality. The review happens before substantial development investment, when the cost of changing direction is low and input can meaningfully shape the outcome.
Why it matters
Building the wrong thing is expensive. Engineering time spent on features that miss the mark, designs that don't resonate, or products that fail to find market fit represents wasted investment. Concept reviews matter because they expose potential problems early, when they're cheap to address.
Beyond catching problems, concept reviews:
Align stakeholders. Different parts of the organization may have different assumptions about what's being built. Reviews surface and resolve these differences.
Gather diverse perspectives. Engineering sees technical risks. Sales sees market fit issues. Support sees usability concerns. Reviews bring these perspectives together.
Create shared ownership. Stakeholders who participate in shaping a concept feel more invested in its success.
Document decisions. Reviews create a record of what was decided and why, useful when questions arise later.
What to present
Effective concept reviews share enough to enable meaningful feedback without requiring excessive preparation:
The problem. What customer need or business opportunity does this address? Why does it matter?
The proposed solution. How does the concept address the problem? This might include wireframes, mockups, user flows, or written descriptions.
Target users. Who is this for? What do we know about their needs and context?
Key assumptions. What must be true for this concept to succeed? What are we uncertain about?
Trade-offs and alternatives. What other approaches were considered? Why was this one chosen?
Open questions. Where do you need input? What decisions are yet to be made?
The detail level should match the stage. Early concepts might present rough sketches; more developed concepts might show detailed wireframes.
Who should attend
Include stakeholders with relevant perspectives:
Product. The concept owner and other product managers who might be affected or have relevant experience.
Engineering. Technical leads who can assess feasibility, identify risks, and estimate scope.
Design. Designers who will create the user experience and can spot UX issues.
Business stakeholders. Sales, marketing, support, or others who understand customer needs and market dynamics.
Leadership. When concepts involve significant investment or strategic implications.
Keep the group small enough for meaningful discussion - typically 5-10 people. Large groups produce shallow feedback.
Running the review
Set expectations. Clarify what stage the concept is at and what kind of feedback is useful. Early concepts need directional feedback; refined concepts need detailed critique.
Present, then discuss. Allow the presenter to explain the concept before opening for questions. Interruptions derail narrative flow.
Encourage questions. Questions often surface assumptions and misunderstandings. Create space for them.
Capture feedback systematically. Designate someone to document feedback, concerns, and decisions.
Distinguish feedback types. Separate "this is wrong" from "have you considered" from "I prefer." Not all feedback carries equal weight.
Reach conclusions. End with clear outcomes - proceed, iterate, pivot, or stop. Ambiguous endings waste the review's value.
Effective feedback
Good concept review feedback is:
Specific. "This feels complex" is less useful than "Users might not understand what 'sync status' means."
Grounded. Feedback connected to user research, data, or experience carries more weight than pure opinion.
Constructive. Identifying problems is valuable; suggesting alternatives is more valuable.
Prioritized. Distinguish critical concerns from minor suggestions. Not everything needs addressing.
Respectful. The concept represents someone's work. Critique the work, not the person.
Concept review vs. design review
Both are review meetings, but they differ in timing and focus:
Concept review happens earlier, when ideas are still forming. The question is whether to pursue the direction at all.
Design review happens later, when the concept is accepted and detailed design is underway. The question is whether the design effectively implements the concept.
Concept reviews focus on "what" and "why"; design reviews focus more on "how."
Common problems
Too late. Reviews that happen after significant investment is already made can't easily change direction.
Too vague. Concepts presented without enough detail produce only vague feedback.
Wrong audience. Missing key stakeholders means missing important perspectives. Including too many dilutes discussion.
Defensive presenters. Presenters who defend rather than listen miss the review's value.
No follow-up. Feedback that's collected but not acted on makes future reviews feel pointless.
Scope creep. Reviews that try to solve detailed issues better addressed elsewhere lose focus.
After the review
Concept reviews should produce actionable outcomes:
Clear decision. Proceed, iterate, pivot, or stop - know which.
Documented feedback. Capture what was said so it informs next steps.
Assigned actions. Who will address which concerns? By when?
Communication. Share outcomes with stakeholders who need to know.
Tools like Klero support concept reviews by bringing customer feedback into concept development. When concepts are informed by actual customer needs, reviews can evaluate how well concepts address those needs.
