Beyond Tasks: Reimagining Workflows in the Age of AI
AI will "shift left" work, empowering individuals to perform tasks previously beyond their scope. Roles inside the organisation will evolve. What does this mean for the future of enterprise products?
While everyone in the startup world is excited about AI, it’s clear that the typical advantages startups enjoy are not as potent this time. Incumbents have hoarded data, they’re not oblivious to AI’s potential, and are drawing in some of the best talent [1]. How can startups break through?
In this post, I explore one such lens to ideate truly breakthrough ideas : zoom out and reimagine the entire workflow, not just the task.
Shifting user personas and roles
Most product teams and startups today focus on optimising for a particular person (e.g. end user or support agent) instead of focusing on the final outcome (e.g. faster, more personalised support). Given that every enterprise operation is essentially a workflow involving people with varied skills working towards a common outcome, what if we considered the entire workflow and not any one user?
My hypothesis is that with the help of AI agents, a lot of the work will “shift left” — AI agents with complementary skills will empower individuals to perform tasks previously beyond their scope, prompting us to reconsider our user personas & how roles evolve. Organisations prefer this too because it helps frontload the risk, and lowers cost of execution.
Let’s explore two examples to illustrate this point :
Tech Support
Tech support includes anything where support and dev teams interact frequently (e.g. support for SaaS products, IT support in enterprises, etc). The typical solution here is to build a chatbot trained on past tickets and documents. Now, anyone who has worked in tech support knows that the real reason of delayed resolution, confusion and frustration is the back and forth between the support agent and the developer. Some examples -
Incorrect assignment : The issue surfaced in one part of the product but originated somewhere else and got assigned to the wrong dev team
Missing information : User shared vague or incomplete information and developer asks for more information
Basic troubleshooting : Developer needs to spend a lot of time searching through logs, looking at bug reports and mapping bugs to recent releases.
Most of these tasks can be easily solved at the level of the support agent if they were equipped with AI copilots proficient in understanding code, logs and debugging. This capability could significantly decrease resolution times, shift simple tech support issues to the support team, and enhance developer productivity by allowing them to focus on more engaging tasks (stuff they enjoy!)
What would the ideal interface for this look like? I envision a blend of Slack and JIRA, where there’s a seamless interaction between bots, agents, and developers without traditional “handoffs” (where only one entity is working on a ticket at a time, which is what happens in all chatbots and support solutions today). A place where multiple technical agents are available with the L1 support team to help them with “tech stuff” and can be invoked at will.
Developers are only brought in when AI agents are unable to resolve an issue, and the platform ensures that even these interactions contribute to training the AI, thereby completing the feedback loop. Such a solution is difficult for incumbents to replicate due to the need for a bottom-up product rebuild (multiple agents and humans communicating at the same time). Plus, it doesn’t align well with their pricing model which is either per session or per agent. This is basically, outcome-as-a-service. We also developed a prototype of this concept during my sabbatical. [2] [3]
Learning & Development
Now, let me take you to a completely different world which seems to be far away from support but is actually quite connected (as you will soon find out!)
Traditionally, 100% of the trainings were instructor-led — employees were brought into a room, given a few presentations and asked a few questions at the end of it. People felt this is very different from what SMEs do, and therefore, L&D used to be a separate department altogether. Although enterprises have since adopted self-paced training and video-based learning, they still don’t see the results that they’d hoped for.
There are two reasons for this -
Training content gets outdated quickly as products and policies evolve
Real learning occurs on-the-job, driven by immediate needs rather than scheduled training sessions — when 30 presentations are shoved down your throat over a week.
Companies like Sana Labs offer a novel solution — they directly connect with the knowledge base and internal communication channels (e.g. slack, Onedrive, Notion, etc.) and build content on top of them. This enables -
Learning in the flow of work (people ask questions when they need to, and learn when they are open to it — think stack overflow for developers)
Byte-sized learning (only get the information you need with the ability to explore more)
Always up-to-date with the latest content
For Sana’s customers, Knowledge Management and L&D begin to converge — which makes sense, because why not connect learning directly to the source of truth? Note that if Sana restricted themselves to solving for the tasks that L&D teams do today, they would have probably built a better LXP instead.[4]
Other examples
The trend of generalists being able to own some specialist tasks with AI assistance extends beyond these examples:
PMs can now draft initial designs, leaving designers to concentrate on visual aspects.
Figma’s dev mode simplifies collaboration between designers and developers.
Nurses and technicians can make accurate preliminary assessments using diagnostic tests, traditionally a specialist’s task.
AI enables technicians to predict and address equipment failures proactively, tasks that traditionally required specialised engineers to analyse patterns and predict issues.
Paralegals could perform more complex legal research and preliminary case assessments, traditionally the realm of more experienced lawyers.
Using this lens to build better products
Consider the final outcome and build for the workflow. e.g. Figma was built for great design, not for designers. For instance, Figma succeeded not by building for designers but for the design process, emphasizing collaboration among all stakeholders.
By shifting our focus from individual users to teams, departments, and entire organisations, we can uncover root problems. Maybe the root of the problem is farther away from the symptoms and with AI it’s now possible to solve the problem at the root (the L&D example above, or the hiring vs performance problem).
To differentiate from the incumbents, look at adjacencies — places where handoffs happen from one team or person to another. There’s likely a possibility to “shift left” there, or a better workflow altogether.
Of course, all of this needs organisations to change their way of working. While building solutions that fit into existing workflows is pragmatic and necessary today, keeping an eye on the future is crucial. This vision will prepare us to adapt to and capitalise on these changes as organisations evolve.
Hope this perspective inspires you to consider how these shifts might apply to your field. Happy building!
[1] AI startups require new strategies — blog by Jason Cohen
[2] Coval.ai — early results were promising but I decided not to startup, will write about it some time!
[3] Some companies trying to combine dev and support — Thena, Clearfeed, Devrev — however I am not sure how similar their thesis is.
[4] Josh Bersin wrote about autonomous learning platforms if you are interested.