I sometimes find product management teams composed entirely of first-timers, where not a single person has any previous experience as a product manager. This presents a fundamental challenge: how do we train or skill up a whole product team from scratch?
Every CPO/VP Product I talk with is in a battle for product talent… so we’re in a “candidate” job market rather than a “hiring company” job market. What are some do’s and don’ts for product managers and first line product directors looking for their next adventure in this market?
There’s a pattern I see, especially at enterprise software companies, where the go-to-market materials present a glowing product picture – but underneath there’s a jumble of mismatched pieces, arcane product history, incomplete testing, and randomness. I call it product sprawl.
Most of us don’t get much practice resigning from corporate leadership positions, but it’s important to do this gracefully. Plan it the way you’d plan your next product: clear communication, succession plan, helpful transition. And be a mensch: you’ll be working with many of these people again.
Many companies have replatforming efforts underway. This is an essential part of the software product business, but fraught with poor assumptions and lack of experience/understanding. I’ve seen the majority of these replatforming and reimplementation efforts fail…
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.