This article is from Silicon Valley Product Group Newsletter - October 5, 2009.
Subscribe at: http://www.svpg.com 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.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment