In the first part of this series, we introduced the Harvest Framework - a methodology for capturing the innovation already bubbling up across your organisation. Now let's dig into the first and arguably most critical step: identification.
In case you've missed the first part you can find it here
The hardest thing about identifying problems is resisting the urge to solve them immediately. We're conditioned to be helpful, to demonstrate value, to show we're clever. But the moment you attach a solution to a problem, you've narrowed the field of who can contribute.
When someone says "we need a dashboard that shows X," they've already solutionised. The actual problem might be "I don't know if our campaigns are working" or "I spend three hours every Monday morning pulling numbers for my boss." These are fundamentally different problems that could yield radically different solutions from different people across the organisation.
Problems worth harvesting tend to cluster in predictable places:
The Spreadsheet Graveyards. If someone has built an elaborate Excel model that takes an hour to update every week, that's a problem screaming to be identified. These spreadsheets are often the most honest documentation of actual business processes which is far more accurate than whatever's written in the official process documentation.
The Apology Emails. "Sorry this took so long" or "Apologies for the delay" in internal communications are breadcrumbs leading to friction. Someone is consistently blocked by something, and they've normalised it.
The Workarounds. When people say "oh, we just do it this way because the system doesn't let us," then there's gold in them there hills! They've already identified a gap between what they need and what they have.
The Meeting That Could Have Been an Email (But Couldn't). Recurring meetings that exist purely to synchronise information between systems or teams point to integration problems that are often perfect candidates for automation.
Ask team members to spend one week noting any moment they feel friction - where they're waiting, copying, pasting, reformatting, or switching contexts. No judgment, no solutions, just observations. You'll be surprised how much surfaces.
Have someone outside a team shadow the work and ask naive questions. "Why do you have to do that step?" often reveals processes that exist purely because they've always existed.
For any decision that requires approval or information from elsewhere, calculate the actual wait time. If a simple data request takes three days because someone has to manually pull a report, that's a quantifiable problem.
Ask people what tools they actually use daily versus what's officially sanctioned. The gap between these lists is fertile ground for problem identification. If someone's using a personal Notion account to track work because the official system is too clunky, that's a signal.
When you've identified a problem worth exploring, document it in a way that invites contribution rather than directing it:
Bad: "We need to build a Python script that automatically pulls data from Salesforce and formats it for the weekly report."
Good: "The sales team spends approximately 4 hours every Monday morning manually compiling data from multiple sources for the weekly leadership report. This delays other work and introduces potential for human error."
The second framing allows the junior marketing coordinator to suggest "what if we just changed what leadership actually needs?" just as validly as the senior engineer proposing an API integration. Both are legitimate responses to the problem as stated.
For each identified problem worth pursuing through the Harvest Framework, capture:
Crucially, leave the "how" completely blank. That's for the Enable stage.
Not every problem is worth running through the full framework. Good candidates typically share these characteristics:
Repeated friction - something that happens regularly, not a one-off annoyance.
Broad impact - affects multiple people or touches multiple processes.
Clear boundaries - you can reasonably define when it starts and ends.
Non-critical path - at least initially, it shouldn't be something where failure causes significant harm. Patient data and financial transactions can wait until your harvesting muscles are stronger.
Measurable improvement - you'll be able to tell if it's better afterwards.
The best problems often come from the people closest to the work - the ones who've been dismissed before when they suggested improvements. Creating genuine psychological safety for problem identification means actually listening when the person who processes invoices tells you the system is broken, even if you've been told by IT that the system is fine.
It also means being honest about problems that implicate existing investments. If a team spent two years building an internal tool that everyone hates, that's still a valid problem to identify. Sunk cost shouldn't protect bad solutions from scrutiny.
In the next installment, we'll explore how to open the solution space to everyone in the organisation, from the CEO's "what if we just..." to the intern's fresh perspective, all enabled by AI tools that make prototyping accessible to anyone willing to try.
Want help identifying the problems hiding in plain sight across your organisation? Get in touch.