38:21
product management
Leah Hickman argues that traditional "what by when" feature roadmaps are wasteful because they convert unvalidated ideas into false commitments the moment a date is attached; she advocates outcome-based roadmaps — structured as problem/objective, measure of success (key results), hypothesis, and "feature candidates" — that tie work to business results, replace fixed dates with time frames or rare "high integrity commitments," and shift executive control from picking features to setting strategic context.
Executives demand roadmaps to answer two questions: are we working on the most important thing, and when will we get it.
People hate roadmaps because a date attached to an idea turns it into a commitment/promise/expectation before proper discovery has happened.
Most roadmap items fail to achieve their intended outcome, largely because they rest on unvalidated assumptions from people disconnected from the actual work.
An outcome-based roadmap is structured as: outcome/objective → key results (how success is measured) → hypothesis → feature candidates (explicitly not commitments).
"Feature candidate" is a deliberate label that keeps roadmap items framed as hypotheses to test, not promises to deliver.
Leah would never commit to a specific date, only a time frame (e.g., "late Q2"), because fixed dates force trading off building the right thing against hitting the date.
Roadmaps are often perceived by executives as a tool of control, but Hickman calls this "false control" — teams can deliver 100% of a roadmap and still have zero business impact.
Coaching advice to executives: stop controlling which features get built; instead control strategic context (business objectives, vision, strategy, priorities) and hold teams accountable to their own definition of success.
Antipattern: stakeholder-driven roadmap — collecting every stakeholder's requests and building a project plan from them, with nothing validated, leading to a lose-lose of unmet expectations.
Antipattern: executive-driven/competitor-driven roadmap — work dictated by what a competitor just shipped or by a CEO's requests, with no discovery.
Antipattern (host's framing): "quarterly fill-the-bucket roadmap" — treating fixed engineering capacity (e.g., a set number of story points) as the planning unit and finding tickets to fill it.
Antipattern: "future factory roadmap" — a pure list of outputs disconnected from strategy; diagnosable by asking people why they're working on something and getting "because it's on the roadmap/in Jira."
Antipattern: fixed-timeline roadmap — a date promised before any discovery is done, creating unrealistic expectations.
A "transitional roadmap" is a bridge step: still lists features, but requires asking "why" for each and framing them against a problem/objective and success measure — a "working backward" approach.
Outcome-based roadmaps and OKRs are compatible: objective = problem to solve, key results = measurement of success, feature candidates sit underneath both.
Hickman states that in 35 years of building products she has never met an engineer who didn't care about the why or impact of their work.
Product strategy is defined as "the prioritized list of problems to solve," which should ladder up to product vision and business needs.
Dates aren't inherently opposed to the outcome-based model — they can exist as "High Integrity Commitments" (HIC), explicitly labeled on the roadmap, reserved for large initiatives or cross-team dependencies.
A legitimate HIC requires two things: discovery/feasibility work already done, and the commitment on scope coming from the builders, not the leaders (leadership can set the date, the team commits to what fits).
Diagnostic question for stakeholders: how many people have delivered roadmap items that were never used by a single user — usually most hands go up, exposing that feature-based roadmaps hit dates while delivering unvalidated, low-value output.
Credibility with stakeholders is built by delivering one validated, valuable thing at a time and must be earned, not assumed.
Reframing technique: instead of saying no to a stakeholder's idea, apply the improv "yes, and" rule — ask them to elaborate on the problem their idea solves rather than rejecting it outright.
Practical closing advice: for any feature-based roadmap or backlog item, ask why, articulate the problem being solved, how success will be measured, and what evidence exists that the item is valuable, usable, feasible, and viable.
Rule of thumb: never tell people what you're working on without telling them why; annotate roadmap items with their outcome alongside the deliverable.
Outcome-based roadmap — A roadmap structured around outcomes/objectives, their key results (measures of success), and underlying hypotheses rather than a list of features tied to delivery dates. Apply: Replace a feature-and-date roadmap with a layout of business outcome → key result → hypothesis → feature candidates to test.
Feature candidate — A labeling convention that frames a proposed capability as an untested hypothesis rather than a committed deliverable. Apply: Prefix or tag roadmap items as "candidates" so teams and stakeholders treat them as ideas to validate, not promises to ship.
High Integrity Commitment (HIC) — A rare, explicitly labeled date-based commitment reserved for large initiatives or cross-team dependencies, valid only when feasibility work is done and the team (not leadership) commits to the scope. Apply: Mark true date commitments with an explicit "HIC:" tag on the roadmap, and only use it after discovery is complete and the delivering team has agreed to the scope.
Transitional roadmap — A bridge format between feature roadmaps and outcome-based roadmaps that still lists features but requires each to be tied to a stated "why," problem, and value proposition. Apply: When an org isn't ready for full outcome-based roadmaps, keep the feature list but annotate every item with the problem it solves and how success will be measured.
Working backward methodology — A planning approach that starts from the problem and value proposition, then defines the success measure, and only then lists feature candidates. Apply: Before listing any deliverable, first write down the problem, the customer/business value proposition, and how success will be measured.
Stakeholder-driven roadmap (antipattern) — A roadmap built by collecting every stakeholder's requests and turning them into a project plan without validation. Apply: Recognize this pattern when a roadmap's contents map directly to stakeholder requests with no testing, and replace it by requiring a problem/value justification per item.
Executive-driven / competitor-driven roadmap (antipattern) — A roadmap dictated by executive or competitor moves (e.g., matching a competitor's newly shipped feature) rather than validated problems. Apply: Flag roadmap items whose sole justification is "a competitor did it" or "a leader asked for it" and require independent problem validation.
Quarterly fill-the-bucket roadmap (antipattern) — Treating a fixed engineering capacity number (e.g., a set count of story points) as the planning unit and sourcing tickets to fill it. Apply: Avoid starting roadmap planning from "how much capacity do we have" and instead start from which problems are worth solving.
Future factory roadmap (antipattern) — A roadmap that is purely a list of outputs disconnected from strategy or problems. Apply: Test for this by asking team members why they're working on an item; if the answer is "it's on the roadmap" or "it's in Jira," the roadmap needs a why attached to each item.
Fixed-timeline roadmap (antipattern) — A roadmap built around a promised date set before any discovery work has been done. Apply: Delay date commitments until after discovery/feasibility work, replacing fixed dates with time frames.
Valuable / usable / feasible / viable — A four-part evaluation criteria for whether a product idea is worth pursuing, referenced when validating backlog or feature-candidate items. Apply: Before pursuing a backlog item, ask what evidence exists that it is valuable, usable, feasible, and viable.
Roadmap-as-hybrid-with-OKRs — A model where an outcome-based roadmap's structure maps directly onto OKRs: objective = problem to solve, key results = success measurement, with feature candidates underneath. Apply: When an organization already runs OKRs, present the roadmap as the tactical layer beneath existing objectives and key results rather than a separate feature list.
"Change what you control" coaching model — A coaching reframe for executives: shift their control from picking specific features/dates to setting strategic context (vision, strategy, business priorities) and holding teams accountable for defined success. Apply: When an executive demands control over specific features, redirect them to define and own the business objectives and success criteria instead, and let the team own the solution.
"Yes, and" stakeholder intake rule — An improv-derived technique for responding to stakeholder feature requests by asking them to elaborate on the problem and value instead of rejecting the idea outright. Apply: When a stakeholder proposes a feature, respond by asking what problem it solves and how they'd measure its success rather than saying no.
Product strategy as prioritized list of problems — A definition of product strategy as the ranked set of problems worth solving, which should ladder up to product vision and business needs. Apply: Build the product strategy document as a prioritized problem list rather than a prioritized feature list, and derive the roadmap from it.
Annotate roadmap items with "why" — A practice of pairing every roadmap deliverable with the outcome/business reason behind it. Apply: Next to any feature or deliverable on a roadmap, write the specific outcome it is meant to drive (e.g., "building X to increase conversion, to increase revenue").
The core critique isn't that roadmaps are bad, but that attaching a date to an unvalidated idea is what converts a harmless list of ideas into a trust-eroding promise — the failure mode is structural, not attitudinal.
A company can deliver 100% of its roadmap on time and still go out of business, which Hickman uses to argue that roadmap "success" (on-time delivery) and product/company success are entirely decoupled metrics.
The "false control" framing reverses the usual executive intuition: demanding feature-level and date-level control actually reduces an executive's real leverage over outcomes, because it pulls them into decisions builders are better positioned to make.
Hickman's advice to executives isn't to relinquish control but to relocate it — from tactical (features/dates) to strategic (vision, objectives, definition of success) — reframing the negotiation as a trade rather than a loss.
A legitimate date-based commitment (HIC) is legitimate only when its origin is inverted from the usual practice: leadership may fix the date, but the team — not leadership — must determine and commit to the scope, and only after feasibility work is already done.
The stakeholder-diagnostic question ("how many delivered roadmap items were never used by a single user") functions as social proof within a room — most hands going up demonstrates the failure mode experientially rather than argumentatively.
Reframing a stakeholder's request as competing against a quantified alternative (e.g., a stakeholder's idea worth an estimated $1M versus a $10M initiative already underway) defuses pushback without ever saying no — stakeholders back off once they see a bigger number, not because they were told they're wrong.
The predictability-versus-innovation tradeoff is framed as a hidden cost leaders don't price in: guaranteeing a date structurally cannot guarantee the outcome, so demanding both from a team is an internally inconsistent ask.
Even engineers who receive unvalidated, top-down solutions still want the underlying "why" — the absence of that context in most roadmaps is treated as an organizational failure to communicate rather than a lack of interest from the delivery team.
«if a road map were just a list of ideas, it is harmless... But the second you put a date beside an idea, it turns from an idea into like a commitment, a promise... an expectation.»
— 03:20
«I have seen even the best intended road maps destroy a company because one stakeholder had a missed expectation of failed commitment... eroding trust.»
— 03:36
«delivering a feature is a means to an end. Like who cares how many features we deliver if they don't yield any kind of positive result for the customer or positive result for the business.»
— 08:24
«I would never commit to a date. I'd commit to a time frame but I would not commit to a date... you're just setting the team up for failure.»
— 09:53
«it's more valuable to deliver the right product than to deliver it by a particular date.»
— 11:52
«a road map is a perceived tool of control... The problem is is that it's false control.»
— 12:48
«was that product team successful? No, the product team wasn't successful because the company failed.»
— 13:29
«change what you control. Don't worry about controlling the features that are being developed on the road map. Make sure that you control the strategic context.»
— 13:39
«most road maps in and by themselves are arrogant in nature — somebody's feeling like I know the solution.»
— 15:01
«what's more important to you, getting your goal of growing revenue or hitting the date of releasing this feature... if we want [you] to guarantee the date you're definitely not going to guarantee the outcome.»
— 15:42
«they're just not very effective tools if you believe the value is building the right product to drive the results for the customer and the company.»
— 18:16
«If I give you the solution, you become a delivery team or a future team. If I give you the problem, I empower you.»
— 20:42
«I haven't worked with a single engineer in the 35 years that I've been building products that didn't care about the why.»
— 26:19
«If we're delivering the wrong thing efficiently, who cares?»
— 28:34
«The easiest way I think about product strategy is it's the prioritized list of problems to solve.»
— 29:07
«How many people have delivered items on their road map that have never been used by a single user.»
— 33:22
«Would you rather me deliver something that has no value by that date or would you rather have me deliver something that has value to your customers and helps you achieve your revenue targets because you allowed me to have some time to build the right thing?»
— 34:02
«You have to earn it though right it doesn't come for free you have to earn that.»
— 34:45
«No stakeholder is like you must do my idea, they just don't know you're working on anything more valuable.»
— 35:11
«Never tell people what you're working on without telling them why you're doing it.»
— 36:32
«Nobody has ever given you the templates you must use for a road map. It kind of comes from you.»
— 36:47
Reception
Comments are uniformly positive, ranging from generic praise to one strong endorsement calling it the best product podcast.
This is a practitioner coaching session that repackages familiar outcome-over-output product philosophy (OKRs, discovery, valuable/usable/feasible/viable) into a specific, teachable roadmap vocabulary — feature candidates, transitional roadmaps, and High Integrity Commitments — aimed at PMs navigating stakeholder and executive pressure for fixed dates.
38:21