Recruiting (from Managing Tech)

http://managingtechcartoon.blogspot.de/

Managing Tech: The Dark Side of Social Media

http://managingtechcartoon.blogspot.de/

Biggest Mistakes Orgs Make When Establishing Product Management

Those in my homeland (USA) and from other mature software markets may find it difficult to believe that product management isn't well established in some corners of the world. I now live in Central Europe and can tell you with some authority that product management here ain't what it is back West. Many organizations in these markets are faced with the daunting task of implementing an effective product management function from near scratch. It may be a bit more intuitive to those of us that came up in mature software shops to consider startups that must make the transition from founder-led product definition to proper product management. Regardless of the motive, I've seen multiple organizations attempt to implement product management and have seen plenty of missteps and outright failures. Here are the biggest mistakes I've seen:

Assuming a good technician will be a good product manager
For a variety of reasons, including tight budgets and pressing deadlines, the typical shortlist of candidates for conversion to product management comes from development. What many organizations fail to realize is that just because someone shows impressive leadership in a technical role DOES NOT mean they will make a great product manager. I think about roles in product development in terms of functional and technical perspectives. The former considers products outside-in, the way customers see them; the latter is all about implementation. One of the most difficult transitions that technicians must make when becoming product managers is acknowledging this difference and developing the reflex to let go of the obsession on implementation ("the how") and think deeply about "the why" and "the what".

Not giving PM sufficient autonomy
To create sustainable success, product development organizations must develop a healthy balance between the functional and technical perspectives I just mentioned. Essentially, product managers must be free to reason over what the market needs without unduly constraining themselves with technical viability; this is the basis for much technical innovation. Creating a product management organization and having it report directly to development leaders will, in most cases, compromise this delicate balance, resulting in a technology-led rather than a market-led product development organization. If you decide a dedicated PM organization is worthwhile, give it the autonomy in needs to effectively advocate for the product's stakeholders, including customers. Otherwise, you will create an odd class of custodians instead of true business leaders.

Not setting reasonable expectations across the organization
Product management is an inherently hard job. If that statement doesn't resonate with you, I'm unlikely to be able to convince you of this fact in a blog post. The associated complexity and nuance mean that it takes time for product managers to "find their legs" so they can have maximum impact. During the early phase of establishing the role, product management will need "air cover" from leadership and a bit of understanding and even compassion from the multitude of organizational functions who will come to rely on them. As with any new initiative, it can be tempting to oversell the short-term benefits of establishing product management, setting this team up for failure. Leadership and product managers themselves need to set realistic expectations regarding what they can deliver. The obvious goal should be to continuously improve until PM adds the value its stakeholders expect.

Confusing Product Ownership with Product Management
I've written on this topic before so I'll avoid belaboring it. Product ownership is a role defined as part of Scrum. The Scrum Guide dedicates fewer than 250 words to its description. Product management is a discipline that is decades old and is not methodology-specific. At scale, you'll likely need people in both roles.

Assuming PMs can learn everything on the job in the lab
Product managers need to get out of the lab to develop into mature professionals. They should be spending time with customers, attending training and seminars and engaging with communities. Failure to make these investments will result in PMs that lack the external perspective they need to be effective.

Not inviting an external perspective
Organizations creating or empowering product management can often benefit by consulting someone outside the organization that is familiar with this transition and its pitfalls. This isn't a plug for a long engagement with a high-priced consultant, but a bit of coaching and guidance can easily pay off in the long run.

Have you experienced "the birth" of PM in an organization? What was your experience?

You can learn more about me and how I help organizations with software product management at prickril.com.

Managing Tech: Prioritization Tools

http://managingtechcartoon.blogspot.de/2016/07/prioritization-tools.html

Value: A trickier concept than it seems...

I really enjoyed Ellen Gottesdiener's recent post on value. Although we throw that term around a lot in the product management community, it remains a bit of a tricky concept for many. The key problem is that the value we perceive is often different that the value our customers' realize. Here are a few examples I refer to in my product management classes. I'm not sure about the veracity of the Concorde example, but I find it illustrative regardless.

Examples:

• A survey revealed that people wanted to buy milkshakes in the morning instead of traditional breakfast items because they last longer, keeping them occupied during their commute. [value beyond taste]
• A survey of Concorde passengers revealed that they thought their tickets were much more expensive than they actually were. Response? Raise prices! [greater perception of value than airline assumed]
• Have you ever realized that the time it takes for the waiter to deliver your meal doesn't necessarily go up if the delay goes down? How does it make you feel to have a meal delivered to you just minutes after you order it (we're talking sit-down situation or room service here)? [Some KPIs generate negative value beyond a certain point]
• Many customers value a relationship with a big vendor over superior features and functions from smaller vendors. Frustrating for the "little guy", but true in my experience. [features/functions not as important as security]

Have you thought about what customers really value in your products (or how much they value it)? It may not be what you're thinking.

The trick to discovering customer value is actually talking to customers about value beyond what you typically perceive as valuable. It helps us develop empathy, something for which there is no true substitute. We have a tendency to talk about features and functions (which makes sense), to the detriment of deeper understanding of their problems and perceptions. Although customers use our products' features, they base their perceptions on a broader "customer experience". Are you on top of it?

In a previous post, I suggested a few creative questions you can ask your customers to better educate yourself. Doing a little reading on customer experience is also a good idea.

What are your experiences with customer value? What were your biggest surprises?

For more information on my consulting and training offerings, including a complete online software product management course, please see my site.