AI is the modern gold rush – media hype and venture capital ($3.9 billion was invested in Q3 alone) has created a frantic race to be the first to develop an AI-driven competitive advantage.
This is both the right and the wrong mindset for building AI products. If you’re too bullish on AI’s capabilities, you’re likely to choose novel AI applications with zero ROI. However, if you move too slowly, you risk building something that’s obsolete before it’s even launched.
To find the right balance, we sat down with Edmundo Ortega. Ed is our former Head of Product at Section and now leads Machine & Partners, an AI consultancy that helps organizations prototype and validate AI experiences. They’re currently working with a range of clients, from an international media company to a policy think-tank. They’re also helping us build AI applications at Section.
So here’s Ed’s framework to help leaders choose the right AI applications to build.
The common pitfalls of building AI products
Even though it’s not perfect, AI is no longer an experimental technology. “AI is overhyped,” Ed says, “but it’s also going to fundamentally change how products are built and delivered.”
Companies that can leverage AI correctly will see productivity gains, cost efficiencies, and new capabilities that traditional technologies can’t deliver. Yet to get these advantages, they need an approach that avoids building “cool tricks” and focuses on delivering business outcomes. Ed typically sees two main dilemmas when working with clients on AI initiatives.
- A misalignment with business goals: Many organizations feel pressure to invest in AI simply because it’s trendy, without aligning their projects to core business needs. This approach often results in six-month projects that cost hundreds of thousands of dollars, only for management to realize these tools don’t solve any real business challenges.
- The wrong people are leading them: AI projects are too often led by a technical team without sufficient input from business stakeholders. Even if an engineering team will build an AI application, AI projects aren’t tech initiatives – they’re business initiatives. AI development needs to be led by executives and business leaders who understand the company’s strategic goals.
Identifying high value AI use cases
A lot of people think AI can do anything – but successful AI applications rely on having the right inputs.
To help clients identify where AI can generate real business value, Ed developed the D.E.W. framework. For any potential AI initiative, Ed and team evaluate three things: Data, expertise, and workflows.
- Data: Does the company have the right data in hand to support an AI initiative? For example, if you want to build an AI application that generates product recommendations for consumers but you’re not storing past order history, you have nothing to go on.
- Expertise: AI projects often rely on domain expertise that lives in the heads of certain employees. This expertise is critical to train the AI on the context and nuances of the business problem. If you want to build an AI tool to take over a process, but no one has a clear understanding of the process, AI won’t be able to help.
- Workflows: High value AI use cases, integrate into existing workflows. Any definable workflow, especially dreary ones, are an opportunity for AI.
Here’s an example. Ed and team are currently working with a client that spends lots of time and money to extract information from complex SEC documents. This use case is ripe for AI, not only because it requires extracting information from text documents. In addition:
- The company had access to lots of these documents and examples of information that was extracted from these documents by humans
- The internal team had deep expertise in understanding and extracting financial information from the documents and had that information documented.
- The workflow for processing these documents was clear and repeatable
On the other hand, Ed and the team had another prospect ask them to build an app that could build AI-generated pitch decks. But once the team dug in, they realized a few limiting factors:
- The source data for the pitch decks was derived from unstructured call transcripts and notes, making it in unreplicable source
- The sales team knew how to engage clients and what content resonated, but hadn’t documented this process in a structured way, making it tough to train AI on the process to create a deck
- The process for creating a pitch deck varied by the person who created it
Successful AI projects include all three components (data, expertise, and workflows). When evaluating use cases, run them through the D.E.W. framework.
Picking the most high opportunity AI product
Once you’ve vetted some use cases through D.E.W., the next step is to prioritize them. This is where Ed’s V.V.V. Framework comes in: evaluating use cases for viability, value, and velocity.
- Viability: How feasible is this project? Think about this through the lens of resources, technical capacity, and any potential regulatory issues. For example, Ed cited a financial services company with stringent regulations around client data. Even though they had the technical capability to build an AI tool, regulatory hurdles made the project non-viable.
- Value: What’s the ROI for this project? Value isn’t just about cost savings—it’s also about how much impact the project will have on strategic goals. For instance, in the SEC filing example above, automating document-parsing saved the company hundreds of hours of labor, making it a high-value project. By contrast, automating a sales deck that takes a couple hours here has less clear ROI relative to the cost of development.
- Velocity: How quickly can the project be built? AI is changing rapidly, and projects with long timelines risk becoming irrelevant before they’re finished. “It’s not just about how long it will take to build—what’s going to happen in three months or six months?” Ed asked. “By the time you’re done, the entire landscape might have shifted.”
By the end of this exercise, hopefully you’ll have whittled your list of use cases down to one or two AI products that you know you can do and are worth doing.
“Just because something’s cool doesn’t mean it’s valuable,” Ed emphasized. “Run the numbers first.”
Final advice
To get the most out of AI, companies need to build thoughtfully, align projects to business objectives, and use frameworks like D.E.W. and V.V.V. to identify high-impact initiatives.
As Ed put it, “The danger of moving too fast based on hype is you end up building a toy that doesn’t deliver value. But moving too slowly means you’ll end up building something that’s already out of date.”
Here are Ed’s top tips for anyone looking to build AI products:
- Involve subject matter experts (SME) at every stage: AI development isn’t purely technical—it’s deeply tied to business needs and nuances. Unlike previous software development products where an SME could be consulted at just the beginning and end of development, every step of AI development needs to be informed by someone who is deeply knowledgeable about what the end experience should look like and what good output looks like. Engineers alone can’t be evaluating the quality of AI’s output. “If you’re missing the right subject matter experts at every stage, you’re just building in a vacuum,” says Ed.
- Prepare for a new way of working: Traditional software development practices don’t apply to AI. Because AI’s output can change every time, it’s much more difficult to determine if a solution is working or not. Sourcing and recreating “bugs” is also significantly more difficult. This requires tech teams to work more collaboratively with business ops and release incremental half-baked versions of the tool to allow for nuanced testing. "Product people don’t like it, designers don’t like it, and developers don’t like [working this way]," Ed said, “but teams need to adapt fast.”
- Focus on small, incremental wins: Start by building simple, impactful AI solutions rather than attempting large-scale projects immediately. If you have a large-scale idea, break it down into smaller components you can test. This gives you a low stakes chance to learn and iterate, and gives you a better chance of avoiding wasted work when you do take on bigger initiatives.