I recently needed to validate a new B2B subscription tier for a product my team was building. We had a hypothesis: create a mid-tier between our existing Starter and Pro plans aimed at small teams that need collaboration features but not enterprise-level integrations. We wanted a fast, low-cost way to validate price sensitivity and perceived value using only 30 customer calls — and without introducing survey bias that would invalidate our findings. Below I share the exact approach I used, the questions that worked, what to avoid, and how to turn qualitative calls into quantitative signals you can act on.

Why 30 calls — and why phone/video interviews, not surveys

Thirty customer conversations is a pragmatic balance: small enough to be fast and affordable, large enough to find patterns and rule out weird outliers. Calls (phone or video) let you probe, clarify, and observe tone and hesitation — things a form can't capture. The key challenge is to keep calls structured and comparable while avoiding leading language that anchors respondents. If you do them right, 30 calls will tell you whether a new tier is plausibly priced and what messaging or feature tweaks are needed.

Recruiting the right participants

Recruitment matters more than clever questions. I split recruits into three groups to reflect the segment the tier targets:

  • Current Starter customers (10 calls): those who might upgrade.
  • Starter customers who churned in the last 12 months or downgraded (10 calls): to capture friction points.
  • Prospects or trial users who evaluated but didn't purchase (10 calls): to test price sensitivity from the “not-yet” viewpoint.

    • Keep company size, role (product manager, ops, founder), and ARR bucket balanced. Use CRM filters, support tags, and in-app events to find people. Offer a modest incentive (e.g., £50 Amazon voucher or a month free on any plan) — it improves show rates without biasing answers.

    Interview framing — what to say and what not to say

    How you frame the call determines whether you introduce bias. I used this opener: “I’m doing product research to understand how teams like yours solve X and whether a new plan would be useful. This is a research call — I’m not selling anything.” That last sentence sets expectations and reduces sales pressure, which can alter willingness to say “no.”

    What to avoid:

  • Avoid any mention of specific price points before you ask price-related questions.
  • Don't introduce features and then immediately ask willingness to pay — first understand current workflows and pain.
  • Never ask leading questions: replace “How valuable is feature X?” with “Tell me about the last time you needed X.”

    • Call structure and timing

    Each call lasted 25–30 minutes and followed a rigid template so answers could be compared later. I recorded calls (with permission) and took live notes using a shared Google Doc. Here’s the structure I used:

    SegmentTimeGoal
    Intro & consent1–2 minSet expectations, ask permission to record
    Context & current workflow8–10 minUnderstand real problems and tool usage
    Feature & value exploration8–10 minExplore perceived value without price anchors
    Price sensitivity & hypothetical trade-offs6–7 minGet quantitative signals on willingness to pay
    Wrap-up1 minAny final thoughts, thank you

    Questions that avoid bias and reveal real value

    Here are the question patterns I used — phrased conversationally and open-ended. You can copy these directly.

  • “Walk me through the last time your team needed to do [the task the tier aims to solve]. What did you do?”
  • “What were the biggest challenges or friction points in that process?”
  • “How are you solving those today? What tools do you use?”
  • “If you could wave a magic wand and change one thing about your current solution, what would that be?”
  • “If a tool could save your team X hours per week, how would that change things for you?”
  • “We’re thinking about a mid-tier product that includes [list features without prices]. Based on what I’ve described, how likely would you be to consider switching/adding that product?” (Scale: Very unlikely — Very likely)
  • “If you had to pick between feature A and feature B for the same price, which would you choose and why?”
  • Price probe (non-anchoring): “If a product solved the problems we discussed, how would you think about the price? Would it feel cheap, fair, or expensive?”
  • Gabor-style probe adapted for calls: “For a product that delivers what we described, would £X per month feel too cheap / fair / too expensive?” — BUT only after establishing use-case. Also vary X across interviewees to avoid anchoring.

    • How to ask price questions without anchoring

    Anchoring is the main threat to valid price signals. I used a randomized micro-experiment within the 30 calls:

  • Divide calls into three price-exposure groups (A/B/C). Each group hears a different candidate price when you finally use numerical probes (e.g., £20, £40, £80).
  • Before any number appears, collect qualitative value statements. Then introduce the number and ask the same reaction scale (too cheap / just right / too expensive).
  • Make sure each interviewee only hears one price to avoid cross-contamination if they talk to each other later.

    • This lets you map perceived value across price points without priming everyone on a single anchor.

    Turning qualitative answers into quantitative signals

    After each call I coded responses in a simple spreadsheet with these fields:

  • Segment (Starter / Churn / Prospect)
  • Primary pain (category)
  • Interest level (1–5)
  • Perceived value (low/medium/high)
  • Price reaction (too cheap / right / too expensive)
  • Notable quotes

    • Once all 30 calls are coded, I calculated simple metrics:

  • Percent “likely to buy” by segment
  • Percent who rated price as “right” at each exposed price
  • Common feature trade-offs

    • These metrics give you a fast decision rule. For example, if ≥50% of Starter customers say the price is “right” at £40 and ≥30% say they’d likely upgrade, the tier is worth piloting. If nearly all call participants say “too expensive” at £80, you need to lower price or add more value.

    Common pitfalls and how I avoided them

    From this exercise I learned what breaks tests fast:

  • Talking about competitor prices too early — we only discussed competitors when the participant brought them up.
  • Leading with features instead of problems — I always led with the customer's workflow and pain.
  • Mixing price exposure within a single interview — never show multiple price points to the same participant.
  • Ignoring “deal-breaker” signals — if multiple participants say a specific missing integration prevents adoption, fix messaging or consider bundling that integration.

    • What to do next with the results

    After you analyze the coded data, you have three practical paths:

  • Pilot the tier with a small cohort at the price that scored “right” most often and monitor conversion rates.
  • Adjust the feature set and messaging based on recurring objections and re-test with another 15–20 calls.
  • Use price sensitivity signals to build a simple pricing experiment in your checkout (A/B test two prices with a limited rollout) to validate in-market behavior.

    • In my case, the interviews revealed clear price elasticity and one overlooked feature request that we could add cheaply. We piloted a 50-customer rollout at the lower mid price, used targeted messaging addressing the explicit pain points voiced in calls, and saw a 3x conversion uplift versus the previous messaging.

    If you want, I can share the exact script I used as a template you can copy, plus a simple spreadsheet for coding answers so your team can run the 30-call validation in a week. Just tell me whether you want the script for video calls or phone calls (we slightly adjust phrasing for tone and visual cues).