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.
Subsystems and ComponentsDeploymentUsers, External systemsInteraction, ProtocolsConfigurationExceptionsConfiguration options for featuresDependenciesAbility to support change while retaining stabilityAnticipated changes
Product Strategy & Architecture - Rahul - 12Nov11
Product Strategy & Architecture Rahul Abhyankar Nov 12, 2011
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?
We exist to create value! PM Engineering WHAT? HOW? WHY? Business CaseMarket Requirements Architecture Product Engineering Requirements Requirements
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?
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
How do we discover Value?• Expectations of value – What are the needs – What are the capabilities to address the needs – How well are they provided (quality)
How do we discover Value?• Limiting factors – What makes it difficult to satisfy the value expectations?
How do we discover Value?• Catalysts to value – Events that cause value expectations to shift OR – Limiting factors to have a different impact
Value Analysis• Expectations of value• Limiting Factors• Catalysts of value• HOW SATISFIED IS OUR MARKET?• HOW DIFFICULT WILL IT BE TO SATISFY IT?• WHAT WILL DISRUPT THE MARKET?
Deployment Context Single Context Products Multiple Context ProductsAll deployment scenarios have Different deploymentequivalent value expectations environments, valueand limiting factors expectations, limiting factors
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
Where does this fit? Value Analysis ArchitectureRequirements Definition
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
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
Cisco’s collaboration architecture emphasizes interoperability and openness, allowingany device or application to use core collaboration services enabled through a set offlexible deployment models
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
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