Steve Johnson on affecting transformational change in product management

Meet Steve Johnson , a product management veteran who helped develop and lead training for the Pragmatic Marketing framework. Steve is now a founder and principal at Product Growth Leaders, providing tactical and strategic product management training and coaching.

This is #3 in a series of posts to introduce you to exceptional people in my?#productmarketing?and?#productmanagement?network available in the talent pool.?

I asked Steve “There’s lots of training and frameworks for modern product management. How can you best implement them in established organizations? What key things you can do to influence peers, direct reports, and leadership to ensure product management training can affect transformational change?”

?Here is a summary of Steve’s responses.

?1 – Change is easier at the department level

At any single company, one team may be dysfunctional, but another may be knocking it out of the park. Often, change happens faster and better at the team level rather than at the company level. And when one team is clearly successful, others in the company will follow.

Empower teams with tools and training. Re-train on the fundamentals despite having seasoned PMs. Even experienced people need a refresher of product management basics. (That’s why Product Growth Leaders focuses so much on “fundamentals.”)??

Continue to take actions and communicate that the job of a product manager is structured, customer-focused, and all about problem-oriented stories.?And continue to move away from the role as “what any other team asks of you that nobody else is doing.”?

2 – Employ a little bit of “civil disobedience” when needed

At the end of our programs, I ask what attendees will be doing differently moving forward. Once, a person, with his arms crossed, answered, “Nothing. My management won’t support any of this.” He shared that his organization wouldn’t fundamentally shift.

I suggested that he start implementing some of the product management techniques we covered without telling anyone. For example, why get permission to begin thinking about and formally researching buyer personas and using them in your day-to-day job? Why can’t you have a regular lunch or coffee with key developers to show openness to having them help you document better problem-oriented stories? Why can’t you share customer discussion summaries with other teams to spur them to think about creative solutions to customer problems? You can impact change and improve your own performance and be a positive example.

3 – Build executive buy-in through pre-and post-training briefings

I have a vivid recollection of an executive briefing before the training that discussed how PM must have direct, unfettered interaction with customers and prospects. The company president (not the VP who hired us) said, “If that is what you are going to teach, then the seminar is off. I don’t want PMs to ever talk with customers without sales in the room.”

This is a minority but not uncommon approach of company leaders who rose from sales — a sales-driven approach that often leads to a reactive “feature factory” company. These approaches can work to an extent, but they require project managers and more development resources rather than market-focused Product Managers. In this case, the VP who hired us stepped up and smoothed things over with the president, and the training continued. ?

This experience exemplifies the ironic challenge I’ve seen in organizations over the past five years or so. They want a transformation but don’t want to change! This is why executive pre-session briefings and post-session summaries of learnings by the participants themselves help show what product management can be, which is essential for buy-in and company success.

4 - Understand peoples’ history and motivation to create better problem-oriented stories?

We teach product management teams and leadership how to better communicate with problem-oriented stories. We can’t have a “here’s the answer” kind of attitude from PM – we need to be open to the skills of the dev teams.?

Our endgame as PMs should be to generate better problem-oriented stories based on market problems that inform solutions that delight customers. By understanding the experiences and approaches of your PM and development staff, you can better align the organization to build more accurate and useful problem-oriented products.?

What are two common patterns we need to address as product management leaders?

• One common anti-pattern is that developers get slapped down too often when they leverage their experience and judgment, which quickly creates trust issues.
• Does it seem that you have developers who just want “specs, not stories” to be handed to them?? I’ve learned that?developers don’t want specs handed to them.? Sometimes, PM teams write such poor stories that a dev team couldn't creatively figure out solutions, gives up, and asks “just tell us what to do.”

At the end of the day, this is people working with people – of all experience levels and communication skill capabilities. This is a leadership challenge: Understand team members’ personalities. ?You don’t want to be an autocratic PM, but you do want to come to the table with a strong experience with customer problems and make it clear that you want developers to take the lead on solutions. You trust that they will come up with great solutions.

5 - Friends build products. Enemies build documents.

When you try to write down everything and anticipate everything in every problem story and pre-judge every solution– it doesn’t work.? For example, even when you write a will, there will likely still be disagreements when it is executed. There are always requirements and realities and problems you didn’t anticipate.

What you should be doing: Describe a customer problem scenario. Have a conversation.

Documents don’t deliver; conversations and relationships do.

?

?

?