The moment I got stuck on “I don’t know where to start”
The first time I wanted to turn a small idea into an AI tool, what really kept me up at night wasn’t the server or the code. It was: where exactly is the user supposed to click? I made a spreadsheet that broke “from signup to seeing results” into 17 steps and thought I was being thorough. Then a friend opened it, stopped at step three, and asked: “So, what do I do first?” That was when I realized: more features aren’t necessarily better. A shorter path is more useful. You don’t have to try this now—just keep the problem in mind.
What OpenAI means by giving users fewer detours
OpenAI’s “A thousand fewer paths to root” discusses the “root path” of an AI product: whether users must pass through too many choices, settings, and explanations before completing one valuable task. The article doesn’t present a standalone button-style product. It’s about product design that helps people move faster from input to result.
My colleague Lin Xiao is in Hangzhou building a tool for organizing client records. She combined the formerly separate steps—uploading a file, choosing a function, adjusting parameters, and exporting—into one entry point: “Turn this contract into a client table.” She told me that during a demo, clients asked “What does this do?” two fewer times, and the trial completion rate rose noticeably.
This matters especially to non-technical founders like us. We don’t need to learn every AI term first. I ask myself whether a user can get a result they can take with them within a minute or two of their first interaction.
Replicating this approach today costs very little
Money: ¥0 to start with an existing AI tool. Time: 30 minutes to map the current workflow and remove unnecessary intermediate steps. Technical barrier: No coding required, but you need to be willing to test with a real file. First step: Open the AI tool you already use, start a new conversation, and write two sentences: “The task I want to complete” and “The result I want to end up with.” If you sell knowledge-based services, for example, write: “Turn these scattered notes into a short, publishable article.” Ignore complex automation for now.
I’ve messed this up too. Early on, I wrote prompts like product manuals, assuming the more complete the wording, the better. Users didn’t have the patience to read them. Later, I asked a friend to follow the screen without explaining anything or clicking for them. The first place they got stuck was exactly where I needed to fix things. Not everyone needs this method; if you don’t have a tool workflow yet, keeping your current way of working is fine.
How I’d approach it at different stages
If I’m just starting: I’d build a “single-path version” of one specific task, such as turning a client question into a draft reply. The goal is to deliver today, not build a system.
If I already have 1-2 clients: I’d record one real usage session, keep only the most common entry point, and have the client try the new version. Then I’d ask: “Which step made you hesitate?”
If I’m scaling: I’d turn recurring steps into templates and automated workflows, while keeping one simple entry point at every launch and recording where users leave. This doesn’t make the product more complicated; it keeps the complexity in the background instead of putting it in the client’s way.
I could start today with one small change: remove one unnecessary choice, cut one block of instructions, and bring the user closer to their first result. Or I could wait, collect a few examples of real users’ hesitation, and then decide whether a change is worth making.