Archive of the PRODUCTHEAD newsletter, a regular newsletter of product management goodness, curated by Jock Busuttil (@jockbu).
» Conversational programming changes the nature of the developer job, but doesn’t do away with it
» Describing needs and context is more valuable than giving instructions or requirements
» There are 3 reasons why a discovery should end:
1. It is purely performative
2. Ignored / unknown context
3. Unconnected to value
» Everything on your product roadmap should have lots of context that is easy to find
» By reinstating Sam Altman, OpenAI has chosen financial success over its altruistic principles
» When Steve Jobs left Apple in 1985, the board believed he wasn’t ready to be CEO
» Google was quick to fire ethicist Timnit Gebru when she challenged its lucrative search advertising business
» Product models are more scalable and have higher investor valuations than service models, but can be more difficult to implement and require a longer sales cycle
» If you find your team is biasing towards delivering custom features (= output), refocus on discovery and problem solving instead (= outcomes)
» When designing an experiment to test a hypothesis, ask how might it fail, and what you need to find out
» Luck and uncertainty mean that even good decisions can have a bad outcome (and vice versa)
» Framing our beliefs with a confidence percentage makes us more willing to accept contradictory evidence
» Anyone can access generative AI, so simply using it is not a competitive advantage
» SEO has long sought to game search engine rankings; AI provides a new tool for doing so
» LLMs trained on AI output become increasingly detached from reality: “model collapse”
» We can and should measure discovery activity and its impact on the team and users
» Discovery cycle time and cadence are critical to adopting a continuous mindset
» Avoid vanity quantity metrics such as number of research activities; measure quality instead
When sunsetting a product or feature:
» Explain why honestly and be transparent about how it will impact your users
» Be understanding as they may be disappointed or frustrated by the change
» Be responsive and supportive by answering your users’ questions and helping them with the transition
» If possible, offer your users alternative features or solutions
» Context helps to make a service good as opposed to simply existing
» By not consciously designing our services, we instead force our users to link actions together
» Outcomes for users are core user needs that a service helps them to meet
» A starting point can be to ask different teams what ‘good’ looks like to them
» Rather than focusing on engineering team productivity, examine the causes of their low / negative value work
» When asked for development estimates, ask why they need the information and what they’ll do with the answer
» Different development tasks need varying amounts of user story detail
» Treat your developers with the same thoughtfulness as your users
