Agile product management for startup
Download as PPTX, PDF1 like58 views
The document discusses principles for agile product management in startups. It emphasizes the importance of iterating quickly before running out of resources, keeping things simple by maximizing unnecessary work, and getting outside feedback from customers rather than expecting customers to know their wants. It also notes that successful software products are built "right enough" and that everyone's shared job in a startup is to ship products rather than focusing on individual roles like coding or testing.
Agile product management for startup
- 1. Agile Product Management for startup TIEC Mahmoud Ghoz
- 7. There is nothing so useless as doing efficiently that which should not be done at all.”
- 12. Startups that succeed are those that manage to iterate enough times before running out of resources.
- 18. Simplicity--the art of maximizing the amount of work not done--is essential.
- 25. Getting outside the building
- 28. It’s your job to come up with the solution. It is not the customer’s job to know what they want.
- 38. The fundamental truth of successful software products is that they have to be built "right", or at least "right enough". Ron Jeffries
- 41. Cross functional
- 42. Cross functional Everybody...has exactly the same job. They have exactly the same job description. And that is to ship products. Your job is not to write code. Your job is not to test. Your job is not to write specs. Your job is to ship products. Chris Peters - Former Microsoft program manager Source: https://www.microsoft.com/en-eg/download/details.aspx?id=13870
- 49. Q&A Mahmoud Ghoz
Editor's Notes
- #6: Give me a bag full of rice and I counted it very quickly — beautifully with no time wasted. Source: https://medium.com/swlh/going-nowhere-fast-doing-right-things-vs-doing-things-right-da201b652c05
- #7: Would you find it impressive or would you immediately ask, with palpable disdain “ Yeah, but what’s the point?”
- #8: Popular productivity is largely geared towards efficiency where titles like “how to achieve X in half the time” are commonplace. But efficiency, is the less important part of the productivity formula.
- #9: Effectiveness is more important, but efficiency is easier. It takes more courage and effort to be effective than be efficient.
- #17: Unique Value Proposition
- #18: Unique Value Proposition
- #19: Unique Value Proposition
- #20: MVP
- #21: Product Market Fit
- #22: MVE
- #26: https://www.youtube.com/watch?v=fNVRMPhRHmo
- #27: Feedback
- #28: Customers mainly asking about something faster than their existing alternative, which happened to be horses.
- #29: Ask people on the problems not the solutions
- #30: Efficient or effective? Effective “Doing the right thing”
- #31: All the previous is Qualitative what about million of people
- #36: The 5 Customer Segments of Technology Where blue represents the groups of consumer adopting a new technology and yellow is the market share which obviously reaches 100% following complete adoption. This is the point of market saturation. Source: https://ondigitalmarketing.com/learn/odm/foundations/5-customer-segments-technology-adoption/
- #38: Building right things is not enough Building things right
- #39: There is an exception. If your "business strategy" is to build some piece of crap that isn't sustainable, make a big splash on the Internet, then be acquired by GoogBook for a zillion dollars, you don't have to be able to build it right. You're not building a product. You're dancing about trying to look really attractive, so someone will slip you enough shares to let you go live somewhere warm and dine on tea and oranges that come all the way from China. That's cool. But it's not developing a product. https://ronjeffries.com/xprog/articles/build-it-right-to-build-the-right-thing/
- #40: Process
- #41: Process
- #42: Process
- #43: Process
- #44: Technical Debt
- #45: Technical Excellence
- #46: Transparency
- #47: Cycles of Mistrust
- #48: Process