Why Roads Are Not Straight: A Product Management Lesson
Product managers should understand why roads are not always straight.
When I was younger, I used to wonder why highways curve. Wouldn't it be easier to go straight from point A to point B? A straight line is the shortest distance. Why waste time on curves?
Yes, it would be easier on paper. But it's not about what's easier on paper. It's about what's worth it.
TL;DR: Making a road perfectly straight has enormous costs: cutting through hills, relocating people, destroying trees, fighting nature. The same is true for product features. Every simplification and perfection you chase has a cost in engineering time, complexity, and maintenance. The real PM skill is knowing when the curve is good enough and further straightening isn't adding meaningful value.
The cost of straight roads
Making a road perfectly straight means:
- Cutting through hills
- Relocating people from their homes
- Destroying forests and ecosystems
- Engineering bridges over valleys
- Sometimes, fighting the very geography of the land
That's a lot of effort. And for what? To save a few minutes of drive time?
In most cases, the curve adds negligible time to the journey while saving enormous costs. The road still gets you from A to B. It just takes a slightly less direct path. And that path respects the terrain instead of fighting it.
The PM equivalent: chasing the straight road
When PMs start out, we often want to build the "straight road" for users. The shortest, sleekest, most elegant path possible. Zero friction. Perfect flow. Every edge case handled. Every interaction polished.
That instinct comes from a good place. You care about the user experience. You want things to be simple and delightful. You've read about products that "just work" and you want to build that.
But every simplification and perfection you chase has a cost:
- Engineering time (the team spends weeks on something that could've shipped in days)
- Increased complexity behind the scenes (simple-looking features are often the hardest to build)
- Edge cases that multiply the more you try to handle them
- Maintenance burden that grows with every "smart" interaction
- Opportunity cost (the other features you didn't build while perfecting this one)
"How?" matters more than PMs think
While not thinking about the "How?" in the earlier stages of developing a feature is fine (you should explore solutions freely before committing), you should not ignore it altogether until the end.
I've seen PMs dream of straight roads and hand the vision to engineering, only to discover that the "straight road" would take 3 months while the "slightly curved road" takes 3 weeks.
The curve isn't a compromise. It's wisdom.
| Approach | PM mindset | Result |
|---|---|---|
| Straight road | "Users deserve the perfect experience" | 3 months, high complexity, fragile |
| Curved road | "Users need to get from A to B reliably" | 3 weeks, maintainable, shippable |
Both get the user to their destination. One respects the terrain (technical constraints, team capacity, timeline). The other fights it.
Examples of unnecessary straight roads
The perfect onboarding flow. You want every new user to have a personalized, contextual, step-by-step experience. That's a straight road. The curved road: a simple 3-step wizard that covers 80% of users and ships in a week. You can iterate from there.
The zero-click integration. You want the product to automatically connect to every tool the user has, with no setup required. That's a straight road through a mountain. The curved road: a clear, 5-minute setup flow with good documentation. Users don't mind a few clicks if the value is clear.
The intelligent recommendation engine. You want to predict exactly what the user needs next using ML. That's a straight road requiring months of data collection and model training. The curved road: a manually curated "popular next steps" section based on what most users do. It's not personalized, but it works.
In each case, the curved road delivers 80-90% of the value at 20% of the cost. The remaining 10% of perfection costs 80% of the effort. That's rarely a good trade.
When the curve is good enough
The real skill isn't building straight roads. It's knowing when the curve is good enough and further effort isn't adding meaningful value.
Ask yourself:
- Will the user notice the difference between the perfect version and the good-enough version?
- If they notice, will it change their decision to use the product?
- Is the extra effort proportional to the extra value?
- What else could the team build with that time?
Most of the time, the honest answer is: the curve is fine. The user will get from A to B. They might not even notice the slight detour. And the team can ship three other improvements in the time it would've taken to straighten this one road.
The trap of invisible perfection
Here's what makes this hard: the PM who insists on straight roads looks like they "have high standards." They seem like they care more about users. They seem like the better PM.
But in practice, they ship less. Their teams burn out on polish that users don't notice. Their roadmaps stall because every feature takes 3x longer than it should. And the "perfect" features they eventually ship often get overtaken by competitors who shipped the curved version six months earlier.
High standards doesn't mean perfection. It means consistently delivering high value. And sometimes high value ships with a curve in it.
When straight roads ARE worth it
Not every curve is acceptable. Sometimes you do need to fight the terrain:
- Security and compliance. No shortcuts here. The straight road is mandatory.
- Core user trust moments. Payment flows, data deletion, account security. These deserve perfection because failure here destroys trust permanently.
- Foundations that everything else builds on. An architecture decision that will be expensive to change later warrants extra thought upfront.
The judgment is: how reversible is this decision? If you can iterate later (most feature UX), the curve is fine. Ship and learn. If it's hard to change later (architecture, security, pricing model), invest in getting it straighter the first time.
The bottom line
Roads curve because the cost of straightening them exceeds the value. The same principle applies to every product decision you make.
Chase the straight road when it matters (security, trust, foundations). Accept the curve everywhere else. Ship faster. Learn faster. Iterate.
The PMs who build the best products aren't the ones who demand perfection at every turn. They're the ones who know which curves are fine and which straightenings are worth the fight.
That judgment, the ability to assess where effort creates value vs. where it's wasted, is one of the most important skills a PM can develop.
How ProductResume helps
Hiring managers look for PMs who can make pragmatic trade-offs, not PMs who describe every feature as "perfect." Your resume bullets should show evidence of shipping effectively, not just designing ideally. Score your PM resume to see whether your experience signals pragmatic leadership or just ambition. The Skills & Tools dimension evaluates your ability to balance quality with velocity.