Skip to content

Latest commit

 

History

History
76 lines (40 loc) · 3.27 KB

products-projects-initiatives.md

File metadata and controls

76 lines (40 loc) · 3.27 KB
Raw

Products, Projects and Initiatives

A product is a vehicle to deliver value. A project is a plan that aims to fullfill a set of requirements. An initiative is a program to address a problem or opportunity.

[toc]

Overview

Mindset:

  • Project mindset: Finish a pre-defined fixed set of tasks, within constraints.
  • Product mindset: Continuously deliver value to customers.

In practice, products are improved through multiple small projects or initiatives.

Products are never finished, only deprecated.

Because products are never finished, they cannot be reduced to a static set of requirements. Instead they represent an outcome, which should be conveyed by telling a story or showing a vision.

Initiatives are projects without deadlines. Instead, they have domain-specific acceptance criteria. Sizing may be controlled through hierarchy. E.g. sagas, epics, stories and tasks.

Product Project Initiative
Purpose Deliver value to customers Satisfy requirements Satisfy acceptance criteria
Timing Continuously, frequently Finish before the deadline Sooner rather than later
Focus Market-oriented Result-oriented Outcome/impact-oriented
Constraints Funding Time, cost, requirements, resources Resources, quality standards

Differences

Typical differences between projects and products.

Projects terminate; either successfully by meeting requirements or by reaching deadline. There is a bias for the short term (the duration of the project) over the long term (after the project).

  • Optimize cost. Satisfy requirements as fast and efficiently as possible.

    • Build a feature/project/product, then hand it over and move on.

    • Reach the deadline at all cost; strip features or reduce quality if necessary.

Products are continuous, but may expire (based on alternatives). There is a preference for value and sustainability.

  • Maximize value, opportunity and viability.

    • Delivering value to customers > resource efficiency.

  • Compatible with DevOps and vertical integration.

    • "You build it, you own, you run it"

  • Place bets on potential wins. Prefer outcomes over meeting (initial) requirements.

    • Long-term revenue stream > quarterly results.

Projects typically have three constraints: a time bound, cost bound and a set of requirements (input or output). When risks materialize then at least one of these must be let go.

Types of Products

  • Traditional Product: a static object. Must be right the first time.
  • "Software" Product: can be updated (patched) after the first release.
  • Service: completely continuous. Regularly updated to market conditions.

Levels of product

  • A commodity, a heterogenous product. Marketed by showing features or generic benefits.
  • A unique selling point. Solving a specific problem, for a specific market/persona.
  • Being a brand. An identity/lifestyle. Telling a story.

“We understand you". That’s why you should trust us and buy our services