Marketing 101- When the Product Manager Needs to Take Control

Marketing 101: When the Product Manager Needs to Take Control

Last updated: 8/19/2002; 4:06:20 AM

The FuzzyBlog!

Marketing 101. Consulting 101. PHP Consulting. Random geeky stuff. I Blog Therefore I Am.

Marketing 101: When the Product Manager Needs to Take Control

At the request of a reader, I'm answering a real live question. I've opted to write it in an Ann Landers like fashion pretty much for no other reason than to amuse myself (and the one or two readers out there that have ever sneered at an Ann Landers column).

Question : I'm a new product manager, for a product that is currently at, approximately, version 0.4. I'm concerned about scope creep as, every time I turn around, the product seems to sprout a new module or big feature. Or 5. Or 13. It's a difficult situation for me since the lead engineer has more seniority than I do and is, ahem, on the assertive side. I know he knows what he's doing but I want to see this ship before the next millennium. Comments? Thoughts? I've thought about hitting him over the head with a chair but that might not stop him. Help!!!

— Features ^ 13

Answer: Dear Features ^ 13,
You're in a bad situation but not a really bad situation. You've told me a few important things. The first thing that you told me that's important is that you're in a pre 1.0 situation. When you're in this situation, you should understand that there's nothing holding back the engineers. There aren't customers, there isn't a code base, etc. This means that that often will go to town in structuring the application. But, and this is a big but, bear in mind that there is a huge difference between structure and real code. When an engineering team is at the pre 1.0 stage, they will often "stub out modules", essentially putting a place holder there so they a) don't forget about it and b) capture a good idea or ten when they occur to them. This is very, very common – but it doesn't necessarily mean a damn thing. When something is stubbed out there often isn't much if any real code there. This means that little if any time is being spent on it.

The important thing to realize is this:

Real Engineers Ship

If you don't ship, pardon the expression; all that coding amounts to nothing more than intellectual masturbation. As the product manager, your goal is to make sure that your team meets this criteria; that they are "real engineers". What you, as the product manager need to do, is the following:

Define a minimum set of modules for the 1.0.
Negotiate with the engineering team that these are the right modules. They will have their own opinion. And it will be a push / pull, give and take tension. That's ok and its normal. Keep in mind that the engineers have the advantage of being required to think about the problem space in greater detail than the product manager. This means that they have their own ideas. You have the advantage of thinking about this from the customer and market perspective.
Put the list of modules for the 1.0 in writing.
Negotiate ship dates for each module. Engineers need goals and a date is the best goal of all.
Negotiate ship dates for the 1.0. Engineers need goals and a date is the best goal of all.
When stuff actually does get done, show appreciation to the engineers involved. Know their names, take them to lunch, buy them a cookie, shake their hand, give them a hug, whatever. NOTE: Food does seem to always be a good way to bond with or bribe an engineer. Everyone likes to be appreciated; that's human nature. Expressing a little bit of human courtesy to your engineers goes a long, long way. Just think about the engineer's life – they sit in front of a keyboard for 8+ hours per day with a minimum of human interaction. And, unless they are totally troll like, they will appreciate this.
Help to prioritize what modules need to be done in what order. Bear in mind that the engineers don't know what customer demos are coming up, what that customer needs to see, etc. Generally things are flexible (although there are certainly constraints at times) and can be adjusted to help meet overall goals.
Talk to the engineering team on a daily or weekly basis on the order of:
- How's it going with Module X?
- Are we on track?
- Is there anything I can do to help?
- Are any features that are giving you trouble? Let me know since cutting things is always a possibility….
Write the product literature for each module and the product as a whole!!! I'm a huge believer in product literature as a specification tool. If you can write product literature that you think will sell the product, that's a big help to the engineering team. It gives them a perspective from the customer that they lack. Another really useful specification tool is documentation / tutorials. Once the engineers know that work on these is going on, it can help to make them realize "Oops. I guess we really do need to finish this."
Monitor global AND local progress. Global progress is how close to being "done" the overall product is. Local progress is how close to being done a particular module is. I strongly advise you to develop objective, numeric metrics to track progress. It's a lot easier to understand that for each module there are these 10 common routines that need to be implemented and their status is X on a 1 to 5 scale (1=conceptual statue, 5=working code).

As far as the issue of your lead engineer being both senior and assertive, this is a classic case of cross managing / up managing. Grit your teeth and accept that it can be challenging but that you can do it. And understand that if the lead engineer has any common sense at all, he or she knows that the overall goal is to ship. The single best thing that a good product manager does is to help keep things on track. It can be all too easy for an engineering team to spin their wheels solving the wrong problem. As unpleasant as it can be to keep the pressure on the engineering team to ship, that's a big part of product management. You're the interface between the customer, the market and the engineering team. So it is ok to hold their feet to the metaphorical fire. That's what you do.

And, if they don't respond, move from a metaphorical fire to a real fire…. It works.

comment []