FOXHOLE

I had a chance to lead two discussions last week at an innovation conference organized by Pitney Bowes.  One session was on how development and product management can work better together.

I like to start such sessions with unfiltered comments from development managers about their (good and bad) experiences with product managers. Typically, these include more disappointment than elation… which gives me a chance to recap the critical parts of the product job that development teams don’t see: product managers keeping in touch with the market through constant interactions with customers / prospects / partners outside the sales cycle; and “buffering” the hourly interruptions that come in from sales teams and executives.

It’s all about building and shipping great products, not getting hung up on title or roles.  About understanding how each person (or group) contributes.  And constantly collecting critical customer inputs so that we build what the market wants (= will pay for). We’re in this foxhole together.

I closed with some suggestions for each group:

Six Ways Product Managers Can Help Their Agile Dev Teams

1. Be humble

  • Product Management isn’t the source of most good ideas.  It’s great to have an MBA, but don’t be an MBA.

2. Show up for sprint planning, reviews, retrospectives, demos

  • Be part of the team, get the right thing built.

3. Summarize and share lots of customer interactions

  • Dev should see PdM as a continuous source of curated market input.

4. Buffer Dev teams from urgent/chaotic/irrational interrupts

  • True sprint-busters are very rare. Signal-to-noise in the market is very low.
  • Share how Product filters selected Sales and customer demands.

5. Run the financials with the team

  • Tie work to revenue. Success is motivating, dollars matter.

6. Map and size market segments

  • 
Not all users are equal, and our showcase customers are never representative.

 

Six Ways Dev Teams Can Help Their Agile Product Managers

1. Don’t demand product managers as technical as your developers

  • Different roles, different needs, different skills.  If we’d wanted to be developers…

2. Ask to see customer lists, forecasts and revenue numbers

  • This is what the rest of the company really cares about.

3. Expect your PdMs to translate complex features into simple benefits

  • Most users don’t actually care how that algorithm works

4. Not every user story gets its own ROI

  • Diminishing returns, and rarely meaningful for smaller items

5. QUIETLY sit in on some customer meetings

  • Rule: Don’t speak a word unless your product manager
    specifically requests it.  And only “yes/no” answers to “yes/no”
    questions.

6. Help lobby for sufficient, relevant, passionate product manager/owner talent

  • Successful products need great tech and great market fit

Comments
  • Bennett Barouch Reply

    Both of these are good lists. I am surprised by #3 in the second list though. A chronic problem at the companies I have worked at is that PrdMgmt is often overly focused on feature details and virtually mute on value delivered to end users. So, I agree with these lists, but I am curious of PrdMgrs really agree with that request in particular being made on their behalf here. A proof on this would be if the value is delivered and PrdMgmt does not then introduce new requirements on the details of what it looks like and how it works. I don’t want to get too far beyond what we can cover in a comment, but my experience is that we need much more PrdMgmt input on value to deliver, much les on details on implementation, and much more and much earlier interaction on those aspects of appearance and functionality tht do matter to PrdMgmt.

  • Geoffrey Anderson Reply

    Very good post, and lessons I learned early on. Particularly the one about sharing the revenue and financials with the dev team (and one that makes my boss cringe). They deserve to know what their work means to the company, and there is no better way than to see the dollars and cents if brings in.

  • Greg Gehrich Reply

    I really like your term “curated market input”. It goes to the heart of a great product manager–filter the crap, communicate customer value and things that keep the team engaged.

  • Sorin Alupoaie Reply

    Most of this makes sense, just few comments. I think it’s a good idea to have an overlap in understanding (not responsabilities) of each other’s domain for both engineers and product managers. Engineers should be encourage (and preferably trained) to communicate with a customer and also to understand the customer needs and the market their application is serving. Also product managers should be encouraged to understand the technical underpins and challenges of a product they’re developing. Therefore I strongly disagree with #5 from list 2 and I don’t think creating separated silos of competence is a good idea in this case. Engineers should be able to communicate with their customers and understand their needs.

    • Rich Reply

      Sorin: I agree in theory, but get stuck on “should.” I’ve personally run meetings with developers who are clueless about appropriate interactions with (paying) customers, and we want to avoid real-time public etiquette lessons. So when I bring developers into their *first* customer meetings, I try to lay out unambiguous behavioral rules:
      - DON’T say anything is “easy” or “trivial” or can be in the customer’s hands within a week. Don’t promise anything.
      - DO ask clarifying questions about the problem/issue, and alternate solutions
      - DON’T talk badly about our product or the competition
      - DO thank folks for being customers and sharing their time with us
      - DON’T lean over and “show” the customer how to do something (unless the prodmgr specifically asks)
      - DON’T offer to do follow-up research, build sample code or send user doc snippets (unless the prodmgr specifically asks)
      Etc.

      Our goal is to plan for first-time-with-customer excitement and nervousness, avoiding accidental corporate commitments or loud disagreement in public. Consider this “charm school” if you like.

      Devs (and everyone else) who have been in lots of customer/ prospect meetings already know this. Newbies may not. It’s a responsibility of product managers to choose attendees wisely, and mentor inexperienced before bringing them in.

      After which, engineers *should* be able to communicate with their customers and understand their needs.

  • Kellie Jones Reply

    My 7 on the list for product managers is for us to define the what and not the how. The development team I work with continues to surprise me with creative ways to solve things – in a better way then I could have imagined. A favorite recent post on this topic is: http://under10consulting.com/2013/02/27/user-stories-vs-user-goals/

    • Rich Reply

      Kellie: probably should move yours to #1. And love that Ed Brown guest post on Steve’s blog.

  • Rich Reply

    BTW, I had a seventh for each list:
    - Product managers should end-of-life a few hundred products and free up a large fraction of the development staff for meaningful work
    - Devs should never say “Just find out what the users want.” It’s the equivalent of the non-dev’s “How hard could it be? It’s probably only ten lines of code.”

  • […] the Product Owner role is extremely noisy and tactical and requires a lot of day-to-day interaction with Development in daily standups, sprint planning sessions, and retrospectives.  While there is nothing wrong […]

  • […] the Product Owner role is extremely noisy and tactical and requires a lot of day-to-day interaction with Development in daily standups, sprint planning sessions, and retrospectives.  While there is nothing wrong […]

Add your comment

Your email address will not be published. Required fields are marked *