“Efficiency is doing things right; effectiveness is doing the right things.”

— Peter Drucker

People throw around these two words pretty indiscriminately in business, usually not making a distinction between them. They’re treated as interchangeable synonyms for broadly being “good” at something.

We can think about effectiveness and efficiency as two dimensions on a grid, often (but not always) in competition with one another. More focus on one means less on the other.

That Drucker quote is a pretty solid one-line distinction. But like many quotes, it’s concerned with being pithy and memorable, but not that helpful.

“Doing things right” is too amorphous. I’d define the two dimensions like this:

• Efficiency is concerned with being well-run, applying resources with minimal waste; having an economical approach
• Effectiveness is a focus on fit, fitting the right solution to the appropriate problem, being specific and surgical in approach

Where would speed fit into this? Many people would think of velocity of work as an aspect of efficiency, but it’s also a result of and an input to effectiveness. When a team of SEAL operators swoop in to hit a target, we’d say that’s just about the pinnacle of being “effective”, and swiftness is a key factor in driving that effectiveness.

Let’s look at some differences through the lens of product and company-building. What does it mean to orient on one over the other? Which one matters more, and when?

A company is like a machine — you can have an incredibly efficient machine that doesn’t do anything useful, or you can have a machine that does useful things while wasting a huge amount of energy, money, and time.

With one option, our team leans toward methods and processes that efficiently deploy resources:

• Use just the right number of people on a project
• Create infrastructure that’s low-cost
• Build supportive environments that get out of peoples’ way
• Instrument processes to measure resource consumption
• Spend less on tools along the way

With this sort of focus, a team gets lean, minimizes waste, and creates repeatable systems to build scalable products. Which all sounds great!

On the other dimension, we apply more attention on effectiveness, doing the right things:

• Spend lots of time listening to customers to map out their problems (demand thinking!)
• Get constant feedback on whether or not what we’re making helps customers make progress
• Test small, incremental chunks so we stay close to the problem
• Make deliberate efforts, taking small steps frequently, not going too far down blind alleys with no feedback

Another great-sounding list of things. So what do we do? Clearly there needs to be a balance.

Depending on preferences, personality types, experiences, and skill sets, different people will tend to orient on one of these dimensions more than the other. People have comfort zones they like to operate in. Each stage of product growth requires a different mix of focuses and preferences, and the wrong match will kill your company.

If you’re still in search of the keys to product-market fit — hunting for the right problem and the fitting solution — you want your team focused on the demand side. What specific pains do customers have? When do they experience those pains? What things are in our range that can function as solutions? You want to spend time with customers and rapidly probe small problems with incremental solutions, testing validity of your work. That’s all that matters. This is Paul Graham’s “do things that don’t scale” stage. Perfecting your machine’s efficiency is wasted effort until you’re solving the right problems.

A quick note on speed, and why I think it’s critical to being effective — if you’re laser-focused on moving carefully and deliberately to solve the right problem at the right altitude, but not able to move quickly enough, you won’t have a tight enough feedback loop to run through the iteration cycle enough over a period of time. Essential to the effectiveness problem is the ability to rapidly drive signal back from a user to validate your direction.

When you find the key that unlocks a particular problem-solution pair, then it’s time to consider how efficiently you can expand it to a wider audience. If your hacked-together, duct-taped solution cracks the code and solves problems for customers, you need to address the efficiency with which you can economically expand to others. In the early to mid-stage, effectiveness is far and away the more important thing to focus on.

The traditional definition of efficiency refers to achieving maximum output with the minimum required effort. When you’re still in search of the right solution, the effort:output ratio barely matters. It only matters insofar as you have the required runway to test enough iterations to get something useful before you run out of money, get beat by others, or the environment changes underneath you. But there’s no benefit to getting 100 miles/gallon if you’re driving the wrong way.

Getting this balance wrong is easy. There’s a pernicious aspect to many engineers, particularly so in pre-PM-fit products: they like to optimize things. You need to forcefully resist spending too much time on optimization, rearchitecting, refactoring, et al until it’s the right time (i.e. the go-to-market fit stage, or thereabout). As builders or technologists, most of us bristle at the idea of doing something the quick and dirty way. We have that urge to automate, analyze, and streamline things. It’s not to say that there’s zero space for this. If you spend literally zero time on a sustainable foundation, then your product clicks and it’s time to scale up, you’ll be building on unstable ground (see the extensive literature on technical debt here).

There’s no “correct” approach here. It depends on so many factors. As Tom Sowell says, “there are no solutions, only trade-offs.” In my first-hand experience, and from sideline observations of other teams, companies are made by favoring effectiveness early and broken by ignoring efficiency later.