The feature that proves you are technically capable is often not the feature that helps a customer get started. If you want to reduce product friction, that is the tension to examine first.
That is a painful lesson because powerful products are satisfying to build. They give expert users control. They make a good demo. They feel flexible enough to handle every possible case. But when the target customer does not want to become an expert, flexibility can feel like homework.
An Indie Hackers founder described this problem with unusual clarity. Their AI product had spent years around $100–$150 per month in one-time sales. It used a node-based interface similar to tools built for technical visual workflows. The product was capable, but architects and designers kept signalling the same issue: the learning curve was too high.
The pivot was severe. The founder removed the node system, rebuilt the experience around chat, and introduced subscriptions. Six months later, they reported $8.6K in monthly recurring revenue.
One story does not prove that every product should become a chat interface. It does show a useful diagnostic: when users keep telling you that the path to value feels too hard, the highest-leverage product work may be removal, not addition.
The real problem was not a missing feature
When growth stalls, founders often look for the feature their product does not have. The more useful question is often: What does a new user need to understand before they can receive value?
For the AI startup in this case, the answer included a technical mental model. Users had to think in nodes, connections, and prompt-engineering choices. That might be reasonable for an experienced creator. It was a bad trade for a busy architect or designer who wanted a result, not a new discipline.
Every product has an implied learning tax. It may be hidden in:
- unfamiliar setup steps;
- terminology users do not naturally use;
- a blank canvas with too many choices;
- permissions and integrations required before a first result;
- a workflow that assumes technical confidence; or
- pricing that asks for commitment before value is clear.
The tax is not always obvious to the people who built the product. Founders already know where everything is. They can see the promise in the interface. A first-time customer sees decisions, risk, and the possibility of wasting an afternoon.
Your job is not to make the product look simpler. It is to make the first useful action genuinely easier.
Measure product friction before you redesign
“The onboarding feels hard” is too vague to guide a pivot. Turn the feeling into measurable behavior. For a defined new-user segment, track four simple indicators:
| Metric | What it reveals | Warning sign |
|---|---|---|
| Time to first value | How long it takes to reach the promised result | new users need a call before they can finish |
| First-session completion | Whether the initial path ends in a useful outcome | many accounts stop at the same step |
| Assisted-success rate | How often a human must intervene | support repeatedly completes the same setup |
| Return after first value | Whether the result was useful enough to continue | users finish once and never come back |
Use a small cohort rather than a giant dashboard. Watch ten new target users. Record where they stop, what they ask, and which work you silently complete for them. The point is not statistical certainty. It is to find the repeated tax before a more expensive redesign begins.
Time to value is particularly useful because it connects product and onboarding. A user who reaches a good result in fifteen minutes may tolerate an imperfect interface. A user who spends two hours configuring a tool before seeing anything useful may quit even if the product is powerful.
Questions that uncover friction in user interviews
Ask after a user has tried the product, not before. Avoid “Was that easy?” because people are polite. Instead ask:
- What did you expect to happen when you clicked that?
- Which part made you stop and think?
- What would you have done if nobody from our team was available?
- What information did you need but could not find?
- At what point did the product start to feel worth the effort?
The answers tell you whether the barrier is comprehension, trust, missing capability, or a genuinely wrong audience. Only the first two are reliably fixed by simplifying the interface.
First value is a product design problem
Many teams describe onboarding as a series of emails, tooltips, and progress bars. Those can help, but they cannot rescue a workflow that asks the user to make five complicated decisions before seeing a result.
Define the first useful outcome for a new customer. Then measure how much work lies between them and that outcome.
For an AI image tool, first value may be a credible concept image in the customer’s style. For an analytics product, it may be one answer to a live business question. For a marketing workflow tool, it may be a campaign ready for review.
Now list every action needed to reach it. Next to each action, label it:
| Type of action | What to do |
|---|---|
| Essential | Keep it, but make the reason clear. |
| Deferrable | Move it until after the first outcome. |
| Automatable | Choose a safe default or infer it from context. |
| Expert-only | Hide it behind an advanced option. |
| Confusing | Rename, redesign, or remove it. |
This exercise often reveals why a funnel looks weak. The user did not reject the outcome. They abandoned the price of reaching it.
Listen for repeated friction, not isolated feature requests
The founder in this case heard similar feedback over time and initially did not act on it. That is common. One complaint is easy to dismiss as a preference. Five independent people describing the same barrier is evidence.
Create a friction log during onboarding calls, demos, support sessions, and user tests. Record the moment, the exact language, and the behavior.
For example:
| Moment | User says | User does | Possible interpretation |
|---|---|---|---|
| First screen | “Where do I start?” | waits for guidance | blank state offers too many choices |
| Setup step | “Do I need to know this?” | closes the modal | technical prerequisite is unclear |
| First result | “Can I just tell it what I want?” | asks support | interface does not match their mental model |
Do not count requests only by volume. Weight them by who makes them and when. Friction that blocks a target customer before first value is more important than a minor preference from an advanced user after they are already successful.
You are looking for the sentence that keeps returning in different forms. In the case study, the message was not “please add a new export button.” It was “this is too hard for the job I need done.” That required a product-level response.
A pivot is not a reskin
Replacing a node interface with chat changed more than the appearance of the product. It changed the unit of work.
The old experience asked customers to construct a process. The new experience allowed them to describe an outcome. That is a fundamental difference.
When you consider a friction pivot, identify the current unit of work and the customer’s desired unit of work.
- Current: configure a sequence of rules. Desired: approve a working campaign.
- Current: map data fields. Desired: see the weekly report.
- Current: create a project structure. Desired: give the client one clear next step.
- Current: tune a model. Desired: receive a useful draft.
The product does not always need to remove the underlying complexity. It can absorb it. Good defaults, templates, natural-language input, guided setup, and opinionated flows can move technical work out of the user’s path while preserving control for people who need it.
This is why “make it simpler” is not enough. Decide which complexity belongs to the system and which complexity truly belongs to the user.
Preserve power without making everyone pay for it
Experienced customers may worry when a product becomes simpler. Their concern is legitimate. A product that removes all control can become limiting once users grow.
The answer is not to keep the advanced interface as the default. Use progressive disclosure instead.
- Give beginners a clear, opinionated path to the first outcome.
- Let them edit safe defaults once they understand the result.
- Reveal advanced controls only when a user has a reason to need them.
- Keep expert workflows available, but do not require beginners to understand them on day one.
Think of it as a ladder, not a fork in the road. New users start with a simple request. Repeated users learn a few controls. Experts can eventually access the depth they need. Each level should feel like a natural next step rather than a different product.
The founder’s choice to change the business model at the same time also matters. A subscription can align revenue with ongoing utility, but it only works when customers return and receive recurring value. Do not copy the pricing change because it was part of this case. First make sure the product has a reason to be used again next week.
How to test a friction pivot before rebuilding everything
You do not need to delete an interface before you know the simpler route works. Run a controlled test.
Step 1: choose one high-friction job
Pick the task that most often blocks first value. Avoid redesigning the entire product at once.
Step 2: create a concierge shortcut
During a call or in a small beta, let customers describe the desired outcome in their own words. Behind the scenes, you can configure the complex workflow manually. Record what they ask for and what information is missing.
Step 3: build the smallest guided path
Turn the recurring requests into a template, prompt, wizard, or default. The first version can be narrow. Its job is to prove that people reach value faster.
Step 4: compare first-use behavior
Measure time to first outcome, completion rate, number of support questions, and how many users return. Ask users to explain what they achieved without using your product’s marketing language.
Step 5: decide what to absorb
If the shortcut works, move more hidden complexity into the system. If it does not, inspect whether the problem is trust, capability, or audience fit rather than interface complexity.
This approach protects you from a common pivot mistake: replacing one fashionable interface with another without changing the user’s actual effort.
The distribution lesson: simple products are easier to explain
The case study also credited SEO as an important long-term channel. Product simplicity and distribution are connected.
When the product solves one job clearly, it is easier to write useful pages about it. A person can search for the outcome, find a guide, and understand within a minute whether the product helps. When the product requires a complex mental model, every landing page must teach the model before it can make a promise.
That does not mean simple products rank automatically. It means clear jobs create clearer content:
- a use-case page for a specific professional;
- a guide to completing one task;
- an honest comparison with a manual workaround; and
- examples that show the output a customer can expect.
If your marketing needs a ten-minute explanation before a customer understands the first benefit, that is useful evidence for the product team, not only the copywriter.
When not to simplify
Some products serve experts who genuinely need precision. In those cases, a simplified interface can reduce trust or remove the professional control that justifies the purchase.
Do not simplify because chat is popular. Simplify when the target customer repeatedly fails before value because the product asks them to think like the builder rather than complete the job they came to do.
Also avoid hiding risk. If a complex action affects money, customer data, or compliance, a smoother path must still make important choices visible. The system can remove unnecessary effort without making consequential decisions mysterious.
A useful boundary is reversible versus irreversible work. Make reversible exploration fast: templates, previews, sample data, and draft modes reduce fear. Slow down irreversible actions: sending an email campaign, overwriting a dataset, publishing client work, or changing billing should still receive clear review and confirmation. Reducing product friction is not the same as removing informed choice.
This distinction lets a product feel generous without becoming careless. It also gives product teams a practical prioritisation rule: remove the effort that delays learning, not the safeguards that prevent expensive mistakes.
A quick checklist
- [ ] We have defined one first useful outcome for a new customer.
- [ ] We know every action required to reach it.
- [ ] We have labeled actions as essential, deferrable, automatable, expert-only, or confusing.
- [ ] We keep a log of repeated onboarding friction.
- [ ] We are testing a smaller guided path before rebuilding the full product.
- [ ] We measure completion and return behavior, not only sign-ups.
- [ ] Advanced controls are available when needed, not forced on day one.
- [ ] Any pricing change is supported by recurring customer value.
The best pivot is not the one that looks newest. It is the one that removes the most unnecessary work between a real customer and the result they came for. Sometimes the highest-value feature is the step they no longer have to learn.
