The 4 Laws of Software Economics

Speaker: Rich Mironov (@RichMironov)

I. Your development team will never be big enough

Development can never build as fast as we can dream.

You are never:

  • one developer away
  • one release away
  • one feature away

Magical Thinking

If I say the right thing, you’ll do it for me.

  • “It’s really important”
  • “We already promised it to a big prospect”
  • “We’ve been talking about this for months”
  • “How hard could it be? Probably only 10 lines of code”
  • “My neighbor’s kid could do this in an hour”

This is magical thinking because it comes from an “and” point-of-view: do everything you are doing AND this one more thing.

Development works from an “exclusive or” point-of-view. To do feature A, you have to not do feature B. You don’t have huge amount of idle development resources that you can just apply to the new feature.

Law #1: Ruthless Prioritization

  • Endless stream of AND requests, but EXCLUSIVE OR decisions
  • We succeed by finishing a few critical things
    • The more things you add to the queue, the less productive your team becomes

Executive’s Job:

  • Make hard trade-offs (the easy ones have already been delegated)
  • Battle magical thinking and one-offs

II. All of the profits are in the nth copy

Development process is a fixed cost. Goal is to find identical or near identical customers so we can sell the same software more than once.

Revenue Implications

  • Assume development team of 6, this will roughly cost you $1M/year
  • Implied revenue commitment….
    • 12-18% of revenue for large companies is spent on R&D
    • Or about $1 in every $6 building product
      • $3 for sales & marketing
      • $1 for general & administration
      • $1 for profit or distributions
  • Thus your company should be generating at least 6x the cost of development team in revenue
  • Each new developer should help you generate $1M new revenue per year
  • Incremental cost per user is ideally $0
  • Goal for development is not to minimize costs, but to maximize revenue

If you’re doing a SaaS product, your pricing should be divided into 3 software tiers/bundles (Basic, Expanded, Advanced):

  • Makes it easier for customers to buy
  • Ties into basic buying psychology
  • Helps focus your development team so you can avoid doing custom packages / features for specific customers.

Key to this is getting the right Major Feature that causes people to upgrade from Basic to Expanded.

There’s nothing more wasteful than brilliantly engineering a product that doesn’t sell. Product Managers help you find where the money will be in the market.

Law #2: Build Once, Sell Many

  • Segmentation: Strategic art of choosing customers who want the same solution

Executive’s Job

  • Focus on segments, not deals
  • Prevent one-off features

If you survey salespeople, the top reason they’ll claim they had an awesome last quarter is that they are an awesome salesforce. Conversely, the top two reasons they’ll claim they had a bad quarter is that a) the product sucks and b) the price is too high. Obviously this isn’t true.

We pay sales people on individual performance. We pay salespeople to undermine the product plan. Salespeople are all about getting one-off features to close the next sale. It’s the product manager’s job to hold back the tide and stop this. Consider changing incentives to avoid one-off requests.

III. The Software Bits Are Not the Product

Software bits are not the whole product. A whole product requires:

  • Deep customer understanding
  • Positioning, messaging, awareness
  • Sales & channels
  • Support, evangelism

Commercial Software Failure Modes:

In his experience, the ranked order items are:

  1. Wrong problem, wrong solution
  2. Marketing / channel / sales failures
  3. Undifferentiated or poorly positioned
  4. Late delivery
  5. Poor quality

Only the last two are engineering failures; the rest are whole product failures (sales, marketing, strategy).

Most of the success/failure of a product is determined before we pick our first developer or fill out our first story card.

Law #3: Whole Products

  • Customers buy solutions (often includes software)
  • Mean-Time-To-Joy

Executive’s Job

  • Watch for organizational silos
  • Make sure incentives are aligned
    • Are we paying people for output, or customer success and joy?

IV. You can’t outsource your strategy

Input sources:

  • Voice of the custoer
  • Surveys
  • Crowdsource feature ranking
  • Competitor data sheets
  • Smartest customers
  • Smartest developers
  • Executive Survey-of-One

Input sources are great input into decisions, but you need to be making your own decisions, not delegating to the input.

Kano Model

Surveys customers on new features products by asking:

  • Fulfillment: Did this feature/product meet your needs?
  • Satisfaction: Did this feature/product make you feel satistified?

Features can be divided into three types:

  • Baseline: Every product has these. They meet your needs, but doesn’t make customers satisfied.
  • Performance: Those that you are always aiming to increase over time (CPU speed, memory, disk space, etc).
  • Excitement: Those most of your customers don’t know they want that leave them satisfied and fulfilled. Also known as “delighters” or “exciters”.

Don’t delegate your strategy to analytics:

  • Estimating business value is harder than estimating engineering time.
  • When you do bottom-up prioritization, you get ugly products.
  • Biased trade-offs occur between unlike things

Instead, do prioritization within buckets:

  • New Features – 50% of developer time
  • Infrastructure – 10% of developer time
  • New Research – 20% of developer time
  • Bug Fixes – 20% of developer time

That way you’re not doing trade-offs between unlike things.

Law #4: Judgement

Strategy requires judgement:

  • “I skate to where the pick is going to be, not to where it has been.” – Wayne Gretzsky
  • As a product manager, you must have a point of view and a vision of where we’re going; otherwise you wind up with a random assortment

Questions:

How can you incentivize sales to stay aligned with product development?

  • Give your VP of Sales one “magic bullet” a quarter. A magic bullet allows sales 1 week of the development team’s time to close a specific sale. The VP of Sales, with the perspective of the pipeline and what customers are critical, gets to decide when to spend this magic bullet.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>