Difference between planning a project vs. planning a product

Question

I have read in numerous places that when developing a product you need to take a different approach to when you are developing a project (think "contract" work).

Some differences are:

1) There is no definitive user, but a "user-base".

2) You need to develop the minimal marketable feature set.

3) Scheduling needs to be watched, as there is not often a fixed deadline it is possible for the product to run overtime (or for scope creep).

I was wondering if there are people out there with experience in both, and if they could offer some input into any differences that they know of. Also if anybody could provide any tips/good references for how to deal with the differences I would be most appreciative.

Answer 1

Some significant differences:

• A project is generally time-limited. A product has a lifespan is usually not known at the time of development - your assumption should be that if it succeeds you have an ongoing business.
• A project needs to deliver against a specified deliverables. A product needs to offer a viable ongoing business. Guess which is harder :-)
• It's realatively easy to outsource a project. Outsourcing product development is usually a very bad idea (hint: you shouldn't outsource your core competency!)
• Since products are (usually) externally focused and intended to scale, quality tends to become more important as a success factor.

I think the differences listed in the question actually aren't intrinsic differences between products and projects. You could imagine launching a product with a full feature set for example. A project may well have a broad and loosely defined "user base". And both products and projects are likely to have issues with scheduling / scope creep :-)

Answer 2

This is apples and oranges. There is no comparison as if one is exclusive of the other. One can and should be working on projects for the benefit of the product.

Qualities of building a product definitely focus on 1 and 2, however 3 is not quite correct. Simply because it is a product does not mean that scope creep is any more acceptable or any less dangerous. When determining product work, one must fit workable feature development into one or more projects, as it is important to meet schedule needs and keep costs under control.

The fact of the matter is that the "software product" is partly a marketing term. If I have working software of reasonable quality then I can brand it, advertise it, and attempt to sell it to a number of customers.

Where software design comes into play is the clever amalgamation of customizable feature sets for a disparate variety of customers makes a software product such that the need for custom development to gain a single customer is kept to a minimum if at all possible. This can be extraordinarily hard to do.

If your organization is using the excuse that product work makes scope creep and floating deadlines as acceptable then they are merely making excuses.

Answer 3

While planning a project, you need to consider the following:

1. Scope
2. Stakeholders
3. Resources
4. Constraints
5. Quality level
6. Cost

Whereas, planning a product would require you to cosider the following:

1. Generic Features: Essential component of the product, the traits without which the product does not exist.

2. Expected Features: Features that are generally assumed or expected by the target customer

3. Additional Features: Features that add more strength and value to the product

4. Potential Features: Features that are meant to make the product unique and distinct and hence contributes to customer retention.

Answer 4

All three of your points can apply to a project too. It may help to visualize a real example: developing an internal billing system for a large company (project) versus writing a billing system to be sold broadly (product).

Some differences:

1) You can settle for "just good enough" on the project. The product has higher quality expectations.

2) You have to accompdate many more hardware and software configurations with a product.

3) The users are more likely to be remote on a product. It is harder, but not impossible, to get usage data.

4) With a product you are more likely to leave the integration to someone else.

Answer 5

I worked for a small software company during the time where they released new versions to handle Y2K. To me the biggest differences involve the control and consistency of the users and their environments.

1. User computer setups will be more consitent.
2. The users are usually better trained (Except if your market is IT professionals.) or have an IT department.
3. Contract jobs give you more access to the user's systems in case you have to tweak an install.
4. User buy-in can be tricky in contract situations if there is internal fighting and politics going on. Many users don't want change. Hopefully, a customer buying commercial software really wants to use it.

I don't think the time demands are that different because someone is still paying for your time and may be losing business or productivity because they don't have your app (Isn't that why they're buying it in the first place?). If you're building some free social app and using borrowed money, investors want to see a product sooner rather than later.