Thread by @andybudd

Agile encourages teams to run towards the most obvious solution in order to ship a thing in the duration of a sprint.

Agile provides little time for true enquiry, exploration and understanding. Hiw many PMs would be happy with their team saying “we haven’t shipped anything, but we’ve discovered lots of wrong ways to do it”?

Under the drum beat of the sprint, is it any wonder how few teams think about the ways their products can be abused or lead to abuse. No, instead we bash out the most obvious solution and move on.

As such I’m interested in the role modern product design and delivery practices play in the “unintended” consequences of tech we’re currently experiencing.

The biggest lie of lean is the amount of learning that actually happens. Build>measure>learn? More like build>build>build.

It’s a great defence for product companies and product teams. How could we possibly have known how this product would be abused when everybody was working on a small part and nobody had a clear view of the whole.

This is why I believe companies are often so surprised that their products have been abused, while everybody else looks at the final product and thinks, how could they not have known? When you experience the thing as a whole, with zero time pressure, it becomes obvious.

Now I’m not saying that Agile is bad or broken, but I do think breaking big problems down into small problems, distributing them across different teams and prioritising velocity creates a perceptual narrowing that can’t help but play a part.

Established companies are obviously trying their best to solve these problems by providing ethics training, setting up trust teams, and running red team drills. However this is because they’ve already released things and seen how they’ve been abused.

New product companies are so focussed on shipping their MVP, they often don’t have a good picture of what it actually looks like before it’s ready to launch, and issues of trust and safety only emerge once the MVP has contact with people.