Itzy Sabo

July 5, 2023

Escape the Feature Factory trap to unleash exponential value!


Imagine that your product planning and software development priorities are tactical and feature-driven, rather than strategic.

You have clever, capable and diligent product managers and software developers. They are sweating away with picks and shovels, steadily chipping away at your mountainous product backlog. Your department works like a well-oiled machine, processing tickets and delivering new features by the dozen, on time and to specification, consistently.

💡 You're running a feature factory; optimising for output, not outcome.

Factory assembly lines crank out identical units, each of which has an identical business value, which is also well-defined. It's a mistake to think of your software development operation in the same way, because:

  • An assembly line optimises for process efficiency, not product effectiveness.
  • Different features can contribute wildly differing amounts of business value.
  • Features are not identical, so you invent arbitrary prioritisation criteria.
  • Most of your features will not improve any business metric.
  • Effort and profit are not directly related.

The problem with a feature factory is that the focus is on fulfilling requests, rather than improving core business metrics. The constant stream of requests encourages you to optimise for efficiency rather than effectiveness. Insufficient consideration is given to the business value of the features being churned out.


The solution is to optimise the process to maximise business value. Business value needs to become a thread that runs throughout the whole process. 

The essence of the solution is to clarify what the company wants to achieve, and then to allocate the bulk of the development budget towards that, and little else.

Make business impact the driving force behind everything you do, by adopting these principles:

  • Core metrics: tie as much work as possible to the company's core business metrics.

  • Roadmaps: instead of detailed lists of features, express business outcomes that will be achieved and/or initiatives that the company will focus on.

  • Prioritise work based on expected business impact, using the roadmap or core metrics.

  • Budgets: keep different types of work within pre-determined budgets.

  • Productivity: base your productivity metrics on business impact.

These principles are simple to grasp. However, implementing them requires organisational finesse, patience and perseverance.

I'll provide a mechanical solution to get you started, but the major breakthrough will happen when you notice that your company's mindset has changed.

How I Introduced Budgeting — the Trojan Horse Method

An evolutionary approach usually beats a revolutionary one. However, when you look back after multiple steps, there's no question that a revolution has taken place. This is the story of how I quietly and gradually introduced a new way of thinking, without declaring a revolution.

We were a sales-led company. Some of our large customers routinely leveraged their size to convince us to implement special features for them. Such behaviour is a fact of life at many software companies. 

I started tracking the development costs of these Customer Specials in each development cycle, and I made sure to keep management aware of both the direct costs and the opportunity costs¹.

The amount of attention we were devoting to Customer Specials, and diverting away from the general customer base, seemed excessive. After a few cycles, it wasn’t a big leap to get management to agree to limit the effort we could expend on Customer Specials by allocating a specific effort budget.

💡 Yes, I slipped the word budget in quite deliberately. Executives are accustomed to budgets, although this use stretches the concept a little.

OK, I admit it — I've understated the problem somewhat. It wasn't just Customer Specials —  my department had become a feature factory and our way of working needed a serious shake-up.

Once I had wedged open the door using Customer Specials, I widened the gap by sneaking in another 6 categories. Everything we did  from that point onwards was assigned a business impact category.

Later, I took it yet another step further, and with the cooperation and active participation of the rest of the executive team, organised quarterly planning meetings — more on this below.

The 7 Business Impact Categories 

I recommend adding a field to your issue tracking system, and/or tagging your issues using the following business impact categories:

  1. Basics
    Features that are so basic that the product is not viable without them. New products will have these features; mature products won't.

  2. Differentiators
    Unique features which distinguish your product from the competition. Alternatively, improvements which are game-changing by an order of magnitude. These are what the business needs to win!

  3. Incrementals
    Continuous improvements to existing features. You need these in order to retain your customers.

  4. Technological Foundation
    Infrastructure improvements for scalability, performance, reliability, maintainability, etc. This includes paying down historical² technical debt.

  5. Speculative Bets
    Potential differentiators, but without any reliable evidence. 

  6. Embarrassments
    Fixes for embarrassing mishaps that make the product or company look unprofessional (“broken windows”).

  7. Customer Specials
    Work done for a specific customer which you would not otherwise do, or at least not now.

How to Use the Business Impact Categories

You can use the business impact categories in two independently useful ways: retrospectively and proactively.

  1. Analyse all the work that you've delivered recently.

    How was effort distributed across your business impact categories?
    How much effort did you waste on things that don't "move the needle"?

    These results show how well your recent output reflects your company's business goals. If the results are not satisfactory, you can use them to get management buy-in to change the planning process so that it aligns with the company's goals — see next.

  2. Use the business impact categories to align your plan with company business goals.

    When planning, allocate an effort budget per business impact category, based on what it will take to achieve or support the company's business goals for that period. This can be done at multiple levels such as quarterly planning down to planning individual sprints.

In How to Deliver Business Value Predictably, I referred to effort budgets as an advanced planning technique. To stretch the aviation metaphor I have been using, the business impact categories would be different "fuel tanks", designated for specific uses.


In addition to the improved focus brought by business impact categories, you can define initiatives as a high level way to drive your planning.

Back to my story. After several months of working with business impact categories, we were ready for the next step: quarterly planning.

Rather than a typically useless presentation-fest, the company's executive management team and other key figures met with the product and engineering organisation for an intensive series of interactive discussions over a short two-day period.

During this time we aligned our departmental plans fully, and produced a list of initiatives that we would work on. Each initiative was allocated an effort budget, based on our teams' capacities, growth plans and hiring forecasts. 

😎 For the first time, and from this point onwards, each engineer would be able to know exactly how s/he would be contributing to the company's goals.

Whether or not you do quarterly planning, and regardless of the method you use, you should decide on a periodic basis:

  • What business problems does the company want to solve?
  • Which business metrics does the company want to improve?
  • What is it worth to the company to achieve each of these these goals? 
  • How many people and how much time can the company afford to dedicate to each?

Think in terms of initiatives rather than features. Decide how much attention you would like to give to each initiative — this will be its effort budget³.

Features should be invented to serve specific initiatives and their goals. They should then be sliced and worked on within the effort budgets. Later, you'll be able to measure their success against those goals, too.

Initiatives vs. Impact Categories

We started with business impact categories, and then graduated to initiatives. Does this mean we no longer need those business impact categories?

Initiatives and business impact categories can be used independently of each other. They can also both be used at the same time, because they are orthogonal to each other.

If you have graduated to initiatives, I still recommend using business impact categories to ensure that you are balancing the different types of work, and are not starving some types of activity.


  1. Allocate as much effort as possible to Differentiators.

  2. Next come Incrementals.

  3. Labelling your Speculative Bets will help you ensure that you make enough of them to succeed, but also keep them within sane levels. Don't expect more than a 15% success rate for these.

  4. Customer Specials and Embarrassments should ideally need zero attention. Good luck with that.

  5. Allocate a fixed budget for Tech Foundation. It depends on the maturity of your platform, but I would suggest anchoring your opening bid at 25%.

"Can you help me?"

🤙 Yes, I can help you make this transformation. Contact me via my bio at the bottom of this page. 

Thank you for reading this far!

Comment, ask, suggest, clarify and especially correct me via this LinkedIn post


¹ There is also a third type of cost to adding features: the larger and more complex your product, the more expensive it is to make further changes.

² Historical technical debt is the "bad" kind of technical debt that accumulates like rust. The "good" kind of technical debt is temporarily incurred when you implement an experimental feature. If it works, you pay back the debt in the next cycle. If the experiment fails, you remove the feature, and its debt.

³ You'll need to know what your total capacity is for this; step 1 above will give you the answer. How to deliver business value predictably discusses how to do this in more detail.

About Itzy Sabo

👋 I'm Itzy Sabo, an Engineering Management Expert & Fractional CTO.

What if your engineers could deliver more business value, faster?

Please see my CTO Logic newsletter for my latest posts.