(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Sunday, November 21, 2004
Build, Buy, or Something In-Between?
On November 30th, 2004 the Toronto Product Management Association will have a panel session entitled "Product Managers working with Developers."I'll be participating on the panel representing development. There will also be panellists representing the buy and outsource/contract options.
I've posted a draft copy of my presentation [here]. My intent is to discuss when you ought to consider developing a product in-house and then present several anti-patterns that would prevent success. One caveat about my presentations: I don't develop presentations as stand-alone documents. Although the presentation communicates the basic outline of my argument, I save lots of points for the spoken word.
I've tried to break the argument for and against in-house product development into two separate buckets. First there're the strategic reasons you ought to develop a product in-house.
Second, there are the tactical reasons for and against. Actually, I couldn't think of any tactical reasons for in-house development. Lots of people have told me to develop in-house when it's faster, cheaper, and/or better.
Quite honestly, I don't buy the "faster or cheaper" arguments, which are essentially tactical or operational concerns. If developing in-house isn't better, I think you ought to get rid of it. It's too risky and too management-intensive if you aren't getting a big win out of the exercise. So I only have tactical reasons to avoid in-house development.
I'd appreciate as much feedback as I can get, so please download a copy and let me know what you think. And if you're in Toronto the evening of the 30th, please come out to the meeting. I'd love to see you there.
On November 30th, 2004 the Toronto Product Management Association will have a panel session entitled "Product Managers working with Developers."I'll be participating on the panel representing development. There will also be panellists representing the buy and outsource/contract options.
I've posted a draft copy of my presentation [here]. My intent is to discuss when you ought to consider developing a product in-house and then present several anti-patterns that would prevent success. One caveat about my presentations: I don't develop presentations as stand-alone documents. Although the presentation communicates the basic outline of my argument, I save lots of points for the spoken word.
I've tried to break the argument for and against in-house product development into two separate buckets. First there're the strategic reasons you ought to develop a product in-house.
Second, there are the tactical reasons for and against. Actually, I couldn't think of any tactical reasons for in-house development. Lots of people have told me to develop in-house when it's faster, cheaper, and/or better.
Quite honestly, I don't buy the "faster or cheaper" arguments, which are essentially tactical or operational concerns. If developing in-house isn't better, I think you ought to get rid of it. It's too risky and too management-intensive if you aren't getting a big win out of the exercise. So I only have tactical reasons to avoid in-house development.
I'd appreciate as much feedback as I can get, so please download a copy and let me know what you think. And if you're in Toronto the evening of the 30th, please come out to the meeting. I'd love to see you there.
Comments on “Build, Buy, or Something In-Between?”:
<< Home
I doubt I'll get much debate when I say that product development is risky. Analysis of in-house capability might make the decision a little more comfortable, but it doesn't eliminate the risk. You might also want to touch on what to do when things go bad. Specifically, does the product development plan include an exit strategy? Are there well defined criteria for when it is appropriate to halt a project and cut the losses? Is the product developer capable politically and socially of pulling the plug, or has it tied peoples' careers, reputations, and bonuses too tightly with success? My experience is that people will ride these things into the ground, even when the evidence of failure should be obvious. If you can't be objective, if you don't want to consider the possibility of failure, or you simply can't afford to gamble, in-house capability becomes far less significant.
<< Home
