AI Curiosity Beats Technical Ability

*Part 1 of 6 in a series on the habits that make AI useful. Next: [AI Problem Definition: If You Can't Explain the Problem, AI Can't Solve It](/insights/ai-problem-definition-explain-the-problem/).* There is a person in most businesses who seems to have taken to AI immediately. They turn up to a meeting with a first draft of something that used to take a fortnight, and everyone assumes they must be technical. They usually are not. What they have is AI curiosity. Usually they are not. In the SMEs I work with, the person getting the most out of AI is as likely to be an office manager as a developer. What they have in common is not a background in software. It is a habit: they poke at things. That distinction matters, because if you believe capability with AI is a technical trait, you will hire for it, wait for it, or conclude your team hasn't got it. None of those get you anywhere. If you believe it is a habit, you can build it. ## AI doesn't behave like the software you're used to Traditional business software has edges you can see. There is a menu, a set of features, a right way to do things and a support article when there isn't. You learn where the buttons are and then you know the tool. AI doesn't work like that. What it can do depends heavily on what you ask it to do and how you work with it. Two people using the same subscription get wildly different value out of it, which almost never happens with an accounting package. The practical consequence: there often isn't a button labelled with the thing you want. If you are waiting to find one, you will conclude the tool can't do it and move on. The person who gets value simply describes what they want and sees what comes back. ## Curiosity changes the question you ask Listen to how people talk about AI and you'll hear two very different questions. The first is *"Can ChatGPT do this?"* It is a closed question. It has a yes or no answer, and a no ends the conversation. The second is *"How could AI help me get this done?"* It is open. It admits several routes: maybe AI drafts it, maybe it checks it, maybe it summarises the inputs so a person can decide faster, maybe it does nothing useful here and that's worth knowing too. The second question is not a clever prompt. It is a way of framing the problem that leaves room for an answer you hadn't thought of. ## The first answer is rarely the final answer People who are good with AI treat the first response as a starting position, not a verdict. They push back. They say *that's too generic, here's an example of what good looks like*. They paste in the real context they left out the first time. They ask it to suggest three different approaches before choosing one. The loop is unglamorous and it works: - try the task - see what came back - identify what's missing or wrong - work out why - change the approach - try again Most people who have written AI off stopped at step two. They asked once, got something bland, and filed the whole category under "overhyped". That is a reasonable conclusion from a single data point and a poor one from five. ## What was true six months ago may not be true now This one catches out the confident more than the sceptical. Someone tries a task in the spring, hits a genuine limitation, and stores the conclusion: *AI can't read our scanned invoices, can't handle long documents, can't be trusted with numbers.* Six months later, some of those are no longer true. The conclusion, though, has hardened into policy. Nobody re-tests it because nobody remembers it was a test. It is worth keeping a short, honest list of things you tried that didn't work, with the date. Revisit it twice a year. Half of it will still be right. The other half is opportunity you have already scoped. ## Curiosity is a business skill, not an AI skill None of this is really about AI. Businesses that investigate their own processes, question why a report exists, and ask whether a step still earns its place were better run before any of this arrived. AI just makes the gap more visible, and pays it back faster. That's also why AI adoption tends to stall in businesses where "this is how we've always done it" is the default answer. The technology isn't the constraint. The willingness to look at the work is. ## A curiosity habit you can start this week Pick one task you do every week that you find tedious. Not the biggest problem in the business — the small, repetitive, slightly annoying one. A weekly report, a set of similar emails, tidying data from a form, writing up meeting notes. Give yourself half an hour. Not to solve it, but to investigate whether any part of it could be done differently. Describe the task properly, including what a good result looks like. See what comes back. Note what worked and what didn't. Do that most weeks for a couple of months and you will have tested twenty real tasks in your own business. That is a far better position than anyone who has watched twenty videos about it. If you want a structured version of the same exercise, our [AI Readiness Assessment](/services/ai-readiness-assessment/) does it across a whole business rather than one desk, and the [AI Essentials workshop](/workshops/ai-essentials/) runs the habit with a team using their own work. ## The dividing line The people who become capable with AI quickly are rarely the ones who understood it best at the start. They are the ones who were willing to be a bit rubbish at it in public for a few weeks. That is not a technical trait. It is a decision, and one you can make on behalf of your team by making it safe to experiment — which is where this series ends up. ## FAQs ### Do I need technical skills to use AI effectively? No. You need to be able to describe what you want clearly and judge whether what comes back is any good. Domain knowledge — knowing your customers, your process, what a good result looks like — matters far more than knowing how the technology works. ### What should I experiment with first? Something small, repetitive and low-risk that you personally do often. Meeting notes, first drafts, summarising long documents, tidying up data from forms. Start where you can judge the quality of the output yourself, because you'll learn faster. ### How do I know whether an AI tool can actually do something? Try it with a real example rather than a hypothetical one, and try it three or four times with better context each time. Vendor claims and single tests both mislead. Your own work is the only reliable test. ### Should I keep trying if AI gives a poor answer? Usually, yes — but change something each time. Add context, give an example of what good looks like, narrow the task. If three genuine attempts with better inputs still produce nothing useful, that's a real answer, and worth writing down. ### How much time should I spend experimenting with AI? Twenty to thirty minutes a week on one real task is enough to build the habit. Blocked-out, protected time beats good intentions. The businesses that go nowhere are usually the ones where experimentation happens only when things are quiet, which is never. ### Can experimenting with AI create business or security risks? It can, which is why experimentation needs boundaries rather than bans. Set out what information can't be pasted into public tools, which tools are approved, and which decisions always need a human sign-off. Within those lines, encourage people to try things. See our guide to [using AI without putting your business at risk](/insights/using-ai-without-putting-your-business-at-risk/).

This article was written by Peter Lowe. The ideas and opinions are his own; AI was used to assist with drafting and editing.