Adaptive marketing networking event technical vs market requirements - rahul abhyankar
Download as PPTX, PDF0 likes1,094 views
The document discusses product strategy and architecture. It talks about balancing engineering requirements with market requirements, ensuring architecture is future proof, and using value analysis to better understand customer needs and how to meet them. Value analysis involves understanding value expectations, limiting factors, and change agents. The document also discusses treating platforms as products and using intangible metrics to measure value, as well as creating multi-layered roadmaps.
Adaptive marketing networking event technical vs market requirements - rahul abhyankar
- 1. Product Strategy & Architecture Rahul Abhyankar Nov 12, 2011
- 2. Briefly, about… • 20 years of high tech experience in product management, business development and engineering roles • Led teams to build enterprise/consumer, software/hardware/cloud based systems and services • PM leadership for product portfolios as well as core technology portfolios • Most recently VP of Product Management at McAfee responsible for Global Threat Intelligence and core security technologies • Prior: FaceTime Communications, MasterCard, Union Pacific Railroad, Tata Motors (India)
- 3. Some Real-World Situations • As a PM responsible for the roadmap, my engineering team has some “engineering requirements”. How do I weigh these against “market requirements”? • As an Engineering Lead, how do I get “engineering requirements” road mapped into the release cycle without them getting deprioritized by sales and “market requirements”? • As an Engineering Lead, I need to understand where this product is going in the future so we can architect it for the long term. • As a PM, I trust my Engineering team to build the right technology. How do we ensure the architecture is future proof?
- 4. We exist to create value! PM Engineering WHAT? HOW? WHY? Business Case Market Requirements Architecture Product Engineering Requirements Requirements
- 5. Q&A • For Engineering – Do requirements capture the essence of the value being delivered? • For PM – Do all stakeholders have a clear understanding of how architecture will deliver that value?
- 6. Typical approach to value • Actors, Types of Actors • Use Case Scenarios • Requirements • Shortcomings – Focus more on what actors do, not so much WHY – Tend to stereotype actors – Binary – Requirement is met or it isn’t, use case is satisfied or it isn’t
- 7. How do we discover Value? • VALUE EXPECTATIONS – What are the needs – What are the capabilities to address the needs – How well are they provided (quality)
- 8. How do we discover Value? • LIMITING FACTORS – What makes it difficult to satisfy the value expectations?
- 9. How do we discover Value? • CHANGE AGENTS – Events that cause value expectations to shift OR – Limiting factors to have a different impact
- 10. Value Analysis • Value Expectations • Limiting Factors • Change Agents • HOW SATISFIED IS OUR MARKET? • HOW DIFFICULT WILL IT BE TO SATISFY IT? • WHAT WILL DISRUPT THE MARKET?
- 11. Deployment Context Single Context Products Multiple Context Products All deployment scenarios have Different deployment equivalent value expectations environments, value and limiting factors expectations, limiting factors
- 12. Why is this important? • Value Analysis becomes a important exercise for PM and Engineering • Better understanding – How are value expectations prioritized – How well are value expectations going to be met – How well are limiting factors going to be mitigated – What are the interdependencies between them – What tradeoffs are necessary to fulfill value expectations
- 13. Where does this fit? Value Analysis Architecture Requirements Definition
- 14. Product Managing Core Technology • Treat platform as a product – Customer is buying the product, but getting the platform • Link technology metrics of core components to value expectations • Intangible indicators of value – Decline in support cases – Customer surveys – Third party reviews, bake-offs
- 15. Architecture Strategy • Organization • Operation • Variability • Evolution • High-level statement of direction that must be understandable by all stakeholders • Enable positioning the platform as a product
- 16. Cisco’s collaboration architecture emphasizes interoperability and openness, allowing any device or application to use core collaboration services enabled through a set of flexible deployment models
- 17. Roadmaps – Making it Actionable • We love product roadmaps and the longer the roadmap, the greater our pride! • Do we have a technology roadmap? – “What is the state of VoIP?” – “What is the state of HTML5 vis-à-vis Flash for rich web apps?” • Do we have an industry roadmap? – “When does telepresence become relevant?” • PM and Engineering need to collaborate on creating multiple roadmaps and go beyond a roadmap that just states product release cycles
- 18. Thoughts, Thanks • Summary • Value Analysis – Value Expectations – Limiting Factors – Change Agents • Platform as a product – Intangible indicators of value • Multi-layered roadmaps – Technology roadmap – Industry roadmap – Product-Technology roadmap – Product roadmap
- 19. Product Professionals Networking featuring Rahul Abhyankar Prioritizing Technical vs Market Requirements Starting soon.. 10:00-10:15 Networking 10:15 Speaker Starts Next Networking Events in Bangalore Dec 10 – Product Management for SaaS Jan 7 – Monetizing Ideas on Mobile, SaaS, B2B Feb 11 – Market Validation through Social Media Mar 3 - Proven models for Idea Validation 23 http://www.adaptivemarketing.in
- 20. Announcing a new workshop on Adaptive Workshop on Usability and Interface Design Duration: 1 day (9:00am-5:00pm) Date: Nov 26th (Bangalore) Price: 12,000 Rs. (FREE for Adaptive Xchange members) Ideation Market Visual Information Design Design Problems Validation Architecture Layout Styling 24
- 21. Congratulations!! Jayprakash Velu, AMD Certified Product Manager (CPM) Aswin K, Consona CRM Certified Product Manager (CPM) 25
- 22. Scheduled Training Offerings Open Adaptive Adaptive Adaptive Adaptive Workshops Product “Productizing” Advanced Advanced Management Workshop for Workshop for Workshop for Professional Engineers Product Mgr Sales & Marketing Duration 5 days 2 days 2 days 2 days Audience 5+ years 5+ years 4+ years of 4+ years of experience in experience. PM/PMM, customer facing product Engineers, Project experience, MBA BD, PM/PMM, company Managers, desirable sales experience Architects Focus Career Developing a Advanced PM Focus on setting Transformation customer & skills, managing up and running workshop that business context multiple product sales and builds around building lines, new marketing foundational products. product operations. skillsets to Understand P&L, launches, Business Leveraging online become a Business plan, plans, social marketing, social global PM success metrics media media Certification AIPMM, USA Adaptive Product AIPMM, USA AIPMM, USA Certification Professional Certification Certification 26 (CPM/CPMM) Certification (CPM) (CPMM)
- 23. Upcoming Events (sign up at www.adaptivemarketing.in) Bangalore Certification PM Workshop (5days) Dec 9th Detailed Schedule at Advanced PM Workshop (2days) Dec 9th www. Productizing Workshop for adaptivemarketing.in Engineers (2 days) Oct 28th New Workshops (1 day) More Information & Agile for Product Owners Nov 15th Registrations at Design/Usability for Product Professionals Nov 26th engage@ Social Media for Product adaptivemarketing.in Managers (TBD) 27
- 24. Envisioning a 1 year Executive Program for Product Professionals Looking for senior PMs, Engineering Leaders to help shape the curriculum and setup industry board. Focus Group for Academy for Productizing Innovation on Nov 21st. If you are interested let us know at api@adaptivemarketing.in 28
- 25. engage@adaptivemarketing.in Have an idea? Have a suggestion on the speaker/topics? Group “Adaptive Marketing” 29
Editor's Notes
- #10: If a system is to be effective at satisfying the value models of its stakeholders, it needs to be able to identify and analyze them. Traditional approaches, like use case scenarios or business/marketing requirements, start by focusing on the types of actors with which the system interacts. This approach has several major limitations:It focuses more on what things the actors do, and less on why they do them.It tends to stereotype actors into categories, where all individuals of a type are essentially the same (traders, portfolio managers, or system administrators, for example).It tends to ignore differences in limiting factors (for example: Is an equity trader in New York the same as one in London? Is trading at market open the same as trading during the day?).It is based on binary outcomes: the requirement is met or it isn't. The use case completes successfully or it doesn't.There is a very logical, practical reason why this approach is popular. It uses sequential and classification-based reasoning, so it is easy to teach and explain, and it can produce a set of objectives that are easy to verify. Of course, if simplicity were the only goal that counted, we'd all still be walking or riding horses to get from one place to another.
- #19: Subsystems and ComponentsDeploymentUsers, External systemsInteraction, ProtocolsConfigurationExceptionsConfiguration options for featuresDependenciesAbility to support change while retaining stabilityAnticipated changes