Start With the Problem, Not the Tool
- 3 hours ago
- 6 min read
How to identify your firm’s biggest pain points before touching any AI software
There’s a pattern I see over and over again when working with accounting firms that are trying to adopt AI. Someone reads an article, attends a webinar, or hears a competitor mention a tool. Within a few weeks, there’s a new subscription. Within a few months, nobody is using it.
The problem isn’t the tool. The problem is the order of operations.
Accounting firms — like most professional service firms — tend to be driven by whatever is generating the most buzz. Right now, that’s AI. When something is buzzy, the instinct is to jump straight to the solution before you’ve clearly defined the problem. You end up shopping for answers before you know the question.
Starting with the problem sounds obvious. But doing it properly is more structured than most firms realize. It actually means doing three things in the right order: building a vendor strategy, running a real requirements gathering process, and developing a technical roadmap. None of these are glamorous. All of them are what separates firms that get lasting value from AI from firms that collect expensive, underused subscriptions.
Let’s walk through each one.
Step 1: Build Your Vendor Strategy Before You Evaluate Anything
Most firms skip this step entirely. They jump straight to “what tools should we look at?” without first establishing what kind of vendors they’re willing to work with at all.
A vendor strategy is your firm’s set of standards for any technology partner — AI or otherwise. It answers the question: what does a vendor need to look like before we even consider them? Getting this right up front saves enormous time and prevents you from falling in love with a tool that doesn’t meet your firm’s actual requirements.
Here are the dimensions your vendor strategy should define:
Security and Compliance Standards
Accounting firms handle sensitive client financial data. Before any vendor touches that data, you need to know what certifications and security standards they meet. SOC 2 Type II is a baseline. Depending on your client base, you may need HIPAA compliance, IRS Publication 4557 alignment, or other standards. Define these requirements before you open a single demo.
Company Fit and Stability
Not every vendor is the right size or stage for your firm. A 5-person accounting practice probably doesn’t need — or want — an enterprise platform built for the Big Four. And a 30-person firm probably can’t afford to be a product guinea pig for a 6-month-old startup. Consider the vendor’s size, years in operation, financial stability, and client base. Are their existing customers firms like yours?
Values and Association
This one gets overlooked. Some firms have strong preferences about the companies they do business with — whether that’s geographic considerations, industry associations, political stances, or simply a sense of cultural alignment. These are legitimate criteria. Define them as part of your vendor strategy so they don’t become awkward surprises late in the evaluation process.
Support and Partnership Model
How does the vendor support their customers? Is there a dedicated account manager or just a help center? Do they offer on-boarding assistance or training? For smaller firms without dedicated IT staff, this matters enormously. A great tool with poor support will fail at adoption every time.
✓ Vendor Strategy Checklist
Before evaluating any AI tool, your firm should be able to answer:
• What security certifications are non-negotiable for us?
• What size and maturity of vendor do we prefer?
• Are there geographic, political, or values-based considerations?
• What level of support do we need to be successful?
• What does the vendor’s existing customer base look like?
Step 2: Run a Real Requirements Gathering Process
Once you know what kind of vendor you’re looking for, you can start defining what you actually need. This is requirements gathering — and most firms do it too narrowly.
The instinct is to identify the single biggest pain point and go find a tool that solves it. That’s a start, but it misses a lot. A proper requirements process captures the full picture: what you have today, what you wish you had, and how you’d prioritize it all.
Start With Your Current State
Before you can define what you need, you need to be honest about what you have. What tools are currently in your stack? What do they do well? What gaps have your team been working around? This isn’t just about the software — it’s about the processes those tools support. Sometimes what looks like a technology problem is actually a process problem that no tool will fix.
Capture the Full Feature Landscape
When evaluating a new tool or AI solution, most teams only think about the pain point that triggered the conversation. A better approach is to capture three categories of features:
Features you currently have and need to keep — don’t lose ground in the transition
Features you currently have but don’t actually use — these might not matter
Features you wish you had — the gap you’re trying to close
That third category is where AI often shines. But you can’t evaluate it honestly without knowing the first two.
Separate Must-Haves From Nice-to-Haves
Once you’ve captured the full feature list, force yourself to sort it. Must-haves are non-negotiable — a solution that doesn’t meet them isn’t a solution. Nice-to-haves are things that would add value but won’t disqualify a vendor that’s strong everywhere else.
This distinction matters more than most people think. When you’re deep in a vendor evaluation and a slick demo has the room excited, it’s easy to forget that a critical requirement isn’t being met. Having a written list keeps you honest.
Build a Review Committee for Larger Firms
For firms with five or more staff involved in the workflow being evaluated, a single decision-maker is rarely enough. Consider a small committee — two to four people who represent different perspectives: the person doing the daily work, the person responsible for client outcomes, and someone thinking about cost and risk.
The committee’s job isn’t to pick the tool. It’s to review and prioritize the requirements, evaluate solutions against a shared rubric, and approve the final recommendation. This process slows things down by a few weeks and saves months of cleanup from a bad decision.
Use an Evaluation Rubric
Once you have your requirements and your vendor shortlist, score each vendor against your criteria systematically. Weight the must-haves heavily. This isn’t about finding a winner — it’s about narrowing a field of options to one or two finalists using logic rather than excitement.
Step 3: Build a Technical Roadmap
A vendor strategy tells you who you’ll work with. Requirements gathering tells you what you need right now. A technical roadmap tells you where you’re going — and makes sure you’re building toward something, not just reacting to whatever comes next.
This is the piece most small and mid-sized accounting firms skip because it feels like something only large enterprises do. It isn’t. A roadmap doesn’t need to be a 50-page strategic document. It needs to be a living view of your firm’s technology direction over the next 12 to 18 months.
What a Technical Roadmap Includes
Your current technology stack and how each tool maps to a business function
Known gaps you’ve already identified through requirements gathering
Solutions you’re actively evaluating or planning to evaluate
Planned implementations with rough timelines
Tools or contracts coming up for renewal or replacement
Emerging capabilities you’re watching but not ready to act on yet
Keep It Rolling and Quarterly
The roadmap should be reviewed and updated every quarter. Not because everything changes every three months — but because the technology landscape in AI is moving fast enough that a plan you made six months ago may already need adjustment. A quarterly review forces the conversation: what’s changed, what’s working, and what needs to shift?
A rolling 12-to-18-month view is the right horizon. Short enough to be actionable, long enough to be strategic. If your roadmap only covers the next 90 days, you’re still reacting. If it covers five years, it’s fiction.
The Roadmap Keeps You Ahead
Here’s the real value of a technical roadmap: it changes your relationship with vendors. Instead of fielding cold calls and demos re-actively, you’re approaching the market with a clear sense of what you need and when. You’re not buying because something is exciting. You’re buying because it fits a defined slot in a defined plan.
That shift — from reactive to intentional — is exactly what separates firms that use AI well from firms that are still figuring out where to start.
Putting It All Together
Starting with the problem doesn’t mean asking “what hurts?” and then Googling for a tool. It means building the infrastructure to answer that question properly — and to keep answering it as your firm evolves.
The three steps in this article — vendor strategy, requirements gathering, and technical roadmap — are not a one-time exercise. They’re an ongoing discipline. Firms that build this discipline early find that AI adoption gets easier over time. Every new tool evaluation goes faster. Every decision is more defensible. Every dollar spent is better justified.
Firms that skip it keep wondering why nothing sticks.
Comments