What is the difference between a Project and a Product?
This is a common question that must be addressed early in an Agile transformation. In fact, this is often the lynchpin conversation with leadership that can make or break an organization’s future! So what’s the difference?!? Well, below you will see a few areas where Projects and Products are distinctly different:
Key Differences Between Projects and Products
PROJECT
- Small singular scope of work
- Outcome focused
- Time oriented
- One time funding model
PRODUCT
- Large evolving scope of work
- Customer value-focused
- Persistent (no end date)
- Ongoing funding model
Why is this important?
At first glance none of those listed items seem horrific or revolutionary so what’s the big deal? Fair question! The big deal is found in the execution of the work.
Project Example
Let’s imagine an online insurance company wants to fund a project allowing customers to update health records after a doctor’s visit. The idea is that the customer could add any new medications, updates to weight, prescribed activities, etc. These would be recorded in the existing customer database using existing systems the insurance company already has in place. The project is simply to add these new “features” to their website and mobile application. Here are the steps needed to get this project STARTED:
Starting a Project:
- Establish Funding and Timeline: You’ll need to come up with a plan and set a preliminary budget and get that approved
- Assemble a Team: Find existing or hire new employees who are experts at the systems and products impacted plus and required specialists like Copy Writers, User Experience or Interaction Designers, etc.
- Gather Requirements: Make a comprehensive list of the “Must Haves” for this project
- Plan the Work: Plan all the work required to deliver all the requirements within a given time frame and within the established budget
- Design the User Experience: Create any required look and feel items including copy, buttons, photos, forms, etc.
- Build the Dang Thing: Develop or build the code required to accomplish the requirements and incorporate it into the existing systems and platform architecture
- Test It: Test the solution to ensure it delivers the initial requirements and that it generates no errors, bugs, defects, or security issues
- Demo the Project: Share the work with the stakeholders and others who will be impacted
- Release the Project into Production: Deliver the new functionality into the marketplace for customers to use
- Disband the Team: Let the team members who delivered this work go or find them new projects to work on
- Begin a New Project: Start over on a new project or concept and repeat this process
I hope that sounds pretty terrible to you. If not, let’s consider a few common problems with project work:
Problems with the Project Model:
- You have to establish funding and a timeline prior to really knowing what is involved in actually delivering the work
- You have to build a team around the work and there is no assurance that a knowledgeable team will emerge
- Requirements have to be gathered early and are nearly set in stone at the start of project work
- You have to plan everything upfront with no wiggle room for incorporating significant scope changes
- Once all the user experience artifacts are created the development team is on the hook for coding in such a way that the design pieces fit together
- Testing is done at the end after all the design and development work is complete leaving almost no room for mistakes or defects
- Stakeholders aren’t included in the design and development until the work is complete. This doesn’t allow for improvements
- Once complete the team is dissolved and all the skill, knowledge, and morale goes away
Join our Pro Tips Pipeline
Agile Pro Tips respects your privacy. Read our privacy policy on how we handle your personal information.
How is the Product Model different?
The Product Model offers many distinct advantages over the traditional Project Methodology. For starters, it is focused on persistently delivering customer value rather than delivering a limited set of features. Let’s take a look at our insurance example but apply the Product Model instead of the project methodology.
If an online insurance company wishes to adopt a Product Model approach they would need to define each of their products and establish a continuous funding model for each of them. This funding model can be as simple as a percentage of the previous year’s profit. That funding amount will then be used to fund persistent teams tasked to deliver new and enhanced features for that product as long as the product line exists.
Adding New Features with the Product Model
- Submit New Feature Idea to Product Backlog: Share the idea with the product team or their leadership
- The Feature is prioritized: Your idea is weighed against all other ideas based on a variety of factors that often include: level of effort, time to market, development risk, and most importantly customer value
- Refinement: Your idea is broken down into smaller chunks of work that are self-contained and deliverable within a very short period of time
- Design, Development, Delivery: These smaller chunks of work are then designed, developed, and delivered in testable increments
- Unit Testing and Demo: Testing is completed one small chunk at a time and demonstrated as soon as possible
- Feedback: Your input on the progress and development is encouraged and acted upon every step of the way through the process
- Constant Delivery: As soon as a deliverable enhancement is ready it is released into production to benefit customers
As you can see the team is not disbanded after they deliver your Feature. In fact, they are persistently working on the same product or product line allowing them to become true experts in delivering value. Customers benefit from the continual release of small enhancements to the products they use, and the company benefits by having a predictable budget and predictable delivery of working products.
And this is only the beginning...
Obviously, this barely scratches the surface of how the Product Model diverges from traditional project methodology. There is much more to discuss and review. To that end, please leave any questions, comments, thoughts, or topic suggestions in the comments section below!
