We are in a software renaissance. That much is clear to a lot of us. What isn’t clear, given the pace of change, is what to focus on.

If you’re a business leader, that is a critically important question to answer.

“Given how software is changing, how do I make decisions now that have a sustained impact on my organization?”

It’s useful, I think, to start with what we’re trying to achieve in the first place.

If we went back to before all this started, before you ever used ChatGPT, and I asked you what an ideal outcome in your business would look like, I don’t think you’d tell me you want large parts of the organization automated and faceless. You’d probably say, I need better software that helps our team achieve an objective.

To that end, organizations almost always consider two paths. Subscribe to SaaS off the shelf, or commission something custom.

Off the shelf is less risky. You try to find features that match your requirements, and make peace with what isn’t ideal.

Custom software has a better chance of being exactly what the organization wants, but is difficult to get right. It's an expensive mistake to make if you hire the wrong team. And the UX is often the last priority, which is why they’re often very ugly.

Both those approaches forget that the problem they’re solving is not only a capability problem. We achieve our objectives when taking action becomes routine, not when taking action becomes possible.

That’s the outcome you need to focus on.

What software experience would make the right actions routine for our organization?

A software experience that is core to your strategy, that your team loves to use.

When the experience fits the team, they won’t need continuous training, and they certainly won’t need to be managed to use it. You shouldn’t need oversight to make sure the work is happening.

When you think about it with this framing, it’s easy to see that the wrong outcome in this renaissance is to focus on writing more code, or producing more software, if you haven’t first thought about how to change the way your team operates.

If that’s the future we want to get to, we need to understand why we aren’t there right now. In my experience as a career developer and product manager, it comes down to two things.

1. Software projects are thought of as features instead of initiatives with measurable outcomes.

2. We treat software as complete instead of continuously adapting it to the exact environment in which it operates.

I hope you recognize that the second follows from the first. Continuous adaptation is a requirement to actually promise outcomes.

This does not mean every dashboard or internal utility needs a permanent product team. It applies when software is expected to produce a strategic business result.

This is a serious claim. And it should worry a lot of enterprise software developers and services. Tech startups are immediately punished when they don’t have users. Enterprise developers aren’t. Their work should be held to the same standard that startups are subject to. The products they ship are only valuable if they are used by people to do more economically useful work. If it isn’t adopted, then that project is incomplete. It either needs to be iterated on, or has failed.

Why is it silently changing in enterprises now? Three reasons, starting with the most obvious.

1. Developing software is easier because writing code is. Even though AI models are prone to making serious mistakes, and require expert handling to write maintainable code, there’s no doubt that we can now ship faster.

2. High quality engineering and product knowledge is no longer scarce. If a team didn’t have very talented senior engineers with storied careers, they didn’t know how to develop products that could match a certain standard. That’s no longer the case anymore. As long as the intent is clear, frontier models democratize the knowledge that’s needed to achieve a lot of tasks. This is one of the understated benefits of enterprise workflows.

3. AI, if integrated correctly, improves UX. Elementary examples of this include not needing to read emails all the time, or AI agents creating a task list for you daily. More advanced examples would be presenting information in the UI that helps users reach flow state faster. A lot of what people dislike about modern software can actually be abstracted away, because software can absorb much of the administrative work it needs users to do.

In summation, enterprise leaders who have experience leading digital transformation are focusing on demanding more from service providers when they know that the cost of revising the software has dropped. Waterfall project plans where feature lists are completed and handed over are no longer acceptable. Service providers are evolving to meet this demand, with better engineering practices, access to better knowledge, and development environments set up for their teams’ abilities. Features are designed and implemented with adoption and sustained improved business function in mind. Strategic software for these new enterprises is becoming a continuously managed asset, and service business models are responding in kind.

Let’s talk about how.

Business leaders think along these lines.

Business outcomes are part of organization strategy. Outcomes follow from improved workflows or routines, which follow from software capabilities or features that the team has begun to meaningfully use.

For example, an asset management firm might want to improve client satisfaction using better response times. CRMs and omni-channel communication software exists, but relationship managers are overwhelmed with their schedules to use CRMs or learn a new comms platform. The capabilities are correct, but the adoption depends on factors that are highly variable even within the same professions. Competencies, established workflows, local customs, preferences, even trust are all important to consider before features are designed.

Iteration is an assumed part of the process, but stakeholder management, including their frustration, is necessary. This is where judgement from engineers and product managers becomes key. How well they set up a feature in the first pass earns them the trust and respect from stakeholders which guides future conversations about updates.

Where software must adapt to the organization, and where workflows must be redesigned from the ground up is again a matter of judgement, and is the responsibility of the engineers and product managers.

A handy framework to keep in mind is the software payoff loop.

Payoff: What outcome does the organization need, and what does the team need to do differently to achieve it?

Experience: What should the software make possible, easier, or eliminate entirely? How must it be delivered within our exact environment?

Proof: Which measures tell us if the software initiative was a success? Usage stats, business outcomes?

As business leaders, think obsessively about this. This is a change that we’re seeing only at the frontier, in teams with very high talent density. Use the software payoff loop, and when starting a new initiative, set outcome targets, make strategic software a iterative, continuously maintained project, and know how to measure proofs.

At the beginning, I had you ask a question. What do I focus on? How do we win in the AI era? The companies that win will be able to execute their strategic objectives by capturing work in software experiences that their teams choose to use.