We know that external customers must recognize a problem before they consider buying our solution. But I often see product managers / product leaders forget this when dealing with internal stakeholders and executives. We push for product-side practices and processes without clearly framing the underlying problems. I think of this as ‘selling philosophy.’
Product management work is much easier when the product team is well-respected: when stakeholders believe that we’re smart and hard-working and good at product stuff. So an under-appreciated skill of product leaders is merchandizing good product work and good outcomes from our teams.
What does that look like?
Company leaders who aren’t steeped in how software is designed and built can apply less-than-useful analogies for how software products are built. These analogies tend to highlight predictability, scheduling and cost management… but may not be that useful. This post unpacks a few of them.
Everyone wants innovation, especially if we can plan and schedule into each sprint.
But innovation is uncertain. Can we shift the discussion to planning and scheduling and funding of discovery that can (often) lead to innovation?