Misinterpretation as inspiration A lot of people think dreams and drugs involve some magical inspiration. I think otherwise. I rarely get inspired by dreams or drugs, but I have my own secret source of inspiration: mishearing other people. Somebody says something, I misinterpret it, and the misinterpretation is quite interesting – more interesting than anything I would have come up with on my own if asked to generate an interesting idea. Maybe it’s a clever joke or turn of phrase. Maybe it’s a neat idea. Sometimes I misunderstand people’s entire positions, and end up with positions much more interesting than the ones they were trying to push. Scott Alexander, Negative Creativity slatestarcodex.com Mondegreen mistakesinterestdrugsdreamscreativitymondegreens
Poetic drugs In the final chapters Bachelard lets slip (a confession really) how if he "were a psychiatrist," he would recommend a poem by Baudelaire to treat "anguish." His squabble then is not with the purpose but rather the approach of a still-young profession. And of course, why not treat the power of great poems as something akin to "virtual 'drugs'"? Mark Z. Danielewski, The Poetics of Space psychologypoetrypaindrugs
Doubling Obetrolling didn't make me self-conscious. But it did make me much more self-aware. If I was in a room, and had taken an Obetrol or two with a glass of water and they'd taken effect, I was now not only in the room, but I was aware that I was in the room. In fact, I remember I would often think, or say to myself, quietly but very clearly, 'I am in this room.' It's difficult to explain this. At the time, I called it 'doubling', but I'm still not entirely sure what I meant by this, nor why it seemed so profound and cool to not only be in a room but be totally aware that I was in the room. David Foster Wallace, The Pale King drugsattention
Product vs. Feature Teams An Article by Marty Cagan svpg.com This article is certain to upset many people. Empowered product teamsViability, usablity, feasibilityWhat went wrong? featuressoftwareagile
Empowered product teams When I wrote about the virtues of empowered product teams, I was referring to what I’ll continue to call here as product teams. Specifically, they are cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve.
Viability, usablity, feasibility In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us. However, in a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap. What went wrong? teamwork
What went wrong? If something ships from one of the companies I advise, and it is virtually unusable because of poor design (which as we all know occasionally does happen), you can bet I go directly to the designer and ask how this happened? It is absolutely on the designer to ensure this does not happen, so something went wrong. Similarly, if the product ships and performance is terrible you can bet I go directly to the tech lead with the same question. And most frequently of all, if something ships and the analytics show that it’s either not being bought or not being used, or it turns out that it violates some business constraint like compliance or privacy, you can bet I go right to the product manager with that question. Viability, usablity, feasibility