Skip to article
Strategy

How to compare customer segments in a product strategy interview

8 min read · Updated 2026-10-27

Practice strategy answers Read the guide Free to start · AI feedback
8 min read strategic judgment guide

Work through a scheduling-app case: compare customer needs, product fit and economics, then defend a conditional segment choice.

PMMockr visual guide for How to compare customer segments in a product strategy interview PMMockr.com

Define the decision before comparing segments

A customer segmentation answer should explain which group to serve first, what need makes it distinct and why the product can serve it. Clarify the objective and constraints before selecting a segment or filling in a scoring framework. Segment size alone does not establish demand, willingness to pay or an efficient route to customers.

This guide uses an original AI-assisted scheduling-app case published by PMMockr. It is hypothetical practice, not an employer question, customer study or investment forecast. We do not claim measured market sizes, conversion rates or user outcomes.

The case: choose a first segment for a scheduling product

Illustrative prompt: a small team building appointment scheduling software can support one new workflow before its next product review. Which customer segment should it prioritize?

Assume the goal is sustainable recurring use of the scheduling workflow with an implementation the team can support. The product can manage basic appointments, reminders and access permissions. It does not yet support regulated-record workflows, complex multi-location administration or bespoke integrations. Those are constraints of the invented case, not statements about a named commercial product.

Ask who uses the calendar, who chooses the software, who pays and whose information it handles. A useful segment definition includes a task and operating context, rather than treating everyone of one age or job title as having the same need.

Compare needs rather than demographic labels

Segment A: independent tutors arranging repeat lessons directly with learners. Investigate recurring schedules, cancellations, access and whether existing calendar tools already solve the problem. Do not assume a customer is an adult or that a new product may process learner information without appropriate requirements.

Segment B: small repair businesses coordinating appointments between a dispatcher and field staff. Investigate travel, reassignment, job duration and how an appointment becomes a completed visit. Multiple participants and operational dependencies can create both value and implementation work.

Segment C: multi-location service organizations coordinating staff availability and centralized reporting. Investigate administration, integrations, permissions and procurement. A larger contract does not mean the current team can deliver the needed workflow.

These segments describe proposed research groups. They may overlap in reality. Define an assignment rule for the analysis and a way to record overlap rather than counting the same account multiple times.

Use the same comparison criteria for every segment

Compare the evidence on each criterion and mark unknowns explicitly. A precise score based on unsupported weights is less useful than a clear explanation of the uncertainty.

Make a conditional recommendation

Under the stated constraint that the team can support a basic recurring workflow, I would investigate independent tutors first. The hypothesis is that repeat scheduling can fit the existing product with less coordination work than dispatch or multi-location administration. This is a product-fit hypothesis, not proof of a larger market or stronger willingness to pay.

Compare the strongest alternative directly. A repair business may have a more costly scheduling failure and a clearer paying decision maker, but the value may depend on dispatch features the team cannot yet deliver. If a small repair workflow works without that expansion, it could become the better first segment.

I would not build the complete tutor workflow merely because the initial fit seems convenient. First check whether current calendars already meet the need and whether any unmet problem is valuable enough to justify switching. If they do, reject the hypothesis and reassess the alternative.

Estimate impact without claiming a conversion lift

If asked to quantify potential impact, define the population, denominator and observation window before inserting numbers. For a conversion-led scenario, incremental paid accounts equal eligible free accounts multiplied by the difference between treatment and comparison conversion rates. A higher trial-to-paid rate is not automatically causal without a valid comparison.

An absolute difference between rates is a percentage-point change. A relative percentage change divides that difference by the original rate. Name which measure you mean. Do not assume the same lift across segments simply to make the arithmetic convenient.

To compare contribution, account for retention, realized revenue, acquisition, onboarding, support and variable operating cost over a consistent period. Multiplying new accounts by an annual list price is not realized incremental revenue: accounts may join at different times, receive discounts or leave. Label a scenario as a scenario and show which inputs are unknown. Do not turn missing values into zero.

A useful sensitivity check asks what change in a decision-driving input would make the alternative preferable. Recalculate the entire comparison when that input changes rather than saying a modest price increase closes an unsupported gap.

Choose the next check that could reverse the decision

For the tutor hypothesis, speak with appropriately recruited, consenting participants about their current scheduling work and switching barriers. Observe a prototype task where appropriate, using synthetic appointment information instead of collecting unnecessary learner details. Include people who use a satisfactory alternative, not only those interested in the new tool.

Check the payer, buying process and willingness to commit through an appropriate pilot. Interest in an interview is not a subscription, and initial setup is not sustained use. Define successful repeated scheduling, cancellations, unresolved bookings, support burden and the data-handling requirements before the pilot.

A pilot establishes evidence about participants and the conditions tested. If you need to attribute a conversion or retention change to the product, discuss an appropriate comparison, assignment unit, sample and duration with the analyst. Do not generalize a small convenience sample to the entire segment.

Follow-up: tutors are satisfied with their existing calendars

Interviewer follow-up: research indicates that the tutor workflow is already well served, but repair dispatchers report costly missed handoffs. What changes?

I would stop treating the tutor segment as the lead opportunity. Investigate the repair workflow and distinguish a basic appointment coordination problem from a dispatch-system requirement. Check whether the current product can solve the important part, who will pay, and whether travel, permissions and integration work make it infeasible within the constraint.

If a narrow repair workflow is valuable and supportable, recommend a bounded pilot there. If it requires capabilities the team cannot responsibly deliver, revise the scope or defer entry. The new evidence changes the priority; it does not remove the delivery constraint.

Weak answer, stronger answer and practice checklist

Weak answer: “Choose the largest demographic group and assume the same conversion increase for everyone.” It treats reach, response and delivery cost as known and ignores existing alternatives.

Stronger answer: “Compare a recurring self-managed workflow with a coordinated operational workflow using the same need, reach, fit and economic criteria. Under the basic-product constraint, investigate the tutor hypothesis first. If current calendars solve that need, reassess a narrow repair workflow before building.”

Practice with a new constraint

Practice prompt: choose an initial segment for a language-learning product. Define the learning task and buying context before choosing groups. Compare the strongest alternative, name the largest uncertainty and propose the next check.

Then add a constraint: the team has no capacity to onboard organizations. Explain which segments become less feasible and whether the original recommendation survives. Use the public strategy collection for another prompt, then compare your reasoning with a worked answer before choosing a timed case.

FAQ

How should I handle missing segment sizes or conversion rates?

Mark them as unknown and identify the evidence needed. Explain a conditional scenario or sensitivity check if useful, with a consistent population and period. Do not claim invented numbers are research findings or assume every segment responds equally.

Should I always choose the largest customer segment?

No. Compare need, reachable demand, current alternatives, product fit, sustained value, delivery cost and uncertainty. A smaller supportable segment may be a better first choice; explain what evidence makes that trade-off worthwhile.

What is the difference between percentage change and percentage-point change?

A percentage-point change is the subtraction of two rates. A relative percentage change divides that difference by the original rate. State the denominator, observation window and which measure you use before comparing segment outcomes.

What if research contradicts my recommended segment?

Explain which assumption failed, compare the alternatives again and update the recommendation. Preserve delivery and data-handling requirements rather than treating new demand evidence as permission to ignore them.

Related guides