Development: Leave Us the $Foo Alone!

Jeff Lash has a good post up about Delegating. There are some interactions you need to have – like regular tradeoff meetings with Development. As a general rule, programmers hate meetings. A lot of that has to do with the fact that prior to you, they had some “Marketing” airbag pull them into blahfests about “sustainable competitive advantages” and how we can get a that feature to “go viral.” Now meetings from Marketing (and by proxy Product Management) are dismissed as a waste of time.

Lead Architects in are alpha dogs. There’s only room for 1-2, otherwise they start to piss on each other’s territory and talk about how so-and-so isn’t pulling their weight or how they had to clean up the other’s code. Design planning and software requirements are viewed as nice-to-have’s, and often as Product Management you’ll find yourself in a situation where you’re bringing requirements to Development only to hear “Oh yeah, I heard you were working on that so I already built it.” Great! It’s done, on to the next feature…uhhhhh, no.

What you’ll find is that you got a half-implementation based on:

  1. What was easy for the developer to do over the weekend
  2. What was interesting for the developer
  3. What is based on the developer’s (incomplete) interpretation of the customer’s problem

When you push back on the implementation you have to do it gently to avoid bruising ego’s. Engineering’s usual M.O. is to say “this is what we’re offering, to do your (complete) implementation will take<$ridiculous_timeframe>.” Besides, who is going to call B.S. on the development estimate – they’re the one’s making it! Fox, meet hen house!

There are two ways around this problem. First you need to have the fortitude to call Engineering’s bluff. If you get a time frame of 6 additional months, say “OK. That’s fine. I’ll need to see a detailed schedule so we can determine what resources we need to hire to help you.” If the full implementation is that important, you should be able to drive a business tradeoff to get the resources to make it happen.

Second, you can avoid the problem in the first place with proper planning. Once you approve a product onto your Release Plan, form a Core Team and pull the lead developer onto it. He/She will grumble about the meeting but stay firm – you need the Core Team to drive tradeoffs and get ahead of the prototype that they’re going to build.

Often, Developers project verbal and non-verbal signals that meetings are inefficient uses of time, that they don’t need to be there, or that they could be doing “more important” work. Basically they are saying: “Leave me the F alone!” I’ve found that they feel that way because they don’t interpret their time as valued by Product Management or Marketing, or they don’t feel like PM has a good handle on the tradeoffs that need to be made. Whenever I get these signals from a Developer, these are my tactics:

  1. Be sure to start the meeting with an explicit statement about why we are here, what the goals are, and the expected output of the meeting
  2. If you start getting verbal or non-verbal signals from a Programmer (disinterested, checking email, sighing, rolling eyes, pacing around the room, etc), stop the meeting immediately and address the issue – “Joe, I keep hearing you sigh and roll your eyes, do you understand why we are here? Do you understand why we need YOU here? Is there something else that you need to be doing at this moment?” I’ve actually been in meetings where the developers had stopped working on a critical hotfix, without telling us that we were holding up their work, and were glaring at PM for running the meeting! Enable people to have a voice, because they might not speak up…
  3. If Joe agrees with the purpose of the meeting and his role there, and is still offering bad non-verbals, actively engage him with open-ended questions, much like you’d do on a customer interview.
  4. After the meeting, follow up one-on-one to talk about the importance of the design and tradeoff process, emphasizing that a good design solves a more complete problem set and reduces wasted work in Development. The only thing Developers hate more than meetings is doing work and having it go to waste or get mothballed.

…because it’s Friday, here’s an Office Space clip that always makes me think of Product Management and grin:

Previous Post Next Post


  • Reply Susan Lim April 26, 2008 at 1:03 pm

    Hi Paul, just want to share this about product meeting….

    In one of the product meeting I attended last time in a company where Product Management role is new, I sat in the meeting with teams from development and sales (both international and local). I was new to the company and I was supposed to help kick off the product management team (that’s why I was invited to the meeting). There were 3 vice presidents from sales and development and around 5-6 managers attending the meeting.

    It was supposed to a discussion on the product roadmap. The meeting started with waiting for more than half an hours for some sales VP & managers because they are obviously busy with customers. Thus, they filled in the time discussing about previous issues (about a product evaluation) that was not settled and seemed like not going to be settled in the near future. Well, obviously, there are no conclusion because they just discussed it for the sake for filling in the time while waiting. When the waiting was over, we went through a list of requirements from different customers. We went through the list one by one (some requirements was like a special report from customers) and decided together whether the requirements add to the value to the product (means can be used by other customers or a good sell point) or not. This is acceptable except I felt funny that this task need so many VPs and managers to get involved. But it was good that everyone important to the product are present to trash out all issues.

    Then, the development team announced there will be rolling out version 4.0 in a year later and most of the resources will be tied up. So , any changes to version 3.x would be scaled down to the minimal. Of course, this is unacceptable to the sales team, which as normal, all the requirements from customers are considered urgent. I agreed that version 4 is not really convincing to the sales teams due to the reason they are no one in the room that knows what will be in version 4.0 but one thing for sure is that the developers are going to rewrite the software in the latest programming language framework (something like using VB .NET instead of VB). Eventually, two directors of the company joined our meeting to make the decision. They agreed that version 4.0 will be developed and rolled out in a year and most of the customer requirements will not be fullfilled unless it is an important one. The sales teams are to communicate to the customers that a newer version which will be rolled out in a year , will have the almost the SAME features, but with better architecture or flexibilities to fullfill their requirements. For e.g. any new report they need now may take around months to fullfill, but with version 4.0, it should takes maybe 1-2 weeks. That make it worth for them to wait and “probably suffer” for a year or so in the current version that may not fullfill what they need. But it is only a year, right? Well, that’s probably alright also,except after a year, the development team will come back to say they need an extension because they are so keen to deliver a great product this time that they underestimate some of the things. When the product was finally released to the customers after the delays, the promise that requirements will be fullfilled faster than previous version was not really delivered because the development team is busy fixing new bugs and problems that come with the latest version.

    Anyway, that was the most inefficient meeting that I ever had in my career life. Because I never seen so many top management team gathered around and decided on something at such a high level that nothing was actually achieved.

    I suppose that is why it is important to have a product management team rather than to let everyone (development, sales,etc.) to decide together on the product roadmap but no one to take responsibilities.

  • Reply Scott Ryder May 1, 2008 at 6:38 pm

    Good post. I like the approach of getting the dev leads involved in both the selection of items for a release and the marketing definition of those features. I’ve found that when they get involved at this level a couple of things happen:
    – They gain an understanding of the complexity involved with the decisions. This opens their minds to the fact that their view is not comprehensive and they gain appreciation for how much PM is buffering them from all of the information gathering. (note: I would never have Sales and Engineering at the table for a release contents meeting. A primary function of PM is to gather the various inputs and sort through the needs before presenting them)
    – Ownership is build out of being part of the decision. I can’t put enough emphasis on this. If a Dev Lead has a view into why something was selected and actively or tacitly participated in the decision, the PMs job is going to be a lot easier.


  • Leave a Reply