SaaS Economics Blog

    Quality vs Quantity when Defining Business Metrics

    by Brad Coffey

    At HubSpot we've recently started a series of projects aimed at defining some new metrics for running our business.  We do this because (admittedly) we are dorks and love data - but also because we need to solve some real problems in the organization.  These problems generally range from aligning incentives, evaluating project success, or managing day-to-day operational flow.  In each of these cases, however, a common challenge emerges centered around finding the right balance quality and quantity.

    Below I have identified a series of touch points between organizations where this has been particularly interesting for HubSPot. As you'll see we've tried a couple different approaches to identifying the right balance.  Nothing is ever perfect - but I think there are some take-aways here for others, 

    Marketing and Sales: Sales 'Points' SLA

    • Balance Need: Volume and Fit
    • Tendency: Simply count leads because its simpler
    • Solution: Score each conversion event (not simply lead) and hold Marketing accountable for a sum of those points

    Sales and Customer Team: LTV base compensation

    • Balance Need: New Customer Velocity and Retention
    • Tendency: Compensate only for new units
    • Solution: Measure sales reps by Total Lifetime Value generated each period - not just new units.  For SaaS this strongly influenced by a sales rep individual churn rate

    Onboarding Consultants and Account Managers: Customer Happiness at handoff

    • Balance Need: Pace of Consulting and Success of Consulting
    • Tendency: Don't measure anything because its hard
    • Solution: Determine 'customers happiness' objectively (frequency of use, features set-up, survey results) and hold consultants to a onboarding schedule

    Product/Engineering & Customer Team (specifically services): Daily Pain

    • Balance Need: New Innovation and Fixing Existing Innovation
    • Tendency: Allot some % of time to bugs and hope it works
    • Solution: Score open bugs by severity and hold engineering to a cap - and allow time for new development while below that limit

    In each of these cases we have tried to understand the underlying motivations that lead to imbalances and identify objective metrics that when monitored regularly can keep us from tipping too far in either direction.

    So what do you think?  How have we done?
    Brad Coffey

    Written by Brad Coffey

    Recent Posts