Skip to content

Latest commit

 

History

History
17 lines (10 loc) · 2.02 KB

push_vs_pull.md

File metadata and controls

17 lines (10 loc) · 2.02 KB

Push and pull are two different approaches to product feature development. Here's an explanation of each:

Push approach: With a push approach, the development team decides which features or enhancements to build and then creates them. This is sometimes referred to as a "build it and they will come" approach, where the assumption is that if the team builds a great product, customers will naturally be attracted to it.

In a push approach, the focus is on delivering a specific set of features, often with a fixed scope and timeline. This approach can work well in situations where the team has a good understanding of what customers want and can deliver high-quality features quickly.

However, the push approach can also lead to a product that doesn't meet the needs of the market or customers. Without input from customers or feedback on the product, the team may be building features that aren't valuable or relevant.

Pull approach: With a pull approach, the development team seeks feedback and input from customers and uses that to guide the development of new features. This is sometimes referred to as a "customer-centric" approach.

In a pull approach, the focus is on understanding the needs and wants of customers and using that information to inform the product roadmap and feature development. This approach can help ensure that the team is building features that are valuable and relevant to the market.

However, the pull approach can also be more challenging to execute. It requires the team to be in close contact with customers and be responsive to their feedback. This can lead to a more iterative development process, where features are developed and refined over time based on customer input.

In summary, the main difference between push and pull product feature development is whether the focus is on delivering a fixed set of features or on being responsive to customer feedback. Both approaches have their strengths and weaknesses, and the best approach will depend on the specific needs and goals of the product and organization.