I Start With Friction, Not Features

The side projects I keep returning to usually begin with a repeated annoyance. Naming the friction first makes the product smaller and the first build clearer.

·

2–3 minutes

·

I find product ideas much easier to reason about when I stop asking “What should I build?”

The question is too open.

I get a more useful starting point from:

What keeps annoying me enough that I keep working around it?

Several of my small projects started that way.

ScribeShot started with losing the useful moment inside a video

I was saving useful YouTube videos, but later I could not easily return to the exact explanation, screenshot or idea I wanted.

The obvious feature list could have become huge:

  • AI summaries
  • chat
  • mind maps
  • quizzes
  • search
  • exports

But the original friction was much smaller.

I need a better way back into a video after I have watched it.

That sentence gives the extra features something to answer to.

If a feature does not make capture, retrieval or understanding better, it is probably not central.

WonderKidTV started with feed drift, not “screen time”

YouTube had useful content I did not want to block.

The repeated problem was what happened after the first useful video.

Autoplay, recommendations and open search could move the session somewhere completely different.

That made the build question narrower:

How do I keep the useful content while reducing the uncontrolled feed around it?

Now curation, per-child controls and watch reports are not random features.

They are different attempts to reduce the same friction.

ThinkChampion started with repetition becoming passive

Spelling needs repetition.

I did not want to remove that.

The friction was that the same practice format becomes dull and easy to perform mechanically.

That led to a different build question:

How can the word stay the same while the route into it changes?

Multiple challenge types came after that.

The feature followed the friction.

Features are easier to judge when the friction is explicit

A feature request sounds attractive in isolation.

“Add AI chat.”

“Add analytics.”

“Add export.”

The harder question is what repeated problem the feature removes.

If I cannot connect the feature back to a real friction, I am probably decorating the product rather than improving it.

My smallest useful product brief has three lines

  • Friction: What keeps happening that is annoying, slow or easy to lose?
  • Current workaround: What am I doing manually today?
  • Smallest change: What could remove one meaningful part of that friction?

That is enough to start sketching.

Not every annoyance deserves a product.

But starting with friction gives me a better filter than starting with features.

The product can grow later. The problem should get clearer first.

Written by Rakesh Kalra, a software engineer with 20+ years of experience who still prefers building things. ThinkBySketch is where I share small tools, experiments and lessons from trying to make work and learning simpler. About ThinkBySketch →

One useful experiment at a time

Get the next thing I’m trying.

Small tools, systems and ideas for building, learning and working better, including the experiments that do not work.

After subscribing, check your inbox and click the confirmation link.

Comments

Leave a comment