# Roadmap decisions rather than dates.

DevFeed: [Roadmap decisions rather than dates.](<https://devfeed.tech/articles/roadmap-decisions-rather-than-dates-35683.md>)

Original publisher: [Read original article](<https://lethain.com/decisions-not-dates/>)

Published: 2026-08-11T14:00:00Z

Content type: opinion

Language: en

Sources: [Will Larson - Irrational Exuberance](<https://devfeed.tech/sources/will-larson-irrational-exuberance.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Passkeys](<https://devfeed.tech/topics/passkeys.md>), [resiliency](<https://devfeed.tech/topics/resiliency.md>), [User Experience](<https://devfeed.tech/topics/user-experience.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [Web](<https://devfeed.tech/topics/web.md>)

Tags: [development](<https://devfeed.tech/tags/development.md>), [experience](<https://devfeed.tech/tags/experience.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [phishing](<https://devfeed.tech/tags/phishing.md>), [resiliency](<https://devfeed.tech/tags/resiliency.md>), [web](<https://devfeed.tech/tags/web.md>)

## AI overview

The article argues that product roadmaps should prioritize decisions and execution constraints rather than fixed dates. It uses the development and rollout of passkey support at Imprint as an example, describing implementation behind a feature flag, staged web release, feedback iteration, and expansion to native mobile experiences.

## Source excerpt

One thing that bothered me about Imprint's product after joining was our lack of passkey support. Passkey support is a rare opportunity to increase resiliency to phishing attacks while simultaneously reducing login friction. If it's good for our members, our partners, and our product, it felt like something we should have already shipped. Nonetheless, it was hard to get it onto the roadmap alongside everything else we were working on. To dig into passkeys, I started sketching out the implementation as a side quest. Some iterations later, I had something implemented behind a disabled feature flag for team review. At that point, most problems had a concrete solution implemented, and the remaining issues were messy intersections between passkey implementation and user experience. Issues remained, but the tangible implementation made tradeoffs explicit, and we were able to work through them. Soon thereafter, we launched passkeys to a small group in our web experience, iterated on feedback, finalized the details, and brought those details forward to our native mobile experiences as well. It never got onto the roadmap, but it did ship. Our passkey release planted a seed for me, but it required another experience to fully germinate. We had a discussion about hitting a date for a product extension we're developing. Our conversation kept anchoring on the idea that pulling in a date was dependent on pushing out dates for other projects. Presenting two conflicting projects as requiring timeline tradeoffs wouldn't have caused me to blink an eye five years ago, but in this conversation it inspired a sort of instinctual revolt: with modern development techniques, I believe very few projects are essentially constrained by execution bandwidth. Some are constrained by approvals, others are constrained by cross-team and cross-functional handoffs, and many are constrained by missing decisions, but almost none should be constrained purely on time. Shifting blocks of time across project