It’s “What To Do,” not “How To Do It.”

So I leading a meeting as a product manager, at my big Internet search/media/life-engine company, and I am trying to brainstorm requirements with two engineering managers for a new project. I have heard many times before that I should never, in such meetings, tell engineers how to do something, and rather leave them with a sense of what needs to be done, so that they can figure out how to do it on their own.

This is sound advice because engineers, being engineers, love figuring out how to do things. Never get in the way of an engineer and his/her solution; they treasure it as their own as a sale-hunting shopper would the perfect dress that is marked an additional 50% off. Yet, I was foolish enough yet again not to follow this advice, and started offering solutions in the meeting.

What I realized later is that it’s not that I am wilful or impatient, but that I really do have trouble internalizing this piece of counsel. I can’t instinctively draw the line between requirement and solution, and frequently make the solution part of the problem. For example, on this occasion, the requirement was fairly simple — what service-level agreement the new system was to provide. Instead of asking the engineers that they agree to putting some SLA on the roadmap, I went on to suggest ways to provide different SLAs — perhaps we could allow for users to plug in their own hardware, I said, or alternatively, we would worry about that entirey on our own and implement a resource allocation algorithm. It took a gentle smackdown from both engineers, before I realized that it was not in my place to provide these solutions.

I figure part of the reason I do this is because I have been an engineer myself, so it’s hard to shake off the habit. The other half of the explanation lies in something else that goes on in my brain, which is that I don’t quickly understand the hierarchy of requirements. In any product, or product development process, some requirements come before others. Higher requirements must be understood first, and in attempting to implement these, lower-level requirements will surface. Attempting to incubate the lower-level requirements ahead of time is usually counter-productive — the higher-level requirement will be malformed at birth, and the lower-level requirement will probably be still-born.

To return to my post-mortem of the meeting, the higher-level requirement was the provision of an SLA. It’s possible that once we start implementing an SLA, we’ll find ourselves strapped of resources to offer a reliable service to all our customers, and that I will then have to insist that we make the system capable of plugging in dedicated hardware provided by customers who are willing to pay their way to better service. However, that is a bridge that I, as a product manager, will have to be patient, and prepared, enough to cross when we come to it.

Advertisements

One Response to “It’s “What To Do,” not “How To Do It.””

  1. virk Says:

    Good practical post.

    Its very common in requirement gathering phase to jump to HOW from WHAT. It takes many attempts to do level setting that its requirment collection not the product design phase.

    You presented you thoughts very well.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: