Why Ashby Focuses on Product Velocity Over Long-Term Roadmaps

At Ashby, we don't have a long-term product roadmap. We've decided to take this approach for a number of reasons. In this post, we'll outline these reasons and our broader product philosophy.

The problem with long-term roadmaps

While many companies publish 12+ month roadmaps, providing a sense of visibility of what is to come, they very often miss deadlines or kill features altogether, leaving their customers disappointed. Oftentimes, customers will also put off investment in additional tools (or hold out switching vendors) because they are expecting the promised functionality to be released on time. When that does not happen, they are stuck with a solution that does not meet their business needs.

Even if vendors deliver on all of their commitments on their long-term roadmap in time (something I personally have not seen in the past), this approach to product development still has a major issue: It is unclear if what was put on the roadmap 9-12 months ago is still the most pressing issue for customers.

I'm writing this in 2024, and if we look back at the last four years in the recruiting industry, the above point should be clear. The problems TA teams faced were wildly different every 6-9 months. On top of that, we witnessed a step-function improvement in AI capabilities that significantly changed the kind of functionality vendors could deliver.

Why are long-term roadmaps so common?

There are a number of good reasons long-term roadmaps are used so frequently, despite their downsides.

Enterprise customers, understandably, want to know how the vendors they bet on will evolve over the coming years. But because long-term roadmaps are so often missed, we believe they mostly bring a misleading sense of comfort.

Vendors often feel the need to resort to long-term roadmaps because customers are pointing to significant gaps in their products. The vendor may not be able to address these issues quickly enough, so these "complaints" are turned into functionality that is added to the promised roadmap to buy time to solve them. Such vendors will also often use the allure of the future roadmap to help close deals despite missing product functionality.

Ashby's Approach

First and foremost, we're focused on product velocity. We think that how often we ship meaningful product improvements is one of the most important metrics to track. It leads to fewer gaps in the product and, as a result, reduces the need to make forward-looking promises.

Second, we make commitments to invest in specific product areas (instead of individual features). We've staffed all of our core product areas, Core ATS, Scheduling, CRM, Analytics, Enterprise, and Usability (and now AI), to ensure they receive ongoing improvements over time. This should give you an idea of what to plan for, as you don't need to worry that a specific product area will stagnate.

Lastly, we have priorities within each of these product areas. This is where we get to the exciting part — what do we pick to build and how? There are three main inputs to that:

1. Customer feedback (we look at both the impact of the potential change and the quantity of the request)
2. Our long-term product vision for each of these product areas
3. Changes in the market (e.g., new legislation around Salary Transparency)

We are constantly reviewing the above, and it drives how we pick the next set of projects within each product area.

This means at any given point in time, we'll have several product updates that we know will be released in the next 1-3 months. At the same time, we're constantly evaluating what should come next based on your input.

For individual feature requests, this means they either have an ETA in the next 1-3 months or no ETA. No ETA certainly does not mean we won't ship an update for this request; it simply means we have not committed to it yet because we haven't started work on it yet. So, we're keeping it in the backlog as a candidate to be prioritized when the next set of projects in the relevant product area are completed.

There's one more benefit to this approach that is worth calling out: In addition to our ongoing major releases, we also ship dozens of smaller but impactful improvements that never make it onto the formal roadmap (which also means they don't have a public timeline). Vendors that cram their entire Engineering schedule with pre-planned releases lose the ability to invest in iterative and ongoing polish. Often, these smaller improvements have the strongest impact on day-to-day users of a product (and they come as a surprise and delight moments for our users).

Interfacing with our CS & Product teams

We view all of our customers who provide material customer feedback as design partners. While we don't have a formal program today, our CS team works very closely with customers to understand their unique needs and how some of them should translate into future product improvements. They are always in sync with the product team and will often loop in individual Product Managers to connect with customers directly on individual product areas.

Never say never

We may not keep this approach to long-term roadmaps forever. We continuously evaluate how to evolve our product development practice (once again, based on your feedback!).

But for now, we believe strongly that focusing on product velocity, close partnership with customers, agility in our roadmap, and not overpromising but rather surprising and delighting are the right way to go.