Stop Buying AI Tools. Start Solving Problems.

About this session

AI is no longer just a technology discussion. It is a workflow, content, and operating model shift. As adoption accelerates, many organizations rush to implement new platforms before defining the real problem. The result is often overlapping tools, underused software, scattered experiments, and teams struggling to turn AI interest into measurable business value. This Lunch & Learn will explore a more practical path forward: starting with the challenge, not the tool. We'll discuss why successful AI adoption depends on improving workflows, asking better questions, and identifying the use cases where AI can create real leverage. We'll also explore the role of the solution architect: the strategic partner who helps translate business challenges into the right combination of tools, workflows, and execution plans. The real competitive advantage is not access to AI itself, everyone has that. The advantage is knowing what problem to solve and how to design a system that helps teams move faster, produce more, and work smarter without adding unnecessary complexity. Attendees will leave with a sharper way to evaluate AI opportunities, pressure test use cases, and think about AI as a practical business solution rather than a collection of disconnected tools.

Session recap

The real AI problem most organizations have

The most common AI mistake in 2026 is not choosing the wrong tool. It is choosing a tool before defining the problem. Across industries, organizations are accumulating AI platforms at pace — overlapping subscriptions, underused software, scattered experiments — while teams struggle to translate AI interest into measurable business impact. The June Lunch & Learn addressed this directly: sustainable AI adoption starts with the challenge, not the tool.

Why the tool-first approach fails

Tool-first AI adoption produces a predictable set of failure modes. Teams evaluate platforms based on feature lists and demo quality rather than fit with actual workflows. Pilots launch without clear definitions of success. Multiple tools get implemented for the same use case because no one mapped the existing process before adding to it. And because the question of "what problem are we solving?" was never answered cleanly, it becomes nearly impossible to evaluate whether AI is working.

The result is not just wasted spend — it is organizational skepticism. When AI investments don't produce visible results, teams lose confidence in the category, leaders pull back investment, and the organizations that could benefit most from thoughtful adoption fall further behind the ones that did the foundational work first.

Start with the workflow, not the wishlist

The session introduced a practical starting framework. Before evaluating any AI tool, teams should be able to answer four questions about the workflow they intend to improve:

What is the specific bottleneck? Slow turnaround, inconsistent quality, insufficient volume, or high cost-per-output are all different problems requiring different interventions. AI is not a single solution to all four.

Who owns the output? AI-assisted workflows that lack clear human ownership at the review and judgment stage produce outputs that no one fully stands behind. Defining ownership before automating a step is more important than the automation itself.

What does "better" look like, and how will we measure it? Without a defined baseline and success metric, it is impossible to know whether AI improved the workflow or simply changed it. The measurement framework should exist before the tool is deployed.

What are we not willing to automate? Strategic decisions, client-facing judgment calls, and accountability-bearing choices require human ownership regardless of what AI can technically produce. Drawing that line explicitly, before the tool is live, prevents the gradual drift toward over-automation that erodes quality and accountability.

The role of the solution architect

One of the session's central concepts was the solution architect — a strategic function that helps organizations translate business challenges into the right combination of tools, workflows, and execution plans. This is distinct from a technical AI implementation role. The solution architect's job is not to evaluate which model is most capable. It is to understand where a team or organization is losing time, producing inconsistency, or operating at a scale that doesn't match demand — and then design a system that addresses the actual problem.

Practical use-case evaluation

The session offered a straightforward test for evaluating AI use cases before committing resources. A use case is worth piloting when it meets three criteria: the problem is clearly defined, the output quality can be evaluated by a human reviewer, and the time or cost savings are legible enough to measure against a baseline. Use cases that fail any of these criteria are not ready for AI investment — they are candidates for process clarity first.

The session also distinguished between high-leverage and low-leverage AI applications. High-leverage: analysis and pattern recognition on large data sets, iteration on structured content formats, research synthesis, first-draft production for high-volume outputs. Low-leverage or premature: replacing judgment-intensive decisions, automating client-facing communications without review, using generative tools for outputs where brand consistency is non-negotiable without a quality control layer.

The actual competitive advantage

Access to AI is no longer a differentiator — every organization has it. The advantage belongs to the organizations that know what problem they are solving, have designed systems that deploy AI where it creates real leverage, and have preserved clear human ownership where it matters most. That combination — problem clarity, system design, and role definition — is what separates the organizations that are quietly building capability from the ones still evaluating their third project management AI add-on.

The takeaway from the June session: stop auditing tools and start auditing workflows. The right AI implementation almost always follows from understanding the work, not from understanding the software.