Anyone can build. Will anyone use it?

By Jacob Doogue, Co-Founder and CTO of Rmkble's ProcessPath.
‍

Abstract

AI tools have made it simple for anyone to make an app or agent now and this has recently expanded even in typically locked down enterprise contexts.

The AI built for work.

Microsoft recently provided an update where they are further leaning into the idea of a AI platform for work, by expanding Copilot to include not only Chat, Cowork and Autopilot, but Code as well.

Copilot Code is positioned as a way to build individual productivity tools where you can use natural language to describe an app, tracker, dashboard or automation to build and it uses the same technology as Github Copilot, and is within your Microsoft Tenant.

Enterprise apps from a prompt

There also a new feature in Copilot Cowork that allows users to build apps. What's different about this is it uses a range of Microsoft technology under the hood - like SharePoint lists, Dataverse and connectors - which give the apps better controlled access to data and the ability to implement security and access controls for that balance between innovation and governance.

Build outside, run inside

Another new announcement is the Copilot Managed Run Time the idea being that you can build with whatever external AI tools you prefer, but then run the code within your Microsoft Tenancy. The intent here seems good as the promise is to provide a CLI and SDK so you can build apps and agents to integrate with Microsoft services, working with the current controls within your tenant.

What will people build?

I'm looking forward to experimenting with all these new features soon, but now that everyone can build, and in enterprise environments, what do people typically build in organisations?

Personal productivity

There are a few broad categories of apps and agents that people build, the first being personal tools. Often automations that help them summarise or retrieve information, or create small reports, then research and analysis, such as comparisons, options or background into a particular topic. Then many people us apps and agents to help with drafting documents, for compiling a standard report, to gathering context to being together a document.

Team tools

The next category are tools that small teams often use - like trackers and dashboards, intake and triage processes, knowledge agents and automations to complete swivel chair type operations (take data from one source system and enter it into another).

Department / function tools

Audience Grows, Complexity Grows.

This is where things get more interesting as people will develop sizing tools - calculators or estimators that can be used by a range of people or departmental level workflows - something that doesn't sit perfectly in a larger system (ERP, CRM), and often a process with a workflow unique to the organisation, things typically involving approvals and compliance processes. Audience Grows, Complexity Grows. As the audience for an app, agent or automation grows, usually the complexity and considerations also grow. If an app only had to be envisioned and work for 1 person, they are typically happy to also work through minor problems or bugs, as really the value proposition is that this self made tool is still saving them time.

Team apps can generally be adopted in a team where the app or agent is developed or endorsed by the team leader - e.g. you need to use this tool to be a contributing member of the team and if you're not, maybe your work is not visible to the team, there is a social drive to contribute. In general, teams will have similar levels of security and permissions for a range of systems and applications, so significant security and access control barriers are not hit.

Departmental apps become more interesting as now the potential audience and stakeholder group is larger and security, access control, permissions, integration and sources of truth become more interesting. Is the app created and maintained by one team? Do you need endorsement from a range of managers to use this new app or workflow? Do you need access controls for some users to see some data and other users should not see it?

Business Processes are often emergent, not designed

Often a process or workflow is implemented or changed because something went wrong or there are new compliance requirements. It is not often that processes and workflows are genuinely re-engineered or designed from the ground up. The excel spreadsheet used to track this process was implemented because a contract was delayed, or we now have an intake form as other areas of the business would bombard us with requests, so we needed a way to triage and refine requests.

As soon as you start working across teams or with people with different roles, they all have different perspectives, different priorities and view the work in different ways. This makes it hard to gain consensus on what any app, agent or automation should look or behave like, which is why often there is a person who leads the initiative (and often the development) - to put something out there into the hands of people to use. So now that this part is easier with AI, what next?

Who cares about what you built?

And this is where things usually hit a brick wall. Now the challenge becomes adoption. If you can build something quickly, will other people want to use it? I find that time and time again, the ideas I have as a builder don't matter. What is important that the people that own and use the app/agent/tool have input to the creation of the product to drive a level of ownership and accountability beyond the first prototype. If you didn't build it, typically you won't care about it. Conversely if you contribute an idea and you see that idea implemented and come to life - now you're part of the product and you feel a level of ownership, such that you're more likely to champion the adoption of the app/agent/tool.

If you didn't build it, typically you won't care about it.

Who's going to keep it up-to-date?

So if you can manage to get other people to care about what you built, are you going to keep updating it? This is the next blocker that internal tools often hit, that a key person who built it leaves, or their work focus changes and the tool is no longer maintained to be current with business context, alignment with roles and processes, data gets out-of-sync.

So what's changed and what's new?

Many of these challenges - adoption, ownership, maintenance - are not new, these are the same challenges with Microsoft Access and Excel that have been occurring for many years. What's new is that anyone can build many things very quickly, but the question remains if it will be adopted.

Building T-shaped teams

This is why for the last few years I've been working on building small very T-shaped teams (broad consulting skills and deep Microsoft development skills) that can not only build, but importantly can work to genuinely design new business processes, collaboratively with process owners and users and iterate on what the solution looks like to implement something new and something better. This work between operational teams and technology teams is the key ingredient to drive adoption, usage and then longer term value. So whilst lots of people will still build ideas, apps and agents for themselves, they'll likely hit the same challenges of adoption beyond their immediate team.