Velocity straight into a cul-de-sac

Mar 3, 2026

Spend enough time in industry and you pick up on all the business euphemisms that are inevitable – the ever-creative ways to rename what a mass layoff is (it's a RIF now?), the fleeting nods to usability, accessibility, and "product excellence", and probably the one that concerns me the most, "increased velocity".

When a product manager or engineering lead starts throwing the fateful V word around, it's inevitably code for "we want to ship faster." More specifically, it's code for we want to ship new features faster.

Experienced UXers will have already picked up on the red flag. Product teams that start thinking of their primary goal as "the number of features we shipped in a time period" are a bad sign. Pavel over at Product Picnic has ranted extensively over how this pattern of behavior does nothing other than churn out crappy features no one gets excited about in a "throw spaghetti against the wall to see what sticks" product strategy.

When forced to "partner" (and the term is used very generously compared to what the actual experience feels like) with a team that's dead set on launching features as fast as possible, UX teams inevitably get the unpopular role of having to remind everyone that users don't just want a firehose of arbitrary features, but instead just want their lives improved by having specific needs met. And guess what, figuring out what customers actually need from a product is hard, slow, work. No matter how fast you can write analysis code or draft up a survey, it takes time to have a survey sent out, participants recruited and interviewed, users to see your A/B test. None of those research methods have had any recent tech that makes them orders of magnitude faster "because AI".

It used to be that the ideal development situation would be when product folks would be planning months, even quarters or years ahead for new feature ideas because the time to code up and release a new feature took a long time. Product folks would have to manage the production cycle during the dev period, but it also left them space to gather feedback from customers and engage with the UX research team to get background and understanding of the product. Essentially, UX folks could use the time when engineering was implementing feature A to start doing research that would inform potential feature B or C.

Okay, reality never slotted so nicely because UX would wind up dividing time between 2-5 different teams asking questions and eventually get booked up. But in theory where was space to do slow work.

But as leadership starts seeing how engineers can crank out code at 3x, 5x the pace they originally can, they naturally start asking why can't teams launch more stuff? What's stopping them? Given the chain of command, that pressure just translates downward into "we should ship more stuff because code isn't the bottleneck!". Now, design and research – thinking seriously about the user – has become the biggest bottlenecks.

Crank up the pressure from above more, especially in highly competitive markets, and those product teams start asking if they can't speed up those pesky UX functions with their Universal Magical AI Dust(tm). Now we have LLMs that are generating designs and prototypes in Figma and similar tools. There's those companies pushing "Synthetic Users" to "increase velocity" in user research by getting rid of the slowest, recruiting part of things. UXR teams under increasing time pressure start leaning heavily on LLM summarization and synthesis features. People keep trying to build natural language BI tools. The market is increasingly flooded with these "Confirmation Bias with Extra Steps" tools.

In my opinion, the main reason why UX team after UX team is riding this flaming clown car straight to burnout is because UX teams generally don't hold very much organization power. Engineering owns the machinery and process that creates new products and thus attracts customers. Product usually owns the responsibility for revenue, profit, and where to invest resources. If either of those groups, the "what we're building" and "who does the building" decides to pack it up and go home, all launches stop.

Meanwhile, many UX teams are told they're "an equal partner" but UX usually told to represent "the voice of the user" – there's no actual power inherent to that position. The power is the what is earned through persuasion and the willingness of other teams to listen. Features will keep shipping if all of UX decides to quit en masse. The releases might be the ugliest, most user-hostile and confusing futures ever to cross the build servers, but release they can.

Velocity meeting "wtf are we doin'?"

The running gag with UX researchers who get frantic unsolicited requests for research from folks is that we always have to stop and get them to articulate what the actual research question is. For better or worse, in the face of "increasing velocity" we have to do the same thing – ask what are we even trying to do?

I don't have the answer as to how to stem the tide of teams increasingly wanting "insights yesterday!". That's a question for someone with significantly more EQ than I've got. I do know that it involves forcibly carving out enough mental time to stop from the constant grind to look critically at what's going on, because inevitably the majority of the work isn't going to be magically aligned with the most important stuff to users. Because most users aren't able to give their feedback in a way that can be heard and processed by an organization – distilling that voice out is our job and if we don't do it, no one will. If doing that job means carving time out from the feature mill grind, then that's what has to happen.

What, a chip on my shoulder, you say? I have no idea what you're talking about.

If anyone has had success pushing back on this, I'd love to hear ideas because ughhhh.

Subscribe!

Standing offer: If you created something and would like me to review or share it w/ the data community — just email me by replying to the newsletter emails.

Guest posts: If you’re interested in writing something, a data-related post to either show off work, share an experience, or want help coming up with a topic, please contact me. You don’t need any special credentials or credibility to do so.

"Data People Writing Stuff" webring: Welcomes anyone with a personal site/blog/newsletter/book/etc that is relevant to the data community.

I’m Randy Au, Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. Counting Stuff is a weekly newsletter about the less-than-sexy aspects of data science, UX research and tech. With some excursions into other fun topics.

All photos/drawings used are taken/created by Randy unless otherwise credited.

randyau.com — homepage, contact info, etc.

All Tuesday posts to Counting Stuff are always free. The newsletter is self hosted. Support from subscribers is what makes everything possible. If you love the content, consider doing any of the following ways to support the newsletter:

Consider a paid subscription – the self-hosted server/email infra is 100% funded via subscriptions, get access to the subscriber's area in the top nav of the site too
Send a one time tip (feel free to change the amount)
Share posts you like with other people!
Join the Approaching Significance Discord — where data folk hang out and can talk a bit about data, and a bit about everything else. Randy moderates the discord. We keep a chill vibe.
Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!