franciscassel

Taken from the same blog:

"Roughly, RAG is runtime prompt engineering where you build a system to dynamically add relevant things to your prompt before you ask the agent for an answer."

Have you considered a land-and-expand rollout, where you focus on getting an active community going in one or two cities before you expand? Otherwise, folks from underserved cities (which will be most of them) will be disappointed when they try to find interesting meetups near them using your site. Just a thought!

Spoilers:

"But the impact has actually been fantastic. Some highlights: - ~$1m of sales pipeline generated in 3 weeks, ~$100k already closed - ~10% of the free customers converted to paid - ~50% of the paying customers converted to the new pricing model"

Following the logic in the article: it's not actually a good outcome for the business when "Your QA people are the only ones charged with being an organizational conscience on the behalf of your users." To your earlier point, quality is something the entire team has to commit to.

For sure. For me, the best (worst) sign of 'not proactive enough' re: quality is too many embarrassments and/or hotfixes happening.

In my experience, many orgs that work with Selenium and its derivatives have described that (coded) approach as flaky / brittle (i.e., fragile).

Of course, until automation gets to be as clever of humans, any test automation approach is going to have some flavor of brittleness.

Totally agree that automation will never fully replace the value of human-powered testing. (Though it is great for the rote regression-testing stuff. The "drudgery", as you put it.)

Isn't the problem with relying too much on unit and integration tests that they don't consider the end-to-end app experience? (Which, in my mind, is what ultimately matters when customers think of "quality".)

Yeah, the good ones really care about the product experience and customer outcomes, so this makes a lot of sense to me.

But what do you mean?

When I was a PM, I was lucky to have a big, talented QA team, but I still knew I'd have to do a "smoke test" myself after every major feature release. I cared the most, and I knew the most about the intricacies of the product.

I've been on teams where the "siloed" QA model seemed to work pretty well -- we seemed to find a decent balance between test coverage and frequency of releases.

But this was at a cash-rich startup that had lots of money to spend on making sure we had plenty of QA headcount. That seems to be the exception, rather than the rule. Lots of startups I talk to are quite constrained in terms of dedicated QA, so the argument for empowering product managers to own quality does make some sense to me.