Teams own problems, not products

a coworker told me today that "teams should consider themselves as owning problems, scenarios, or use cases, not owning products"

because products, languages, etc., can be transient, but problems generally aren't

and I can't stop thinking about this observation / framing

@DynamicWebPaige, 2021-05-12

This tweet has been stuck in my mind since I saw it, and I've tried to keep this in mind as my job, career, company, team, etc. has changed since. Three different jobs, X different teams and Y different managers, and a desire to adjust my career as I see it fit myself better, and this framing has helped me a ton.

I think that it is sometimes easy to conflate problems and products in the industrial space because they can be tightly coupled, especially early on in development. A team is spun up or created usually under a product umbrella so that something can be delivered to the customer. As the team learns more about the problem space, the product evolves until a point where it might not reflect the genesis of the product itself.

This is maybe a little bit like the Ship of Theseus where you keep changing the "product" to match the problem such that over time none of the original "product" remains. You're still solving the same problem, so focus on solving that versus building a product. If you need to tie a name to it, sure, but really focus on the underlying problem. The technical artifacts you create should support solving that problem for the oeprator.

Security sometimes forgets this, including in the TD&R space where SIEM is the product that gets sold. When the job-to-be-done is reframed (like in Cybersecurity First Principles) to instead focus on what the security operator is trying to do (reduce the material impact from a cyber incident), then the TD&R space shifts to have a much higher requirement on the response or mitigation side, and automating this facet of the work. Eric Olson's BSidesNYC 2023 talk matches this as well, where the exec cares about two main things: how long were we compromised, and how long did it take to get back to "normal"? Those timings reflect the underlying problem of protecting the company and reducing the harm caused by a compromised through the proxy of increased time is increased (potential) damage.