Skip to main content
The feed
STRATEGY2024.12.036 min read

Why We Stopped Selling Hours and Started Selling Outcomes

Eighteen months ago we stopped billing by the hour. Uncomfortable, risky, and one of our best decisions. What we learned about aligning consulting incentives.

Hamad Pervaiz
Hamad Pervaiz
Founder & CEO, BearPlex
Share

Eighteen months ago, we made a decision that felt risky at the time: we stopped selling hours.

No more timesheets. No more billing increments. No more conversations where clients ask why a task took 12 hours instead of 8.

Instead, we started selling outcomes. Defined deliverables with fixed prices. Success metrics with our compensation tied to hitting them. Risk shared between us and our clients.

It was uncomfortable. It required us to get much better at scoping and estimation. It meant sometimes eating costs when we underestimated complexity.

It was also one of the best decisions we've made as a company.

The Problem With Hours

Hourly billing is the default model in consulting for a reason: it's simple. You track time, multiply by rate, send invoice. The client knows what they're paying for. The consultant knows they'll get paid for work done.

But simplicity isn't the same as alignment.

Here's the uncomfortable truth about hourly billing: the consultant's financial incentive is for the project to take longer. Not deliberately padding hours (most consultants are honest), but there's no structural pressure toward efficiency. If a task takes 20 hours, you bill 20 hours. If you find a clever way to do it in 5 hours, you've just reduced your revenue by 75%.

Clients feel this tension even when they can't articulate it. That's why they ask about hours. That's why they want detailed time breakdowns. They're trying to answer the question: "Am I getting value, or am I paying for inefficiency?"

The question itself reveals the problem. In a well-structured engagement, the client shouldn't need to audit your timesheets to know they're getting value.

The Outcome-Based Alternative

Outcome-based pricing flips the model. Instead of selling time, you sell results.

The conversation changes from "We estimate this will take 400 hours at $200/hour" to "We will deliver X, and it will cost $Y."

X is defined clearly. Success criteria are explicit. The client knows exactly what they're getting and what they're paying. We know exactly what we need to deliver and what we'll earn.

If we find a way to deliver the outcome faster, we keep the margin. If we underestimate and it takes longer, we absorb the cost. The incentives align: we're motivated to be efficient without sacrificing quality, because quality is what defines the outcome.

How We Structure Engagements

Moving to outcome-based pricing required us to completely rethink how we scope and structure work. Here's the model we've evolved to:

Phase 0: Discovery (Fixed Price)

Every engagement starts with a paid discovery phase. Usually 1-2 weeks, fixed price. The deliverable is a detailed specification: what we're building, how we'll know it's successful, what the risks are, what it will cost.

This protects both parties. The client gets a thorough analysis before committing to a large project. We get enough information to price accurately.

Phase 1+: Outcome Milestones

The main engagement is structured as a series of outcome milestones. Each milestone has:

  • Clear deliverable: What artifact or capability will exist
  • Success criteria: Objective measures of completion
  • Fixed price: What the milestone costs
  • Timeline: Expected completion window

Payment is tied to milestone completion, not time elapsed. If we deliver early, great. If we need to iterate to meet the success criteria, that's on us.

The Risk Pool

Here's where it gets interesting. On larger engagements, we structure a "risk pool": a portion of the total project value (typically 15-25%) that's tied to overall project success, not just milestone completion.

If the project achieves its high-level business objectives (the metrics the client actually cares about), we earn the full risk pool. If it falls short, we don't.

This means we have skin in the game beyond just delivering features. We care whether the thing we built actually works in the real world.

Real Examples

Let me share two engagements that illustrate how this works in practice.

Example 1: Document Processing System

A legal services firm needed to automate processing of court filings. Under hourly billing, this might have been scoped as "estimated 600-800 hours of development."

Instead, we scoped it as outcomes:

  • Milestone 1: System processes standard filing types with 95%+ accuracy ($X)
  • Milestone 2: System handles edge cases, accuracy reaches 99%+ ($Y)
  • Milestone 3: Full integration with existing case management system ($Z)
  • Risk pool: 20% of total, paid if system processes 10,000+ documents in first 90 days post-launch

We delivered all milestones, earned the risk pool. Total project cost was actually lower than the hourly estimate would have been, but our effective rate was higher because we were efficient. Win-win.

Example 2: AI Assistant Platform

A client wanted an AI assistant for their customer service team. We structured it as:

  • Milestone 1: Assistant handles top 10 query types with <5% escalation rate ($X)
  • Milestone 2: Coverage expands to top 25 query types, same escalation threshold ($Y)
  • Milestone 3: Assistant handles 80% of all queries with <10% escalation ($Z)
  • Risk pool: Tied to measured reduction in average handle time

Milestone 3 was harder than expected. We spent more time than estimated. But we delivered, and the client got exactly what they needed. Under hourly billing, this would have been a difficult conversation about cost overruns. Under outcome pricing, it was simply us doing what we committed to do.

Aligning Incentives Changes Everything

The shift to outcome-based pricing changed more than our invoicing. It changed how we think about projects.

We invest more in upfront discovery because accurate scoping directly impacts our economics. We're more thoughtful about architecture decisions because we'll live with the maintenance burden. We push back on scope creep because the scope is what we're being paid to deliver.

Most importantly, our conversations with clients are different. We're not defending time logs. We're collaborating on outcomes. When something changes mid-project (and something always changes), the discussion is about adjusting milestones and pricing, not about who's at fault for the extra hours.

Advice for Firms Considering This Model

If you're running a consulting firm and considering outcome-based pricing, here's what we've learned:

Start with strong clients. Your first outcome-based engagements should be with clients who trust you and have realistic expectations. Don't try to convert a difficult client relationship to this model.

Invest in discovery. Your ability to price outcomes depends on your ability to understand scope. Paid discovery isn't overhead: it's the foundation of accurate pricing.

Build in buffers, especially early. Until you've calibrated your estimation, price with healthy margins. You'll get better at scoping over time.

Be explicit about what's included. Scope creep kills outcome-based projects. Define boundaries clearly, and have a process for handling change requests.

Track your data. After every project, compare actual effort to estimates. You need this feedback loop to improve.

Accept that you'll lose some. Some projects will cost more than you estimated. If you never lose money on a project, you're probably overpricing. The goal is to win in aggregate, not on every engagement.

The Bigger Picture

Outcome-based pricing isn't just a billing model. It's a philosophy about how consulting should work.

Clients hire consultants because they want results, not activity. The clearer we can be about what results we're delivering (and the more we tie our compensation to those results), the more honest the relationship becomes.

We're not perfect at this. We're still learning, still refining the model. But we're never going back to selling hours.

Because at the end of the day, nobody cares how many hours something took. They care whether it worked.

Filed under strategy · 2024.12.03
Share
From reading to building

If this maps to a decision you are making, talk to us.

The systems described in the feed are the systems we ship. The first conversation is with an engineer, not an account manager.