product development experience and project development experience

[Rr Kumaran]

Hi All,

w.r.t professional experience in software development, what exactly is a product development experience and project development experience. I am working in a service based company rather than a product based company so what are the actual differences between the two ?


Thanks & Regards,
Bantumilli.

[Lasse Koskela]

In general, I would say the difference is that product development requires much more attention to maintainability and architecture than projects, which may be one-off solutions.

That's not to say that product development would require big, up-front architecture design. In fact, using XP might support the quality much better than a waterfallish method.

[Richard Leavitt]

I like Lasse's generalization. Other characteristics of *Product* development versus projects that I've noticed:

- Products have multiple releases
- Products tend to keep the same team together
- Products are revenue generating, not cost saving

I'm also seeing many IT shops split up their development into "products" and "projects." Products are those areas where they choose to create a competitive advantage, something they feel will help them win more business (e.g. a new provisioning system for distribution to channel partners). Projects are run in areas they want to achieve technical parity (e.g. implement a new packaged CRM application).

Hope that helps.
Richard

[Lasse Koskela]

Actually, in XP2004, Mary Poppendieck called out to the XP community to move into product development mind-set instead of the current project-oriented thinking. Martin Fowler echoed this in his closing keynote.

[Stan James]

In project management they define "project" as a set of tasks with a defined beginning, goal and end. So a project might produce several products or an incremental upgrade to a product. I guess I think of product oriented teams as having more of a "shrink wrap" mentality, perhaps delivering major releases to non-captive audiences infrequently. I live somewhere else - we can ship small upgrades and bug fixes and whatever else as often as we need to a captive corporate audience.

[Ilja Preuss]

Originally posted by Lasse Koskela:
In general, I would say the difference is that product development requires much more attention to maintainability and architecture than projects, which may be one-off solutions.

This doesn't match my experience. I've never seen a user of a system who didn't want a good software system to be even more improved.

Similarly, every "prototype" I've seen did go into production for a while, regardless of what people told beforehand.

[Lasse Koskela]

Originally posted by Ilja Preuss:
This doesn't match my experience. I've never seen a user of a system who didn't want a good software system to be even more improved.

Well, I've seen some (and it wasn't about the system being perfect but about the system being good enough for nobody wanting to shell out extra dollars for improving it further).

Having said that, I really don't think we're disagreeing here -- or then I just don't understand what you're referring to?

[Lasse Koskela]

Trying to clarify what I meant by
In general, I would say the difference is that product development requires much more attention to maintainability and architecture than projects, which may be one-off solutions:

If you're a product company, selling a product named WhizBang 5.0, WhizBang 6.1, WhizBang X, WhizBang 2009, etc., you typically can't afford to start every new version from scratch. Your architecture has to be in a good shape. Otherwise you'll end up open-sourcing your product in a desperate move to avoid bankruptcy after your product releases have slipped severely for many years in a row...

Then again, if you're a stovepipe company engaging in a bespoke development project building a piece of software that automates some mandatory but non-essential part of your company's operations, you might not have too strong an interest to invest too much into a rock-solid, nuke-proof architecture. In other words, you're not expecting to need major changes into the software being built (and the contractor might have his own profit margins in mind...) so the Good Enough bar tends to be lower compared to a product company.

Does this make sense?