Feed The Beast

For those that haven’t heard the term before, “feed the beast” refers to one of the most common problems with product teams, and one of the top reasons for failed projects.  It’s very easy to spot.  If you find a product manager that is scrambling to finish up his PRD because the developers are freeing up from their current project on Monday and the very thought of the developers not having a fresh spec ready to go sends the product manager (and especially senior management) into a panic, that’s what we call “feed the beast.”

The beast is of course the development organization and the beast does have a voracious appetite.  Unfortunately, the beast generally can’t distinguish between something that’s worth eating and something that’s not.  Beasts eat PRD’s and we all know what comes out the other end.

This feed-the-beast mentality stems from the observation that the largest cost in a product development organization is the engineers, so it’s important to keep them fully utilized.  Ironically, this overly simplistic view results in maximizing utilization (they are busy) but not maximizing results (producing successful products).

Further, this mindset tends to diminish the development organization’s real contribution.  They are treated as a software factory optimized for coding rather than a collaborative partner for discovering and delivering successful products.  I like to say that if you’re using your developers for only coding, you’re only getting about half their value.

Good product organizations understand that their responsibility is to provide the development organization with something worth building; something where they have evidence that the products that are created will be successful.

Part of this is simply management not understanding the difference between building the right product, and building the product right.  But often the company’s culture plays a role in creating this problem.

I love what a great project manager can do to help you deliver quickly (see www.svpg.com/ebays-secret-weapon/), but it’s also true that in some companies project management plays too central of a role, and the entire focus becomes about schedule and resource utilization.  This is why normally I encourage project managers to take a back seat during product discovery, and then move to the drivers seat only once you’re sure you want to actually build the product.  I find this works well, except in situations where there’s nobody that knows how to drive in the drivers seat during discovery, and I’m going to discuss this situation in the next article.

So what do you do if you are stuck in this “just in time” situation?  There are several options:

1. the developers can work on critical infrastructure/headroom activities (see www.svpg.com/engineering-wants-to-rewrite/)

2. the developers can work on fixing defects and improving performance

3. the developers can participate in product discovery activities

In general, we try to build a backlog of useful product specs of about a month or so.  This way, if you run into trouble on a project (for example, you test your idea on users and they think what you’re proposing is a big waste of time and they’d never use it), then you have work that is ready to go while you move on to pursue other ideas.

It is also possible that your project team is out of balance.  If there are too many developers relative to the number of product managers and designers, then you will perpetually be behind and your organization is not able to properly utilize the developers you have.  I have seen some teams where one product manager is trying to define products for 20 or more developers and this is just a clear recipe for poor products.  If you’re not sure about the proper ratios, see www.svpg.com/roles-and-ratios/.

Just please remember that no matter what you do, your top priority is to ensure that the team is building something worth building, and that the development team is a very big investment for the company and should not be wasted, either by having people waiting around or by rushing to build something that will just have to be done over again later.