Melissa Perri on State of AI in Product

I've long been convinced that AI focus needs to be balanced and look at the processes upstream of sw development. There's incredible potential to improve product and strategy work and very little evidence of any effort going into it. This isn't entirely OpenAI or Anthropic's fault. Product work requires crossing organizational boundaries, querying fragmented tooling, talking to people, and continuously defining and refining strategy. None of this context is readily structured for an AI model to consume; it remains siloed, undocumented, or locked inside people's heads.

Melissa Perri talks about this (and other topics) in the latest episode of her Product Thinking podcast. The most interesting part is just 3 minutes into the episode (emphasis mine):

[...] "Delivery of designs and code got very fast. Delivery of good decisions became the new bottleneck." Now, I don't think this bottleneck is new. It's exactly what I talk about in the build trap. What I've been seeing is that AI has now just made that build trap bigger. We can deliver more code faster.

We've got more prototypes that can be made faster. But what are we building? Is it being used? Those upstream issues have always been the issues, and AI is not making them better for now. Hopefully, in the future, we have things that can actually help with it. But for now, sometimes it's actually making it worse.

Luca Rossi recently interviewed Anush Elangovan, VP of AI Software at AMD who argued that speed is the only moat. Speed certainly matters, but direction matters more: are we running faster towards a cliff or away from it? This is precisely the awareness and context that is currently constrained as mentioned above.

The second part which reinforces another belief I have (and can see every day at work) is:
AI is a multiplier, not an equalizer

continuing from the example above: if you're running in the wrong direction, you're now running faster in the wrong direction. Arguably, not better than before.

In engineering, teams already operating as elite DORA performers are the ones positioned to compound their lead. If your release cadence is quarterly, writing code faster does not move the needle (a fundamental lesson from Goldratt's The Goal). In product management, organizations with established discovery and validation practices will see their effectiveness multiplied, while dysfunctional teams will just generate noise at scale.

The only place where AI functions as an equalizer is at the individual baseline: an entry-level practitioner (developer, product manager, security engineer) armed with LLMs can reach passable baseline competence far faster. The hard questions then become operational: how do we screen for candidates who use AI to reason versus those who merely parrot its output, and how do we systematically train people to make that transition?

Popular posts

Opengrep quickstart

Since I could not find a quickstart to run opengrep with the full set of rules from their fork I thought I'd document what I found out. Setup Download the opengrep binary from github and make it executable with chmod +x . Clone the rules repo: git clone git@github.com:opengrep/opengrep-rules.git and clean it up to make it usable to opengrep: cd opengrep-rules rm -rf ".git",".github",".pre-commit-config.yaml", "elixir", "apex" find . -type f -not -iname "*.yaml" -delete rm -rf .github rm -rf .pre-commit-config.yaml Ensure opengrep can load the rules with: opengrep_manylinux_x86 validate . The same can be done for custom rules maintained in a separate repository. AFAIU Multiple repositories can be specified by repeating -f option as needed, see below. We are now ready to scan a repo, from the repo root directory run: opengrep_manylinux_x86 scan \   -f <path_to>/opengrep-rules \   --error \   --exclude-rule=VAL some ti...
Read more

NGINX stream module with dynamic upstreams

NGINX has had support for dynamic upstream modules for a while in the community distribution and examples abund. I think this is probably one of the clearest I could find. Finding a similar config for stream proxies turned out to be surprisingly hard, so here I'm sharing my solution in the hope that it can be useful to somebody. Or someone more experienced can point out a better alternative. In my case my upstream is an ELB which can and will change ip address often so using the static DNS name was not an option.
Read more

Mirth: recover space when mirthdb grows out of control

I was recently asked to recover a mirth instance whose embedded database had grown to fill all available space so this is just a note-to-self kind of post. Btw: the recovery, depending on db size and disk speed, is going to take long. The problem A 1.8 Mirth Connect instance was started, then forgotten (well neglected, actually). The user also forgot to setup pruning so the messages filled the embedded Derby database until it grew to fill all the available space on the disk. The SO is linux. The solution First of all: free some disk space so that the database can be started in embedded mode from the cli. You can also copy the whole mirth install to another server if you cannot free space. Depending on db size you will need a corresponding amount of space: in my case a 5GB db required around 2GB to start, process logs and then store the temp files during shrinking. Then open a shell as the user that mirth runs as (you're not running it as root, are you?) and cd in...
Read more