Most roadmaps look great in presentations.
They are filled with features, milestones, and confident timelines. Q2 is locked in, Q3 looks ambitious, and Q4 is “strategic”. But if you talk to the people actually building the product, the reality is often different. Teams feel slowed down. Simple changes take too long. The same issues keep coming back. Design inconsistencies start to spread. Certain parts of the codebase become untouchable. And somehow, none of this is clearly reflected in the roadmap.
This gap is where the idea of ship by friction comes from. Instead of planning what to ship primarily around features and assumptions, ship by friction asks a simpler question:
Where does our work experience the most friction right now?
What Is Friction, Really?
Friction is anything that creates unnecessary resistance in product development or in the user experience.
It shows up in many forms:
- Developers avoid certain files or modules because they feel risky.
- Designers create one-off solutions because the system doesn’t quite fit.
- Product managers spend time clarifying flows that should be obvious.
- Support keeps answering the same questions.
- Releases feel stressful instead of routine.
Friction Logs: Making the Invisible Visible
Most teams already talk about friction informally:
- “This part is painful to work on.”
- “We should really clean this up one day.”
- “Every time we touch this, something breaks.”
The problem is that these insights usually disappear into conversations, Slack threads, or meeting notes. A friction log is a simple way to capture them explicitly. It’s not a bug tracker or a backlog. It’s just an ongoing record of moments where work feels unnecessarily hard.
Examples of friction log entries:
- “Adding a new validation rule requires changes in three different places.”
- “Our design system doesn’t support this layout, so we keep improvising.”
- “Users consistently misunderstand this step in the flow.”
- “Deployments work, but the process is mentally exhausting.”
Nothing in a friction log needs to be fixed immediately. The goal is awareness, not instant action.
Roadmapping Based on Friction
Most teams already talk about friction informally:
- What are we building next?
- What will stakeholders expect?
- What looks valuable on a slide?
A friction-driven roadmap shifts the conversation:
- Which frictions appear most often?
- Which ones slow the team down the most?
- Which ones increase risk as the product grows?
- Which ones compound if we keep ignoring them?
When you review friction logs over time, patterns emerge. Certain issues keep resurfacing sprint after sprint. Others may be rare but extremely disruptive when they happen. This makes prioritization more grounded.
Instead of saying “We’ll refactor this later.”, you can say “This friction affects almost every change we make. Removing it will speed up everything else.”
That’s a conversation developers, product managers, and leadership can align on.
Design Debt as a Source of Friction
Design debt is one of the most common and most underestimated sources of friction.
It often hides in inconsistent UI patterns, unclear interaction rules, components that almost fit but not quite and layouts that don’t scale to new use cases.
For developers, design debt means more conditionals and special cases. For designers, it means constant workarounds. For the business, it means confusion, slower delivery, and higher support costs.
In a Ship by friction approach, design debt stops being an abstract “nice-to-fix-someday” issue. It becomes a logged, recurring friction with a visible impact. You’re not arguing for a redesign because it feels right. You’re addressing a problem because it consistently slows the system down.
Why This Works Beyond Engineering
One reason this approach resonates is that friction creates a shared language across roles.
- Developers talk about cognitive load and maintainability.
- Designers talk about consistency and usability.
- Product managers talk about flow efficiency.
- Leaders talk about delivery speed and risk.
Friction connects all of these perspectives. When a team says, “This friction costs us time every sprint.”, that’s not a technical complaint, it’s a business signal grounded in real experience.
Shipping Less, But Moving Faster
A common concern is that focusing on friction will slow feature delivery. In practice, teams that consistently reduce friction often move faster over time, make fewer mistakes, onboard new people more easily and feel more confident shipping changes.
They may ship fewer features in the short term, but they ship with less stress and more predictability. Ship by friction is not about perfection. It’s about removing the biggest obstacles to progress.
A Small Shift with Lasting Impact
Ship by friction doesn’t require a new framework or a major reorganization. It starts with paying attention. With writing things down. With taking everyday pain seriously.
Over time, friction logs become a mirror of your product and your organization. They reveal where complexity accumulates and what your roadmap has quietly ignored. And in the long run, they help teams move away from constantly pushing uphill, toward a way of working that feels calmer, lighter, and more sustainable.
Because the best roadmap isn’t the one that looks impressive. It’s the one that makes progress easier.
