Download to read offline
Uploaded byShoaib Shaukat
Myths of Product Development
This document discusses common misconceptions in product development and proposes lean thinking alternatives. It addresses six prevailing practices: 1) high resource utilization improves performance, 2) large batches improve economics, 3) sticking to plans is best, 4) starting sooner finishes sooner, 5) more features increase customer liking, and 6) getting it right the first time is most successful. For each, it advocates limiting work in progress, incorporating customer feedback early and often through minimal viable products and experimentation, and accepting that plans will change and failure is part of the learning process. The key takeaway is to make information visible, quantify delays, introduce slack, focus on response over efficiency, use small batches with fast feedback, and treat plans and features
More Related Content
Similar to Myths of Product Development
Myths of Product Development
- 1. De-mystify Product Development @shoaibshaukat Melbourne,2015 Lean Thinking Agile Product Development
- 2.
- 4. Practice #1 “High Utilisation of Resourceswill improve performance.”
- 5. Structures to meetunpredictable demand are different from the structures to meet linear demand. Team 1 Analyse Develop Test Operate Team 2 Analyse Develop Test Operate Team 3 Analyse Develop Test Operate Production Issue Production Issue QA Environment Issue
- 6.
- 7. Little’s Law The averagenumber of things in the system is the product of the average rate at which things leave the system and the average time each one spends in the system. WIP = Avg. Exit rate * Avg. Time Spent in System Avg. Time Spent in System (Cycle Time) = WIP / Avg. Exit Rate Example: A team (5 members) can complete a task in one day – If there are 5 tasks in a batch then Cycle time will become 5 days. Cycle Time = 5 / 1
- 8. High utilization of resourcesincreases number of queues and their size. Queues affect economic performance Make WIP inventory visible Change the Management Control System from efficiency to response Selectively increase capacity Limit the number of active projects
- 9. Practice #2 “Processing work inlarge batches improves the economics of the development process.”
- 10. Holding Costs =High Transaction cost = Low Holding Costs = Low Transaction cost = High
- 11. COST BATCH SIZE Transaction Cost HoldingCost Total Cost Optimal Batch Size
- 12. Small batches allowsto slash WIP and accelerate feedback -> improves cycle times, quality and efficiency. WORK WORK WORK WORK WORK WORK
- 13. Practice #3 “Our development planis great; we just need to stick to it.”
- 14. Our development planis great; we just need to stick to it. • Planning must respond to change to deliver the right customer value. • Every thing that customers said are not necessary is a product/need. • Customer needs can change during the project. • Lean Startup (or Lean UX) - Build-Measure-Learn (Eric Ries) • Plan based on business value, time criticality and effort. • User preferences or market needs can change abruptly requiring a rethink of the product specifications. • Don’t commit to a solution too early – Leave the decision to last responsible moment – (Mary Poppendieck) • Customers can’t accurately specify their needs for solutions that don’t exist yet. • Familiarity with existing product/process attributes can interfere with ability to express the novel product.
- 15. Practice #4 “The sooner theproject is started, the sooner it will be finished.”
- 16. The sooner the projectis started, the sooner it will be finished. Focus: Stop starting – Start Finishing. Value is only realised when delivered to customers. New projects, specially if they use shared resources will almost always create queues and slow down the delivery. Create WIP limits Don’t start a project until it’s value is clearly defined and provides the most benefits to organisation.
- 17. Business, IT, Customers,Partners Concept Evolve Deliver Harness Business Business Business IT IT IT Concept Evolve Deliver Harness Concept Evolve Deliver Harness Concept Evolve Deliver Harness LeanExperimentation
- 18. Practice #5 “The more featureswe put into a product, the more customers will like it.”
- 19. The more features weput into a product, the more customers will like it …
- 20. Less is More. How? MVP(Minimum Viable Product) – a product with a minimum feature set – high enough in value to customer to satisfy a particular need Focus on understanding user needs - understand how they use the products and their problems. Weighted Shortest Job First Bring developers closer to end user. Invest in building capacity to understand user environment.
- 21. Practice #6 “We will bemore successful if we get it right the first time”!
- 22. “We will bemore successful if we get it right the first time”! Requiring success on the first pass forces the teams towards the less risky. Innovation is risky by nature! Focus on shorter build times, early feedback, continuous learning! Software product development is complex and risky by nature! Promote experimentation. Embrace failure but celebrate recovering and learning from failure. Invest in automating the tools that help you deliver and learn faster.
- 23. Key Take AwayPoints Make queues and information flow visible Quantify the cost of delays and factor it into your decisions Introduce resource slack where utilisation is highest. Shift focus of control systems from efficiency to response time. Reduce transaction costs to enable smaller batch sizes and faster feedback. Experiment with smaller batches; you can easily revert to large batches if this doesn’t work. Treat the development plan as a hypothesis that will evolve as new information becomes available. Start projects only when you are ready to make a full commitment. Aim for simplicity; Ask what features can be deleted, not just what can be added. Experiment early, rapidly, and frequently, with computer models and physical prototypes, in controlled and real- life customer environments.
Editor's Notes
- #2 Product development is the process of designing, creating and marketing new products or services to benefit customers. Sometimes referred to as new product development, the discipline is focused on developing systematic methods for guiding all the processes involved in getting a new product to market.
- #3 This brownbag has only one purpose i.e. look at some product development process/practices and explain them in the light of Lean thinking.
- #4 October 2010 – Ryder Cup at Celtic Manor (close to London Heathrow) Mark Pain – award winning sport photographer Cigar guy (bewilderment, confusion, dazed, surprising)
- #9 In product development the WIP inventory is predominantly invisible.
- #11 Large batch size – low transaction cost but high holding costs Small batch size – high transaction cost but low holding costs
- #12 How to determine optimal batch size.
- #13 Small batcheshelp do the continuous deployments. Small batches help with localising the problems and we can rectify the problem before it spreads. E.g. Would you like your design team to make an upfront design to find out about the problems later by developers or would you prefer to design in small batches and take regular feedback from developers? Small batches are less risky. Small batches provides early feedback. Small batches makes you more efficient by reducing overhead – sounds counter-intuitive but people get better at doing things they do more often. So if you do test planning, testing on a 2 weekly cycle on a small batch – you learn and improve faster.
- #15 Last responsible moment: in practice this means delaying commitment by building capacity to change into the system. It involves a commitment to work towards a minimum viable products that defers the implementation of features that might be required for future. It is a call to resist gold-plating or dwell too long on the upfront design of the complete solution. Your understanding of a solution will evolve along with your understanding of the implication of any decision.
- #17 A project must not start unless its delivery can be realised by the business in a timely manner. A project delivered by IT but not utilised by business is equal to a project not delivered.
- #19 Product development teams seem to believe that adding features creates value for customers and subtracting them destroys value. This attitude explains why products are so complicated: Remote controls seems impossible to use, computers take hours to set up, cars have so many switches now and even humble blenders come with some many controls.
- #21 Getting companies to buy into and implement the principle that less can be more is hard because it requires the extra effort in two areas of product development: Defining the problem: Articulating the problem that the developers will try to solve is the most underrated part of the innovation process. Too many companies devote far too little time to it. But this is important as it is where most teams develop a clear understanding of what they goals are generate hypothesis that can be tested and refined through experiments. The quality of a problem statement makes all the difference in a team’s ability to focus on the few features that really matter. Determine what to hide or omit: Often customers would prefer a product that just works effortlessly rather than all the technical brilliance build into it. Determining what features to omit is just as important – and perhaps more important than – figuring out which ones to include.Unfortunately many companies in an effort to be innovative throw in every possible bell and whistle without fully considering important factors such as the value to customers and ease of use. When such companies do omit some planned features/functionality, it’s typically because they need to cut costs or have fallen behind schedule or because the team has failed in some other way. Instead managers should focus on figuring out whether the deletion of any proposed feature might improve a particular product and allow the team to concentrate on things that truly heighten the overall customer experience. Treat each alleged requirement as hypothesis and testing it in small, quick experiments with prospective customers. Dev teams often assume that their products are done when no more features can be added; Perhaps the logic should be reversed: Products get closer to perfection when no more features can be eliminated. As Leonardo da Vinci once said: “Simplicity is the ultimate sophistication.”
- #22 Many product development projects fail to meet their objectives for budgets, schedules and technical performance. Poor planning, rigid processes and weak leadership all play a role. But another cause that’s
- #23 To avoid mistakes teams follow a linear process in which each stage (specify, design, build, test, scale, launch) is carefully monitored at review “gates”. Work on the next phase can not commence until the project passes through the gate. Successful tests in late stages are celebrated, and surprises, no matter how valuable they are, are considered setbacks. Unfortunately, such a linear process flow can cause project overruns because test feedback is delayed, teams cling to bad ideas longer than they should, and problems aren’t unearthed until it’s expensive to solve them. A tolerance for “getting it wrong the first time” can be the better strategy as long as people iterate rapidly and frequently and learn quickly from their failure. Advances in simulation and rapid prototyping technologies have made operating in this fashion vastly easier and less expensive.