Corporate product development

There’s this strange thing about developing corporate software products in-house. Commitment tends to be lower and slipping projects or well, generally accepted. Projects tend to be slipping all the time because the internal client doesn’t have to pay any hard cash to the internal “sponsor” for any last-minute additional changes. Nevertheless the sponsor keeps nagging to deliver projects on time.

So saying no to scope creep is really important, even though the business guys keep requesting new changes. This is why the following part of a The Next Web article on good product management resonated so hard with me:

2. Prioritize ruthlessly
PMs help prioritize the development calendar for engineering, and to do that you need to have excellent organization skills and the ability to make difficult trade-off’s quickly.
Back when I worked at Yahoo, we once had to decide on a painful feature tradeoff 24 hours before a huge product launch. I had a lot of influence with the team, and wanted our engineering resources to focus on a near-complete feature I felt was key for our differentiation. The PM on the team wanted to cut it, even though we’d invested tons of engineering hours into the feature already.
He changed my mind by explaining why minimizing the risk associated with this particular feature was critical to a successful launch, offering a creative plan for communicating the change in scope to the team while maintaining morale and excitement for the launch, and proposing we include this feature in the next earliest release post launch. I learned a lot from his ability to ignore the noise, focus on the most important issues, and stand up to me for what he felt was right (and he was absolutely right).

The problem often is of course to decide on what are those most important issues. Most of the times the client keeps changing that list. Standing up is a very hard problem too, even though saying “no” is quite easy.

I can highly recommend reading the article as it’s quite complete on the product development job description.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.