# Project to Product  ## Metadata - Author: [[Mik Kersten]] - Full Title: Project to Product - Category: #books ## Highlights - It has been iconified by the Gantt chart, created by Henry Gantt in 1917 and subsequently used to build the Hoover Dam, the largest concrete construction of its time. This was the tail end of the Deployment Period of the Age of Steel, during which the practices of Taylorism were adopted in order to improve and scale labor efficiency. ([Location 1110](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1110)) - Taylorism assumed that people could be treated as interchangeable resources that could be assigned and reassigned to projects. Such treatment of workers as machines is not only dehumanizing but also shortsighted, as later demonstrated by Henry Ford, who realized the importance of decentralized decision making and autonomy. ([Location 1114](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1114)) - Fordism put significantly more emphasis on the actual worker, their training, and their economic well-being. ([Location 1118](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1118)) - This results in project plans that incentivize delaying releases and customer testing in order to implement everything that was needed at the start of the project. And this multiplies the product/market-fit (PMF) risk by removing the possibility of iterative learning from the market and pivoting accordingly. ([Location 1172](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1172)) - In contrast, product-oriented management focuses on measuring the results of each unit of investment that brings value to the business. Those units are products; they deliver value to a customer, and as such, the measurement must be based on those business outcomes. ([Location 1174](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1174)) - Marked by a project-over-product mentality, an emphasis on cost over profit, and adherence to time frames over delivery of business value, this disconnect between the business and IT is at the core of IT and digital transformation failures. ([Location 1274](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1274)) - The Flow Framework ensures that your transformation is grounded in connecting, measuring, and managing your Value Stream Network, which is the critical layer needed to succeed with software delivery at scale. ([Location 1283](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1283)) - Tags: [[favorite]] - Organizations need a managerial culture and understanding of a rapidly changing market in order to bring software-based products to market and adapt. But before we consider how to deliver more value, we must first define how we measure business value in software delivery. ([Location 1286](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1286)) - For example, enterprises are still managing IT as a set of projects or a cost center, rather than taking the product-oriented mentality that defined the winners of the Age of Mass Production. ([Location 1296](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1296)) - We need a new framework, one that elevates the best practices of Agile and Lean frameworks to the business. We need to define business outcome–oriented metrics instead of relying on activity-oriented proxy metrics. ([Location 1299](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1299)) - To achieve the Three Ways of DevOps—flow, feedback, and continuous learning—we need to scale the ways of DevOps beyond IT to the business. ([Location 1350](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1350)) - lean thinking can be summarized in five principles: precisely specify value by specific product, identify the value stream for each product, make value flow without interruptions, let the customer pull value from the producer, and pursue perfection. ([Location 1400](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1400)) - Value Stream: The end-to-end set of activities performed to deliver value to a customer through a product or service. ([Location 1410](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1410)) - Software Flow: The activities involved in producing business value along a software value stream. ([Location 1444](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1444)) - if an Agile team is constantly struggling with meeting its release goals, the SAFe or Scrum frameworks can provide metrics and guidelines for better prioritization and planning. ([Location 1448](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1448)) - To pull value, the customer must be able to see that value and be willing to exchange some economic unit for it. ([Location 1485](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1485)) - Flow Item: A unit of business value pulled by a stakeholder through a product’s value stream. ([Location 1494](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1494)) - The four flow items follow the MECE principle of being mutually exclusive and collectively exhaustive. In other words, all work that flows in a software value stream is characterized by one—and only one—of the flow items. This means that activities such as prioritization of the various flow items are a zero-sum game, ([Location 1555](https://readwise.io/to_kindle?action=open&asin=B07F3DJMZ1&location=1555))