The Implications of the AI Age for the Application Software Market
Get your popcorn people!
In our last piece, I made the following prediction:
Using our definition today of what is an Application Software Company (i.e., application software that employees use to be more “productive”), I predict with more than 50% odds that in just a few years:
There will be 75% less employee-facing application software companies
There will be 50% less employee-facing application software categories
We may see a return to “winner take most” dynamics in the employee-facing categories that remain
Here is why I believe the statements above are factual:
1. One Agent for Me Please
Humans will Gravitate Quickly to One Agent as Fast as Possible
The second that a user interacts with a super helpful agentic “buddy”, it is their new best friend. Like humans, they will want to see how broad and deep that new best friend is before they go find additional best friends. They would like that agent to solve more of their needs - i.e., answer more questions, solve more problems, and assist me with more actions. Once they taste this new experience, they are not going back to hunting and pecking across multiple applications - or, in the new world, having to use numerous agents unless they can avoid doing so.
It means that those software companies that deliver the “best” agent for a functional user will be able to collapse/consolidate directly adjacent market categories (i.e., other software that this user has been forced to use before) both because the user is demanding it and it’s much easier to build that capability (the UX layer to build is a tiny fraction of what it once was). As a result, we believe the winners in these spaces will grab a far more significant majority of the spoils.
We at Bonfire Ventures are already seeing this in our AI-first companies - their customers are so delighted by the initial interactions with the company that they have asked them, “Hey, I have been buying this stuff and this stuff too for this set of users. Can you just do that as well?” Interestingly, it is much easier for software companies to say yes, as they do not need to hire entire scrum teams to build an array of visual screens, fields, and workflows. As such, the only natural conclusion is that there will be dramatic consolidation within employee-facing application software categories. Yes, a user may use/manage a few agents, especially in non-vertical use cases, but any beyond that is a stretch over a more extended time. Ironically, fully autonomous digital workers will not have this same constraint as machines don’t have the context switching constraint humans do and as long as there is an API, might talk to many different software applications / data sources if they need to.
2. MetaData as the Moat
Your Technical Moat is Reduced to MetaData & Context
As the world moves to an agentic UX for application software - i.e., digital assistants to help human workers or digital workers that replace human workers, your proprietary user interfaces become irrelevant. Sorry. They just do. Therefore, for your agentic UX to be valuable enough for someone to use, it better have a breadth and depth of “knowledge” to offer up. That knowledge comes from your ability to a) make your metadata contextually LLM smart and b) have enough meaningful metadata in your product.
If you aren’t a meaningful enough system of record today around a core set of problems/tasks that a user wants to be solved/done - you can not become a relevant agent for a user. Do not tell me about your data moat - that mattered in a world of proprietary AI that used to train on your large data sets - that is ephemeral at best now. Additionally, if you play in an application category that does not have enough meaningful metadata, there are only two natural endgames for you:
a) Another company that better broadly serves your user (i.e., has more relevant metadata) will just add that bit piece that you do and/or
b) Your customer will build this capability themselves using an agent-building platform
Apart from being poor news for you, it might mean that all the competitors in the application software category you compete in go poof. The category really isn’t a category anymore, as there isn’t really that much meaningful metadata in that market's problem/solution set to justify an additional purchase by a company for the solution.
3. Build, Baby Build, Internally
The Return of Custom Build
Twenty-five years ago, in the on-premise software world, competing against organizations custom building their software was a very real thing - i.e. the age-old buy vs build debate. We had to justify why organizations were better off buying our solution than building it themselves. This was harder to explain in the on-premise world than it was in the cloud given how expensive and painful it was to use, deploy, and manage our software. In the end, though, we would win out with the 1-2 pitch of “you are experts in running your business but not in building purpose built software for sales, marketing, etc,” and “there are no economies of scale and scope in you building what we build for 1000’s just for yourselves”.
With where the cloud is today, one could easily argue that these justifications are weaker, especially given how much easier it is to build, deploy, and manage software, given a majority of the application stack has been commoditized and AWS-ified. Regardless, companies still, especially if they are B2B or B2B2C companies (B2C companies have huge internal custom build teams as often their SW is their customer-facing product - think fidelity.com, ebay.com, etc), look to purchase from independent companies as those software companies are wholly dedicated to solving specific needs and can bring best practices/principles to the buyer as well.
However, one thing companies know well is their own “Jobs to be Done” - i.e., what I want my employees to do in their respective functions. In an agentic forward world, where I want the software to help my employees just “get their job done well” rather than “hunting and pecking” across multiple applications, companies will aggressively revisit this buy vs build trade-off - especially when to “build” no longer means large swaths of full-stack teams and millions of line of custom code to manage. As such, to sell new software to customers means it has to be 3-5x better than what they can whip up in a few weeks internally with one of a dozen agent/assistant building platforms in the market - which is why metadata is the new gold.
4. Which Agent are You
The Types of Viable Application Software Companies
When I speak of the Appfolio Realm-x example, I am talking about the new approach to traditional application software—i.e., software that is bought by companies to make functional workers more productive either individually or as a unit by driving more consistent processes and keeping a close eye on the appropriate performance metrics to manage. This is what I call a Digital Assistant. I prefer that word to co-pilot, honestly, as these new AI interfaces exist to serve the workers and make them far more productive.
I like to define a digital assistant as different from a digital worker in that that assistant works for a given human employee at your company. For me, a digital worker is more of an autonomous agent that replaces existing employees today (think inbound SDRs) or entire chunks of work (think RFP responses). A digital worker is the next evolution of what we have always called automation, albeit with an identity you can define, gaps it self-identifies, and competence you can train.
We will soon see org charts at all companies with a mix of human employees with digital assistants who help them and digital employees with humans who “manage” them. By soon, I mean in less than 12-18 months.
Within that context and my prior assertions, there are then two broad meta-categories of viable application software companies, and within them, up to 4 roles of value to offer.
The Software Assistants - The Roles
The Public Boss (Application Component)
This is the primary interface that each of your functional workers will rely on for most of their job. From an analogy perspective, think of an application software company, but instead of using 8-10 apps, each functional user starts to gravitate around just a few in a horizontal use case and hopefully one in a vertical use case.
The Private Boss (Application Component)
This is the same as the Public Boss Assistant except one in which organizations choose to build themselves using an assist/agent building platform because either the jobs to be done are not that complicated (i.e., metadata light) and/or the jobs to be done are not offered by software companies effectively enough for their needs.
The Helper (Platform Component)
The Helper assistant lives to help the Boss agent more effectively meet the needs of its targeted functional users. These providers of Helper Assistants solve a more nuanced or complicated sub-task and do it exceptionally well. Besides those who “manage” the assistant, end-users will likely never directly interface with these assistants. In the last two eras of application software, these were additional applications companies bought that users used to do what their primary application could not. In the AI era, these solutions move down the stack and become platform components going forward that exist to make Boss assistants more competent.
The Conductor (Workflow & Integration Component)
The Conductor agent, no pun intended, orchestrates actions across Boss assistants or between Boss Assistants and Helper assistants. Providers of Conductor assistants will endeavor to make it far more straightforward than today to manage the mess of all of this software you use across your organizations and, more importantly, self-identify around the clock where improvements need to be made. Conductor assistants are likely included in any agent/assistant buying platform a company buys for internal build work.
The Software Assistants - The Market Dynamics
In the market for Assistants, organizations will first look to purchase a Public Boss assistant or build their own Private Boss assistant (leveraging an assistant-building platform). They may also evaluate whether they can skip this entire evaluation and eliminate the work to be done / headcount with a Digital Worker.
They will push those Bosses to do as much work as possible for a given functional employee as employees don’t want to use multiple assistants. They then will purchase Helpers to solve complex or nuanced sub-tasks that they feel are critical for their Boss assistants to know/do now. Organizations will next look to standardize on one (if they can) vendor for Conductor assistants to ensure all of the assistants (along with their human counterparts) are working together as effectively as possible.
From a competitive market perspective, the dynamics will be fierce. In this battle for assistants (i.e., the logical evolution of today’s application software), especially for the Boss assistant, I see market-share winners that we have not seen since the on-premise days. Functional employees will not want to use multiple Boss assistants, so there will be a few winners in this market per application category. As previously stated, dominant Boss assistants will also start to consume directly adjacent software categories either by extending their capabilities because it’s easy to do so or by forcing those adjacent software category players to become Helper assistants subservient to them.
On the pricing and packaging side, the Boss assistants will serve to improve the productivity of an individual employee, so seat-based pricing may still be practical here and likely converge to higher price points per seat than we see today as 1) they will offer far more utility than they do today and 2) likely have to monetize on a small employee base as companies will require less humans than today to deliver a unit of x for their role as they become far more productive. The pricing will be challenging to justify when a company can build its own Private Boss assistant depending on how the Private Assistant/Workers building platforms charge their customers.
The Helper assistants will likely price and package either on a seat-based approach (i.e., a portion of what the Boss seat charges) or on a consumption-based approach - i.e., how many times the Boss agent needs to use the Helper assistant. It is logical to assume, unlike the Boss assistant market, that you will see a more fragmented market here in that there is no inherent loyalty from the Boss assistant to the Helper assistant - i.e., they could decide to replace one vendor here with another if they can “do more for less” - similar to how coldly rational management teams theoretically treat employees. If you play in this Helper market, you will want to fight to wipe out the alternatives as you do not control your solution's value/pricing fate with the end customer. Similarly, you likely want to be a helper to many different types of functional boss assistants as there will be consolidation of the boss assistants in any one functional user target set, and your likely exit is to these boss assistants. While good companies can be built here, few will be venture-scale opportunities.
For Conductor assistants, similar to the workflow/integration market today, nothing inherently prevents multiple players/winners, with the caveat that I believe it will be tough to compete as a stand-alone conductor assistant provider versus those software companies that also provide agent and assistant building capabilities.
The Digital Workers - The Roles
These components are not that different from those in the Digital Assistant Market - the significant difference being that these digital workers are not sold/bought to assist individual employees at your company - they exist to be somewhat autonomous (with humans training them) and replace a whole chunk of work that humans did before or entire roles previously done by an employee. Using age-old terminology, where an Assistant becomes analogous with application software, a Worker is now akin to automation.
The Public Worker: These are digital workers provided by an independent software company.
The Private Worker: These are digital workers that an organization builds themself using a worker-building platform
The Helper Worker: These digital workers work for the Public or Private Workers to make them more effective at their tasks.
The Conductor: These are digital workers that an organization uses to coordinate how Public or Private Workers work with their Helpers and how all of the Digital Workers work together with their human employee counterparts to achieve the desired outputs and end goals.
The Digital Workers - The Market Dynamics
This market will likely have fewer outright winners, especially for those companies vying to provide the best Public workers to companies. Why? Organizations, just as they do with employees, will likely hire and fire these workers more often than they swap software vendors if they can employ better workers who can do more for less. This assumes that there is easy portability of the coaching organizations that have done with one worker to a new one - i.e., prompt engineering stays with the organization. If, however, that training is not easily portable, I could see companies being far more reluctant with their workers who work 24x7, never complain, have no ego, and are now not just experts at their job but are experts at doing their job at your company. Is there a future world where an HR company/function emerges to help put digital workers on performance plans and fire them - and if they leave, do all of the other digital workers say goodbye to them on the all-company slack channel? Yikes.
Pricing and packaging are what will evolve the most as you no longer price software on an employee basis or as part of an IT / Software spend (where I argue the Assistant market is still funded from) - you are replacing payroll cost. You are likely funded from that expense savings. The challenge with the pricing here is that one Digital Worker can likely replace many human workers (think in-bound SDRs), so providers will need to figure out the suitable unit of metric to charge for this - either at some approximation of relative human alternative payroll cost savings or some type of piece work/job task completion consumption model.
For companies that offer Helper or Conductor Workers alone, the market dynamics will be similar to those of the Digital Assistant market with the exception that there may be many more Helper workers here in that a Digital Worker does not have the ‘limited context switching” constraint that an employee has and be be willing to use 100’s of Helpers to make themselves more effective. That being said, there is room for many players, and it will likely be hard for one to break out and dominate.
The most exciting space to watch here is which companies emerge to become a terrific platform for companies to 1) build their own assistants and workers and 2) manage/coordinate the assistants/workers they build and the ones they buy. I don’t foresee companies wanting to buy one platform for 1 and a separate one for 2 - winning companies in this space will have to offer both. There are dozens of companies emerging to do this, so it will be interesting to see if there is room for a few to break out. It’s unclear to me what defensible technical IP they are leveraging. Perhaps different vertical vendors will specialize in providing these platforms for companies in specific industries. I also won’t bet against the infra players like Databricks if you see how far up the stack their offerings are now and how thin the application layer becomes with an Agentic future.
4. Legacy, What Legacy
Incumbents have been Thrown a Lifeline
If you follow my logic, you will hopefully get that meta-data matters. Legacy vendors, especially ones with tons of “hard to use” capability, have loads of meta-data. If they recognize this moment like the Appfolio does as an existential one, they can essentially hide/throw away much of their clunky UX (i.e. the usability that sucks, which enables up-start start-ups to attack and replace them) with an agentic UX. Generative AI has thrown these long-in-the-tooth companies the lifeline of a century to become young and relevant again.
This, of course, requires these companies to not just react to the moment product-wise but to revisit much of their operating principles and be willing to cannibalize some of their old practices (pricing, contracting, etc), but these are companies worth multiple billions of dollars and they giving up their chair that easily - ie “those that come for the king best not miss”.
5. Go Vertical, Young Wo/man
The Best chance of being a Big Boss
In the battle to be the dominant player in Digital Assistants or, for that matter, Digital Workers, going vertical early is an easier path to durable commercial success. As vertical software is far more focused and specialized for a finite set of different functional users, it is far easier to solve your customer’s “jobs to be done”. For example, at an insurance company, you would prefer the best assistant for insurance agents over the best agent for generic salespeople. However, horizontal companies are not deaf to this. Large enough ones may now have the trick of offering vertical editions to their product (classic playbook for any large player) more easily with different assistants leveraging LMS tuned to their vertical flavor metadata. That being said, starting (i.e., sub $100M in revenue) as a broad horizontal play is much harder to execute as a founder than a vertical one.
6. M&A is Much Simpler
What Product Integration?
For the last 30 years, the worst news, if you are in R&D, is that “yay, we bought this company”. The groans come from the inevitable pains you know are coming regarding how best to integrate the acquired company’s product. You know that in less than 180 days, your company’s website and marketecture slides will show your solution stack, including this tremendous newly acquired company’s capability - whether that’s realistic or not. If you work at a PE-owned shop, you may not bother as companies rarely do the super hard work of making these products work together well. In the end, if this work is not done, your customers and their end users suffer from having to deal with two “integrated” products that work as if they were from two different companies.
In the old on-premise and early cloud days, when companies still had monolithic code bases and concepts like API-first and shared service architectures were just a glimmer in the architect’s eye, this work was painful. To make it work, you had to often re-write the acquired company’s code in your stack, which is the fastest path to seeing all your acquired engineers run out the door. It has improved technically at the database and infra layer over the last 10-15 years, but all the front-end work remains to ensure the customer and its end users have a seamless user experience. At a minimum, a good portion of your existing R&D team will put aside their roadmap for months to get this new product integrated “enough”.
In an agentic UX future - if the acquired company has API-first metadata and a clean enough ‘ETL retrievable” schema - what’s the work you need to do? It seems that you just train your existing agentic UX and the LLM you leverage to contextually understand the new metadata you acquired and how it works with your own. Voila - you could now have the product wholly integrated in weeks/months without pulling off a good portion of your existing R&D team to do this. I have not entirely processed what this means, but if I were in Product Equity right now (after I got over the concern that my existing companies if they don’t respond to the AI challenge quickly, may just not cover my debt load but go poof in the night), I would be pretty excited.
WHAT DOES THIS ALL MEAN - for Founders?
As founders, it means everything. Everything changes except for the same simple fact - to build an iconic company, you must offer something that is 5-10x better than the alternatives for a pain point many people value highly and want now. That doesn't change. However, as previously stated, all of the other important stuff does and has already changed:
What you specifically build and the value it offers
The competitive dynamics of your market
The people you hire and what they must do
How much & when you spend your money
It’s impossible to codify everything you must do into one readable document, but here are the top things I hope founders process and start implementing now.
1. AI is Not Optional - It is an Extinction Level Event.
If you are an existing application software company, you must become a new company tonight. To not do so means you should fold up shop. That sounds harsh, but you either redirect your thinking toward this new reality now or will surely perish as a valuable entity. Trust me, I still meet founders (including some we have invested in) who tell me that AI is faddish and “it’s not something their users are asking for.” Others say they will get to it after they build all of this capability in the old-fashioned way, i.e., more screens, tabs, views, etc. When I hear this, it takes all my restraint to swallow my initial words - which is a less nice expression than “good googly moogly” and do my best to lead them towards a different perspective while maintaining the relationship.
Fortunately, once you make that mental switch, the legwork to make significant headway is easier than you think, especially if your underlying architecture isn’t junk and you already solve for a necessary broad enough business process (i.e., you have a lot of metadata). If you buy into an agentic future UX, you can build more “features” much faster than you thought (features = more questions you can answer and more actions you can do for your target user). Just follow the Appfolio approach and leverage the right blend of a clean API-first & ETL-friendly schema, a dash of RAG, your LLM of choice, and a whole bunch of coaching. If you want, get fancy and build a framework that leverages the best LLM for a given set of tasks to future-proof yourself around rapid advancements amongst the LLMs.
2. “Jobs to be Done” is King - Deep Customer Insight is the New Right to Play
Many good product leaders and managers know the Jobs to Be Done framework. It is not dissimilar from my high-level guidance to product leaders on thinking through their roadmap, although I spice ours with some adverbs to address differentiation. When leveraged correctly, even for companies with the same outdated List View / Form View / Tab View UX model, product teams are more likely than others to at least allow their users to complete the task they set out to do (or in product parlance, a “complete steel thread) simpler than non-adherents of JTDB.
To win as a provider of AI Assistants or AI Workers, the right to play - i.e., the right to be even considered for evaluation by customers - is your deep insight into your target customer’s end users JTDB. You have to know these far better than before and deliver against this insight better and faster than your competition. Usability testing will change forever tomorrow. No longer are you putting together figma screens and prototypes that tie together a set of screens and functions and ask customers if these have utility (have enough value for a user to use them) and are usable (simple enough for a user to navigate and use unassisted)? You are no longer testing the usability of your application, but you will now be testing your agentic interface's ability to do the jobs your users want done. If you understand those, you likely spend 75% internally testing your new Agentic ux before deploying in beta to end users.
If deep customer insight is your right to play, what is your right to win? In the long term, it is likely a combination of how many JTBDs you solve for better than others (the customer love moat), go-to-market prowess, and picking your appropriate product/value path.
3. Pick Your Path Now - Which Assistant or Worker Are You?
If the go-forward market plays out as I have suggested for application software companies, as a founder, you should identify which Agent(s) you plan to be.
Let’s say you are in the Assistant market. If you can be a Boss Assistant, go be a Boss. The license to participate here is that your product/offering has or will have a significant enough amount of metadata that represents substantial enough of a functional user’s workflow for them to look to you as their primary assistant. For companies where this is true, go hard and do what Appfolio did.
Everyone would love to be the Boss Assistant, but, sorry, very few get to win that game, especially if there are large incumbents that aren’t hated by the functional user set you target.
For example, in sales tech, do I believe account execs and their managers will use the 7-10 tools they do today? Of course not. They will gravitate quickly towards an agentic UX from one of the big players like Gong, Clari, Outreach, Salesforce, etc. As that happens, all of the other adjacent sales tech players in micro categories who are now furiously building their own agentic interface should recognize that while that’s the right short-term strategy, they have to know they will not be the boss assistant eventually - that’s a sucker's bet.
Therefore, if it’s clear you will not be a boss assistant, give up that battle and fight now to be the best helper assistant(s) for those bosses. Using the sales tech example, the adjacent sales tech players should double down on what a partnership integration looks like with those major players - which is all about passing the appropriate context of your metadata to their agentic UXs so that the boss assistant can answer the questions/do the tasks your offering can do today that theirs can not. Then you go to every one of the boss assistants' customers and show them how you are better than anyone else at making that boss assistant more competent and more helpful. The bonus for the customer is that there is no long deployment or user training. They can, faster than expected, just tell their users that the Boss assistant they have been using has been upgraded and now can do new amazing things.
Finally, if you are choosing to play/win in the Boss and/or Helper assistant market, you must have relevant metadata. If you do not, go get some or exit/pivot now—the battle is not going to be worth the fight.
4. Playbook. What Playbook - Throw out Most SAAS advice
Despite the existential musings already expressed, this is a more exciting time than ever for a founder. Unlike those who came before you, you have the opportunity to build something far more impactful to users and companies. Additionally, you can enjoy the building and running of your company far more as you can leave behind so many of the prior unfun components - many that were a by-product of the previous “hunt and peck” user interface product offerings and how much friction that created in the entire machine that you had to overcome.
You will need to think differently about most aspects of your business because reading the SaaS OG blogs on how you build, market, sell, and serve ain’t gonna help you much. My guidance to founders (and my founder screen on new investments) is that you can not be set in your ways. In a period like this of generational transformation and innovation, we are all building a new operational model. You and your team will have to grind hard, without preconceived notions, running, essentially, experiments from a first principles perspective and then “juking and jiving” every several weeks to double down on what works and quickly discard what does not. Here are some quick examples of where to think differently from traditional SaaS:
Think differently about the prospect product evaluation process: In a world where a prospect can quickly experience in your agentic user interface the questions that you answer and the tasks that you will perform for a functional user, what changes? With that transparency, surely there is room for transformation in the customer acquisition process of today? Are MQLs relevant anymore? What’s the role of an SDR? What does an SE do now as we are not trying to show a perfect path through our tabs and screens to show a prospect how we solve their pains? What can I now expect my account executive to do? Can I hold them to much higher standards?
Think differently about your product strategy and the role of R&D: In a very thin but insightful and helpful UX layer, software companies are no longer assembling canonical scrum teams to design, build, and test an endless number of screen pages (ie, what we used to call functionality). What, then, is the Product & R&D team doing? If JTBD is core to success, how do you ensure your product teams know/deliver on this better than the competition? Do you still think of developers as front-end, back-end, and full-stack developers? What is the definition of front-end in this new world anyway? Are agile and scrum still as relevant going forward as they have been for the SaaS world? What is the right blend of intentional product strategy versus iterative - in such a time of rapid AF technology changes, how do I drive my teams to, as some of our Bonfire founders have been doing, find minor miracles every few weeks that have huge implications to the value you can deliver to your customers?
Think differently about customer deployment and onboarding: What does deployment look like in the world of agentic UX first products? What customization is required at a given customer deployment? What are training, product documentation, and tooltips in a world where the product just does what a user tells it to do? What is support? In the past, users reached out because they didn’t know how to do something and/or something did not work as they wanted. What is the new definition of a bug - ie, your agent couldn’t give the user a helpful response? We need to completely redefine what deployment and support means in this new world.
Think differently about customer/product retention & expansion: If you are pursuing the Boss or Helper Assistant route, you need to rethink customer retention & expansion. If your offering is pretty good, you do not need what you are spending today on customer success managers to drive product adoption, and you surely don’t need as many account managers trying to upsell new modules. What we are seeing in our AI-centric portfolio companies is that customers are coming back quickly to our founders and asking them if they can do “this or that,” which reflects what in the past we would have thought as either incremental product features they expected our product to do OR capabilities they were buying from adjacent vendors. Guess what? It is much, much easier for you to offer than it has been in the past (what screen do you need to build - not many), which becomes a real doozy for founders to wrestle through the traditional advice of “stay focused” vs. “let’s go get that now”.
Think differently about when you need money and how much: All of the traditional financial metrics associated with start-up momentum - i.e., the magic number, the cash burn multiple, T3D2 - are all relics of the conventional SAAS industry over the last decade plus. Those are helpful but are likely not the right metrics to measure your progress going forward in this new Agentic UX software market. If we just look at the few “think different” examples provided above, it is clear that founders should be able to be far more efficient as there were whole swaths of running a SaaS business that required tons of resources to deal with the fundamental inefficiencies of a broken user interface model. In the go-forward model, you don’t have to do that anymore. Exciting.
5. Master What is Consuming You - Be the Best User of Assistants & Workers Internally
AI should be as revolutionary for running your software company as it is for your customers who buy your products. Aside from all the changes in how you run a company (see above), you should be the best example of leveraging AI assistants and agents across your business to
1) understand much quicker what is working, what’s not, and what to focus on
2) maximize the returns of the highly dilutive cash you do raise
3) scale much faster as a leader, as your company can only grow as fast as you can
4) potentially attack markets in manners that would have previously been unthinkable
As an example, here is a mind-blowing demo we recently experienced (at least to me, given all my value-add as a prior executive just disappeared) from an agent-building platform:
Build a customer success agent connected to all your relevant customer interaction data streams (ie, success team slack groups, support ticket systems, pendo, Gainsight, etc.). That agent is trained to identify, for example, the ten most significant issues with the product from a customer success perspective. Somewhat helpful.
Build a product agent connected to your relevant product roadmap/release data (e.g., pendo, Jira, Aha, Slack groups, etc.). That agent is trained to identify, for example, the likely product capabilities that will be released on time over the next six months. This is somewhat helpful.
Here comes the magic, however. Build a meeting agent who meets with your customer success and your product agent weekly and train it to identify the biggest disconnects between what your customers are asking for and what your product teams are releasing. That agent is fearless and is immune from the politics of even daring to attempt to answer such a question.
Holy cow. That saves a founder so much time, confusion, and drama. Now imagine that the founder did the same for marketing and sales—you just saved months of being pulled into meetings about WTF is an MQL, why aren’t salespeople following up, etc. As a founder now, in a very short time, I can have a very accurate pulse on my business and how to drive alignment across all of my functions - without all of the politics and personal drama with execs to work through - as my AI agent will just tell me what’s what. My functional execs will have those same agents and, if they are smart, will just go address those disconnects before I go look at what it tells me. Nirvana.
This now sets the perfect segue for the rest of our study, which is about how founders and teams at b2b software companies should best leverage AI across their organization to build and run their companies more effectively.
Brett, my head is spinning... I need an AI Assistant/Agent to tell me what everything you just described, means. I enjoyed reading your article, it describes a marketplace I have not experienced yet, but can extrapolate what it might look like sooner than later.
I'm with you on the return of build. With LLMs, it’s more like “use” than “build”. Building is scary. Using LLMs is far less scary, and even more powerful. I think people are still underestimating how much easier and cheaper it is to create in-house tools using LLMs than it was to build software applications.