product-management   2550

« earlier    

Production Oriented Development - Paul Osman - Medium
Engineers are the subject matter experts for the code they write and should be responsible for operating it in production. In this context, “operating” means deploying, instrumenting, and monitoring code as well as helping to resolve incidents related to or impacting that code. The responsibility of operating code aligns incentives — it encourages engineers to write code that is observable and easy to debug, and connects them to what customers care about. It encourages them to be curious about how their code is performing in production. Importantly, engineers should be on-call for their code — being on-call creates a positive feedback loop and makes it easier to know if their efforts in writing production-ready code are paying off. I’ve heard people complain about the prospect of being on-call, so I’ll just ask this: if you’re not on-call for your code, who is?
webdev  software  programming  product-management  HN 
yesterday by 1luke2
Good Experiment, Bad Experiment — Reforge
Good experiments advance product strategy. Bad experiments only advance metrics.

Good experiments are built around product themes. Every good experiment furthers the product team’s understanding of the customer and her needs. They build on each other, creating insight and depth of understanding in an area. Bad experiments are scattered, one-off tests that stand alone. They come from unfocused brainstorms that result in not being connected to the product vision or a growth strategy.

Good experiments drive impact by solving real user problems. They have strong, well-reasoned hypotheses grounded in data analysis, customer insights, and market research. Good experiments are about understanding true customer behavior around the things that matter. Bad experiments move metrics by confusing or tricking your users. They make things harder for your users, rather than solving underlying problems.

Good experiments are conceived as bets.
abtesting  product-management 
3 days ago by 1luke2
12 Signs You’re Working in a Feature Factory
I’ve used the term *Feature Factory *at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”

heh, this rings a bell....
features  product-management  agile  teams  work  management  product  companies  prioritization  planning 
7 days ago by jm
Roman Pichler, Tools
Various A4-based tools for working out your product ideas (e.g. vision board, business model canvas, persona template)
product-design  product-management  tools 
12 days ago by MGallagher

« earlier    

related tags

!great  2020  abtesting  advice  aesthetics  agile  already-read  architecture  b2b  bestpractises  bounded-context  business  career-development  cba  collaboration  communication  companies  complexity  conferences  culture  data-science  ddd  design-advocacy  design-systems  design  development  diagram  discovery  early-adopters  engineering  eux  event-storming  evidence-based  experiments  facilitation  features  flow  hiring  hn  jess-eddy  jobs-to-be-done  kpi  kpis  leadership  lean  management  measurement  melissaperri  metrics  missions  music  negotiation  north-star-metric  notifications  org-design  os  phil-libin  planning  pm  podcast  practice  principal  prioritisation  prioritization  process  product-design  product-development  product-manager  product-owner  product-roadmap  product-strategy  product  programming  project-management  push-notifications  quality  research  ressources  roadmap  roadmapping  role  saas  slack  slides  soft-skills  software-development  software  spotify  startups  state-machine  stats  storytelling  strategy  synthesis  team-alignment  teams  teamwork  technology  templates  thought-provoking  tips  tools  user-research  ux-design  ux  video  web  webdev  weekly.rc  work  writing 

Copy this bookmark: