As product folks, we should be responsible for reasonably anticipating misuses of our products, as well as harm that flows from fundamental product/economic goals. It’s not clear how we step up to this, though.
This podcast on Creating a Thriving Product Organization covered a lot of ground: becoming a product leader; what to do in your first month on the job; conditions that enable product teams to be their best; and Impostor syndrome.
Restructuring product management teams is challenging: there’s no universal “best practice” or generic org chart, and people issues are the tough ones. We step through two examples of redefining what product folks do…
Synerzip webinar for product managers (and others) with tips for working with data scientists and DS/AI/machine learning projects.
How do we provide additional context? Understand possible failure modes? Define “done” operationally rather than academically?
Product managers working with data science teams on production applications have more challenges than with more deterministic (traditional) applications. These include providing more business/user context, not assuming that data will be predictive, and discussing accuracy requirements at the very start of a project.
Wide-ranging conversation about product leadership, how product management has evolved, validation ahead of building, teleportation, scaling up product management teams, and working with non-product executives.
There are some inherent mis-alignments among internal stakeholders that can complicate enterprise product planning and roadmapping. How do we understand these systematically instead of as personal confrontations?
Software is intangible: it doesn’t have weight or size or per-unit manufacturing costs. But if we’re in the software business, we have to assign units and prices that reflect our value to customers. And we should be mapping out pricing strategy before we start development, not the day before product launch.