Ankle Biters: Machine Tools (was: Don’t be a Tool)

Machine tools are tools used to build other tools, like a drill press or grinder.  As a Product Manager, our tools are the internal applications and tools we use to support our data gathering, requirements tracking, and project management needs.

If you’re lucky enough to have budget for a nice set of tools for common PM problems like requirements tracking (such as RymaTech’s FeaturePlan), then you only need to be concerned with the maintenance, upkeep, and training of your people on the tools.  I’m in an ultra-lean startup, and we don’t have budget for that kind of thing, so we re-purpose other tools like the common Office suite kludges and what we can do with SalesForce.  But if you’re building these apps yourself, then you’ve become a machine tool.

The big disadvantage of being a machine tool is, obviously, time.  Time you’re spending being a machine tool and building your custom, one-off apps is time you could be spending talking with customers.  For example, as Director of Product Management in a startup, I am the “go to” person for product information on our Release Plan, including dates, since we’re too small to have a Program Management team.  I maintain a set Excel file that tracks project milestone completeness and depend on various department heads to update their “track,” e.g. Marketing, Operations, and Engineering.  The individual tracks feed the master Release Plan, which is what we review every Friday as a product team.  I spend at least an hour per week maintaining this application and keeping everything in sync across multiple sheets as projects change.

We’ve tried to keep our PM managed tools lean and mean.  Another example is a community site that we started for our channel.  From a PM standpoint, it’s great - we have a direct conduit into hundreds of users who are ready and willing to communicate with us, and it’s been golden for snap validation surveys.  The problem started when it got too popular, and started attracting spammers.  Pretty soon we were getting 20+ spam registrations per day, and if each took 30 seconds to clean out of the system, that’s another hour per week gone.  I had to add spam protection to the forums, thankfully now its time:value ratio has increased.

My best recommendation/strategy for not becoming a full-time machine tool is to carefully consider the utility of any proposed tool before you build it.  Ask the question - is the effort I’m about to expend building this tool worth the increase in feedback|efficiency|whatever we’re going to get?  The initial effort is the visible part - senior management doesn’t see the ongoing load of handling these tools, so you need to both raise the visibility of the ongoing effort and consider it before you build.

7 February 2008 | Executives, Lessons Learned, Product Management, Tactics, Theory | Comments