On "Business Value" and Prioritization

What Is Business Value?

Every CTO bandies about “business value” as if it’s some universal truth, but the reality is that business value is contextual. What’s valuable to one company may be a distraction for another. A pre-revenue startup prioritizes rapid iteration and product-market fit, a company in growth mode might prioritize feature enhancement, while a large enterprise might focus on cost efficiency and risk management.

As CTO, defining business value within the context of your company’s maturity, product, and customer base is crucial. It’s not enough to say, “Scalability is important.” You need to know why and how something like scalability impacts the business. Is it revenue-generating? Does it improve retention? Does it eliminate a major operational bottleneck?

Without clear definitions of an engineering team’s business values, engineering priorities end up being dictated by external forces. Most often in ways that don’t align with long-term success. Sometimes, that means the loudest voice in the room wins. It can also mean chasing shiny objects that aren’t truly valuable. Maybe sales wants a flashy feature to impress prospects in demos, even if it adds complexity without real user impact. Maybe a big enterprise customer makes a unique request, and suddenly your team’s spending months building a one-off solution that won’t scale to the rest of your customers. Or maybe marketing wants a visually striking, memeable UI element that looks great in screenshots but adds no real usability improvements.

When priorities are driven reactively rather than strategically, engineering work becomes a series of knee-jerk responses rather than a structured approach to delivering long-term business value. Tech debt accumulates, core product development slows down, and engineering teams feel like they’re constantly fighting fires rather than building meaningful improvements. This doesn’t mean stakeholder input isn’t important. Sales, marketing, and customer success all have valuable perspectives. But without a clear, engineering-driven framework for prioritization, the team ends up optimizing for short-term wins over long-term sustainability. CTOs who define, measure, and communicate business value effectively ensure that engineering doesn’t just respond to demands; it proactively drives business impact.

Categorizing Engineering Work by Business Impact

Engineering leaders instinctively categorize work tasks. In the past, I’ve used features, bugs, infra, and tech debt. But formalizing this process can create measurable impacts. Itzy Sabo explores this in depth in his workshop on engineering effectiveness (CTO Grandmasters). His approach helps teams understand where their effort is going and whether it aligns with business value.

Just as each engineering organization should have unique definitions of business value, I think each org should generate its unique categories for work tasks that relate to those definitions. A good categorization framework might look like this:

1. Essential Work: Necessary for the basic function of your product, like authentication, checkout flows, and the like.
2. Revenue-Generating Work: Directly contributes to sales, upgrades, or retention (e.g., new features customers request, improving conversion rates).
3. Customer Experience Work: Enhances user experience, engagement, or ease of use (e.g., reducing friction in onboarding, improving performance).
4. Operational Efficiency Work: Saves time, reduces waste, or improves internal processes (e.g., automation, CI/CD improvements, internal tooling).
5. Risk Mitigation Work: Reduces security, compliance, or technical debt risks (e.g., fixing vulnerabilities, migrating away from fragile systems).
6. Exploratory Work: R&D, prototyping, and foundational efforts that may create business value but aren’t guaranteed (e.g., experimenting with AI, evaluating new frameworks).

Maximizing effectiveness means continuously reviewing where engineering effort is going and creating the right mix from one dev cycle to the next. If 60% of the work is exploratory while revenue-generating projects are stalled, that’s a misalignment.

Measuring Business Value Over Time

Okay, so you’ve defined business value for your organization, and you’ve begun to categorize past and current work according to your framework. The next step is measuring your team’s impact upon those lines. Many companies prioritize work based on gut feeling, but if you don’t track impact, you’re just guessing! Without clear metrics, it’s impossible to know whether engineering efforts are moving the business forward or just keeping people busy in a feature factory.

The right measurements depend on your business model. You should define metrics that align with the types of work your teams are prioritizing. For example:

• Essential Work → Measured by System Reliability & Core Functionality
  Does this ensure the product works as expected, without friction or failure? Critical systems must be stable, performant, and secure. Metrics like uptime, error rates, response times, and transaction success rates help track the effectiveness of this work.

• Revenue-Generating Work → Measured by Revenue Impact
  How much does this contribute to new sales, upsells, or retention? This includes features that drive direct monetization, increase customer lifetime value, or improve conversion rates.

• Customer Experience Work → Measured by Engagement & Satisfaction
  Does this improve engagement, satisfaction, or retention? Faster performance, fewer bugs, and better UX contribute to lower churn and higher user retention.

• Operational Efficiency Work → Measured by Cost Savings & Automation
  How much time, money, or effort does this save? Optimizing cloud infrastructure, automating deployments, or improving internal tooling reduces costs and improves team velocity.

• Risk Mitigation Work → Measured by Security & Stability Metrics
  Does this reduce major risks? Fixing vulnerabilities, improving compliance, and tackling technical debt prevent costly incidents and improve system reliability.

• Exploratory Work → Measured by Strategic Potential
  Does this create opportunities for future growth? R&D, proof-of-concept projects, and new tech evaluations should be assessed based on their potential to unlock competitive advantages.

The Special Case of Exploratory Work

Unlike other categories, exploratory work is hard to measure upfront because its true value may not be realized for months or years. It’s my humble opinion that some form of experimentation should always be included in the mix, if for no other reason than engineers generally enjoy this work. But how can it be measured? Some suggestions:

• Adoption Rate: Did the proof-of-concept evolve into a widely used feature?
• Team Engagement: Are your engineers more excited about work when exploratory tasks are included in the mix?
• Direct Feedback: You could ask users for qualitative feedback on the results of exploratory work.
• Efficiency Gains: Did an experiment with new infrastructure reduce future development effort?
• Market Validation: Did early R&D help the company stay ahead of industry trends or unlock a new competitive advantage?

Because exploratory work is uncertain, it’s crucial to measure outcomes as best as possible. It’s easy to spend too much effort on R&D without clearly demonstrable benefits. Always time-box experiments so they don’t impact other categories.

Business Value Measurements Aren’t Static

Early-stage startups prioritize speed and experimentation, while mature companies optimize for efficiency and stability. Revisiting these measurement tactics regularly ensures that engineering efforts align with the company’s current needs rather than outdated assumptions. Like an engineer, you’ll need to iterate.

How Often Should You Reevaluate Definitions and Measurements?

A good default is at least every six months and following any major company milestones. Examples of events that should trigger a reevaluation include:

• A funding round (Does investor pressure shift the business focus?)
• Significant user growth (Do scalability and operational efficiency become higher priorities?)
• A shift in revenue strategy (Are you moving upmarket? Targeting a new customer base?)
• Mergers, acquisitions, or leadership changes (New executives often bring new business goals.)

Who Should Be Involved?

While engineering leadership drives the technical strategy, business value isn’t defined in a vacuum. Cross-functional input is crucial, considering these values apply to the business overall. Product, finance, operations, and even customer success can provide insights on what’s delivering real business impact vs. what looks good on paper.

Signs Your Business Value Definitions Are Outdated

A formal review process isn’t necessary; it could be little more than a calendar reminder for yourself and a handful of short emails. Regardless of how you structure the review process, watch for these red flags:

• Engineering priorities consistently feel misaligned with company strategy.
• The mix of actual work accomplished never aligns with your categorical goals.
• Stakeholders push for work that doesn’t fit into any defined business value category.
• Teams struggle to justify why certain projects are being prioritized over others.
• Metrics fail to capture the full impact of engineering work.

By tracking these metrics over time and reevaluating them when necessary, CTOs can demonstrate engineering’s impact in business terms, justify investments in key initiatives, and ensure that the team’s efforts are delivering meaningful results.

Prioritizing Work Based on Business Value

Once you’ve categorized work, alongside figuring out measurement, you can start prioritizing based on impact. Things can get tricky here because everything feels important to someone! Engineering wants to clean up legacy code, product wants new features, sales wants flashy demo enhancements, and the CEO heard about this cool new trend. As CTO, you’re accustomed to balancing all these competing needs, right? Pushback from product should be expected. But if you’ve communicated your definitions, saying “no” or “not now” should be easily justifiable.

Use a structured approach to ensure engineering effort is focused on the right work at the right time. Consider clarifying questions like:

• Are we investing in the right areas?
• What’s the opportunity cost of not doing this work?
• Are we focusing too much on one category while neglecting another?

Example: The Feature vs. Tech Debt Trade-Off

Let’s say your product team is pushing for a new feature that’ll help sales close deals faster, making it revenue-generating work. At the same time, your engineering team is flagging a critical infrastructure upgrade that’s been delayed for months and poses scalability threats if user growth continues. That falls under risk mitigation work. Not urgent today but potentially disastrous later.

How do you decide?

1. Compare Business Impact: The feature may drive short-term revenue, but will it create maintenance headaches? The infrastructure work won’t directly generate revenue, but does delaying it put the company at risk?

2. Assess Timing & Dependencies: Can the feature be built without making the infrastructure problem worse? Or would shipping it now mean a painful rework later?

3. Consider Stakeholder Alignment: Does leadership understand the trade-offs? Does sales have alternative ways to close deals while engineering tackles the infrastructure upgrade?

4. Look at Past Trends: Has tech debt consistently been deprioritized? If so, the long-term cost of ignoring it might outweigh short-term sales wins.

A possible decision: Delay the feature slightly but communicate a clear roadmap for when it’ll be prioritized. In the meantime, tightly scope the infrastructure upgrade and put a hard deadline on it. This ensures long-term sustainability while ceding some ground and setting expectations with stakeholders.

These kinds of trade-offs happen constantly. It’s easy to let tech debt pile up while focusing on revenue generation, but that neglect can create a long-term drag on velocity. It’s just as easy to over-index on refactoring and forget that without little enhancements, customers will churn.

For CTOs, the key is not just making these trade-offs but also communicating them clearly to the rest of the company. Leadership needs to understand why certain work is prioritized over others, and engineers need to see how their work contributes to business success.

Final Thoughts

Engineering work is never merely “let’s build cool shit” (although that is important). It always serves a larger business purpose. But without a clear definition of business value, a system for categorizing and prioritizing work, and a method for measuring business impact, engineering efforts can become misaligned with what truly drives company success. It can devolve into a grind, a factory mindset, in service to loud voices, trends, or whims.

By making business value a guiding principle in decision-making, CTOs can ensure that engineering isn’t just working hard; it’s working smart, on the right things, at the right time.