Customer discovery and pricing strategy for early-stage startups

At a glance

What this is: This is a founder-focused discussion of pricing strategy, with the key finding that pricing should be built from day one and refined through continuous customer discovery.

Why it matters: It matters to IAM practitioners because the same value, packaging, and iteration discipline increasingly shapes how security capabilities, NHI controls, and identity services are adopted, priced, and governed.

By the numbers:

• 40% of founders are looking to test new pricing models in 2024.
• 1,500 executives, founders, and leaders were surveyed across payments, finance, engineering, and product teams.

👉 Read Cerbos' discussion on pricing strategy and customer discovery

Context

Pricing is not just a commercial decision. It is a governance choice that shapes product adoption, customer expectations, and the speed at which a startup can learn what its market will tolerate. In security and identity programmes, the same pattern shows up when teams try to package controls around value instead of around internal convenience.

For early-stage teams, the challenge is that pricing, packaging, and customer discovery evolve together. If the value proposition is still changing, static pricing usually becomes a guess rather than a signal. That is why pricing strategy belongs in the same conversation as product design, especially when the offer is technical, usage-sensitive, or likely to expand over time.

The article's core point is that teams should expect pricing to change as they learn. That is typical for startups operating before product-market fit, and it is exactly why rigid assumptions about value, usage, and willingness to pay tend to fail.

Key questions

Q: How should startups use customer discovery to shape pricing?

A: Start by asking buyers what outcome they value, what problem they need solved, and what metric would fairly represent that value. Then test whether their answers support a simple pricing model that is easy to explain, forecast, and defend. Discovery should inform packaging, not just product direction, because willingness to pay is a market signal, not a guess.

Q: Why do simple pricing models often work better early on?

A: Simple pricing reduces confusion while teams are still learning which customer segment, outcome, or usage pattern matters most. It also makes it easier to test assumptions without creating noise in sales conversations or procurement. The goal is not permanent simplicity, but a model that can survive scrutiny while the product and market are still evolving.

Q: When should a startup change its pricing model?

A: A pricing model should change when the product starts serving different buyer segments, when the value metric no longer reflects customer usage, or when integrations and features materially change what customers buy. If the product has shifted but the pricing logic has not, the business is likely carrying hidden friction that slows adoption and distorts value.

Q: What is the difference between pricing for usage and pricing for value?

A: Usage pricing charges for measurable consumption, while value pricing tries to align cost with the outcome the customer receives. They often overlap, but they are not the same. A usage metric can be easy to measure without reflecting value, so teams should choose the model that best matches how customers experience the benefit.

Technical breakdown

Customer discovery as a pricing signal

Customer discovery is the process of learning what a buyer values, what problem they will pay to solve, and which outcome matters most. In the article, discovery is treated as more than validation of pain. It also needs to surface willingness to pay, buying triggers, and the value metric that best matches customer perception. For software businesses, that usually means testing whether the unit of value is users, usage, seats, workflows, or outcomes. The mistake is stopping after enthusiasm. Real pricing discovery asks how that enthusiasm converts into a budget decision.

Practical implication: treat discovery interviews as pricing input, not just product feedback.

Usage-based pricing and billable metrics

Usage-based pricing ties cost to a measurable activity, such as volume, transactions, or consumption. The article highlights why this feels attractive to founders: the buyer sees a direct link between value received and money spent. But the technical challenge is selecting a billable metric that scales with value without creating gaming, unpredictability, or misalignment. In practice, the metric has to be simple enough for customers to understand and stable enough for finance teams to forecast. If the metric is weak, the model creates friction instead of trust.

Practical implication: choose a billable metric that reflects value and can be explained without a sales script.

Pricing iteration through product maturity

Pricing is not a one-time decision because product capability, market understanding, and customer segments evolve together. The discussion makes clear that many startups begin with flat-rate pricing, then move toward more nuanced packaging as the product matures. This is especially true when features become more differentiated, integrations matter more, or different customer groups value different parts of the offer. The deeper point is that pricing should be reviewed with the same discipline as roadmap decisions. If the product changes, the pricing architecture should change too.

Practical implication: schedule regular pricing reviews whenever the product, buyer, or distribution model shifts.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Pricing strategy is an identity governance problem when the product mediates access, not just revenue. The article shows that founders are really deciding how value is observed, measured, and exchanged over time. In identity and security businesses, that same logic applies to how controls are bundled, metered, and adopted by different buyer groups. The practitioner lesson is that commercial design and governance design are often the same conversation in different language.

Customer discovery is the only reliable way to avoid pricing assumptions that age badly. The article's strongest signal is not the specific models discussed, but the discipline of asking what buyers value before locking in a tariff structure. That matters in NHI and IAM programmes because the wrong packaging often hides the real adoption barrier. The practitioner conclusion is to treat willingness to pay as a live governance signal, not a one-off sales question.

Simple pricing is not simplistic pricing. The article's emphasis on clarity, iteration, and alignment with value points to a broader market truth: complexity is often a substitute for product understanding. When offerings sit in crowded security categories, buyers punish confusing models and reward those that map cleanly to business outcomes. The practitioner implication is to design pricing that can survive procurement scrutiny, not just initial enthusiasm.

Value-based packaging is more durable than feature-based packaging. The conversation repeatedly returns to customer outcome, not product inventory. That is a useful pattern for identity and security teams because it forces a shift away from counting features and toward linking commercial structure to operational value. The practitioner conclusion is that pricing should reflect how a buyer experiences control, not how a vendor organises capability.

Founders who think about pricing early are usually thinking more clearly about market fit. The article makes early pricing awareness sound obvious, but the subtext is that many teams delay the hard question of what the offer is worth. That delay creates downstream confusion in positioning, packaging, and customer segmentation. The practitioner conclusion is that pricing maturity should be assessed alongside product maturity, because the two are tightly coupled.

From our research:

• 67% of founders admit to guessing their pricing, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Pricing governance and secrets governance both depend on whether teams can translate intent into repeatable practice, as shown in Ultimate Guide to NHIs , Why NHI Security Matters Now.

What this signals

Customer discovery functions like control discovery in identity programmes. Teams that cannot explain what value they are selling usually cannot explain what control they are enforcing, and that ambiguity shows up later in adoption, billing, and governance drift. The practical lesson is to treat pricing logic as part of the operating model, not as a commercial afterthought.

For identity and security teams, the broader signal is that buyers increasingly expect clear value mapping, not broad claims. That means packaging, entitlement design, and adoption metrics will need to line up more tightly with business outcomes. The same pressure is visible across NHI and IAM programmes where control sprawl makes it harder to show what is actually being bought and used.

For practitioners

• Run pricing discovery alongside product discovery Ask buyers what outcome they value, what they would pay to solve it, and which metric best reflects that value. Capture those answers before you lock in tiers or contracts.
• Test one clear pricing metric at a time Use a simple model first, then measure whether the chosen unit such as seats, usage, or workflows matches how customers perceive value. Avoid adding complexity until the metric proves reliable.
• Review pricing whenever the product changes materially Revisit packaging after major feature changes, segment expansion, or shifts in customer behaviour. A pricing model that matched an earlier version of the product can become a source of friction later.
• Validate willingness to pay before expanding tiers Use discovery calls and pilot feedback to learn where buyers feel value and where they hesitate. That helps prevent tier sprawl and keeps pricing understandable for both buyers and finance teams.

Key takeaways

• Pricing is a learning loop, not a launch decision, and teams that ignore that loop end up guessing at value.
• Customer discovery should inform both what you sell and how you charge, because willingness to pay is part of market fit.
• Simple pricing that maps cleanly to customer value is easier to operate, easier to explain, and easier to revise as the product matures.

Key terms

• Customer Discovery: Customer discovery is the process of learning what buyers value, what problem they are trying to solve, and what they will pay to fix it. In practice, it connects interviews, pricing tests, and product feedback so teams can validate demand before they harden a commercial model.
• Usage-Based Pricing: Usage-based pricing charges customers according to how much they consume, such as volume, activity, or transactions. It works best when the billable metric closely reflects value delivered and when the model remains easy for buyers, finance teams, and operators to understand.
• Value Metric: A value metric is the unit a business uses to connect price to customer-perceived benefit, such as users, workflows, or usage. Good value metrics are understandable, stable enough to forecast, and tightly linked to the outcome the buyer thinks they are purchasing.

Deepen your knowledge

Pricing strategy for early-stage software belongs in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is packaging security capabilities for adoption and growth, the same governance mindset is worth exploring.

This post draws on content published by Cerbos: customer discovery and pricing strategy for startups. Read the original.