MPCS 51240: Lecture 06
November 3, 2021
Product Management
Presentation based on unpublished work copyright (c) 2017, Vas Vasiliadis. All rights reserved. Modi ed and used with permission.
fi
Release-based vs. Feature-based roadmaps
Release-based Feature-based
❖ Show milestones and major ❖ Show themes and all features
features in release
❖ Less detailed; features ❖ Includes detailed resource
described mostly by name requirements
only ❖ Often includes more detailed
schedule (Gantt chart)
❖ Better for sharing with
executive team and ❖ Better for discussions with
external stakeholders development team
Releases
❖ Contain enough features to deliver new customer value…
❖ …but manageable enough to create a “win”
❖ Think of releases in terms of themes (vs. only timeline)
❖ Releases vs. Sprints vs. Weekly/Daily deployment
Release planning
❖ Prioritize within a release (may be your hardest task)
❖ Avoid the “must deliver” trap
❖ Learn to put development “estimates” in context
❖ Ensure progressive enhancement across releases
Constraints …and setting realistic expectations
Most of the time we want to drive here
5
Constraints …and setting realistic expectations
But we must plan for driving here
6
Maintaining strategic focus
What a great idea. I’d love to
put it on the roadmap, but as
Awesome idea! it doesn’t get us closer to the
We’ll get right vision, unfortunately I can’t
on that! take it on right now. Sorry!
Beware requests that mortgage your product’s future!
7
Communicating the roadmap to customers
Source: http://dilbert.com/
8
Brief detour on estimating
❖ De nition + design and technical architecture
❖ Integration/user testing + release quality checks
❖ With time you will nd your own multiplier…
9
fi
fi
Building buffers
Daily deployments
Spot (sanity) testing Integration testing Release blockers
Deploy
Release Release
Dev/ Staging
Test Target
Sandbox
T-2x T-x T
10
Product Architecture
11
What is it?
❖ Identify all the pieces
❖ Describe (and understand)
how the pieces t
together (functionally)
❖ Reduce complex,
monolithic product into
simpler, implementable
components
12
fi
Goal: De ne a set of
suf ciently simple
components that interact
in well understood ways
13
fi
fi
Product architecture is key to holistic design
❖ Agile design/development increases risk of shortsighted
architectural decisions
❖ Good architecture is not “documentation”
❖ Provides the framework for technical architecture (often
hard to differentiate between the two)
14
Example: Retail website
❖ Products: catalog management, product search (CDN)
❖ Ful llment: logistics integration, inventory control
(interface with physical systems)
❖ Purchase: cart management, payment management (high-
speed transactions, external service integration)
❖ Marketing: ratings, recommendations, promotions (data
analysis, external service integration)
15
fi
What is “good” architecture?
❖ Intentional structure and behavior (what and why)
❖ Appropriately high degree of modularity (loose coupling)
❖ Unambiguous component description —> well-de ned APIs
❖ No functional duplication
❖ “Lightweight” documentation
16
fi
Typical architectural considerations
❖ Functionality (minimal —> rich —> comprehensive)
❖ Usability (tech savvy —> mainstream —> all)
❖ Reliability (best effort —> 24x7)
❖ Performance (multiple de nitions!)
❖ Supportability (Trial/Error —> instrumentation —> self-healing)
❖ Security [functional] (simple AuthN/Z —> comprehensive IAM)
❖ Security [operational] (basic IDS—> fully hardened, isolated)
❖ Implementability (general —> highly specialized)
17
fi
Architecture validation
❖ Scenario driven validation
❖ Describe a hypothetical
❖ Walk through architecture to identity disconnects
❖ De ne (and implement) tests
❖ Example hypothesis: Order execution is dependent on account status
❖ Expect: orders for inactive accounts will not be executed
❖ Test: submit order via inactive account
❖ Expect: margin orders for 401(k) accounts will not be executed
❖ Test: submit margin order via 401(k) account
❖ Identi es: impedance mismatch between components, corner cases
❖ Delivers/informs: detailed design, user docs, starter code
18
fi
fi
Product architecture framework
❖ Decompose
❖ Abstract
Iterative
Decouple
Re nement
❖
❖ Implement
❖ Refactor
19
fi
Revisiting our stock brokerage
Symbol lookup
Delayed quotes
Position tracking Live charts
Market and limit orders OCO orders
User registration and authentication EFT and linked bank accounts
Traders
4Q17 First beta 1Q18 First Expo 2018 4Q18 Cash ow
paying Series A break
release
customer even
Real-time quotes Chart overlays
Static charts Scenario analysis
Watch lists Order strategies
Stop orders Real-time account provisioning
Online account application
20
fl
Categorized features
Symbol lookup Delayed quotes
Position tracking Live charts
Research Chart overlays Scenario analysis
Real-time quotes Static charts
Watch lists
Order Market and limit orders Stop orders
Management OCO orders Order strategies
User registration and authentication
Account EFT and linked bank accounts
Management Real-time account provisioning
Online account application
21
Decomposition
❖ Breaks system into
composable parts
❖ HOW? Function groups,
complexity boundaries
❖ WHY? Because we’re
human, after all
22
Starting point: Easiest to
begin with one “component”
for each category (or major
subcategory) of features.
Iteration #2: Decompose each of the initial components into more granular
ones and identify the key data ows among them.
fl
Iteration #2 (continued): In this example, decomposition of the Research
features provides more detail about the data expected.
Iteration #3: Further decomposition of order management, after thinking
through additional capabilities that will be required.
Iteration #4: Even more detailed decomposition of the Trade Execution
component.
Data Modeling: A good proxy
❖ Iterate between component/service architecture and data
modeling
❖ Start with high-level data model…
❖ …evolve to data schema descriptions (and database
implementation constraints)
28
Abstraction
❖ Shields “consumer” from internal details/complexity
❖ WHY? Critical for decoupling, outsourcing, refactoring
❖ HOW? One common approach - standard APIs
29
Decoupling
❖ Reduces (eliminates) system
level dependencies
❖ WHY? Availability, scalability
❖ HOW? Application Layers,
Message Queues, Webhooks
30
Refactoring
❖ Simpli es/ xes/improves/.…
existing functionality
❖ WHY? Product changes,
performance, technical debt
❖ HOW? Decomposition,
Abstraction, Decoupling
❖ …or REDO!
31
fi
fi
Implementation
❖ De nes approaches, sets context for tech selection
❖ WHY? Time-to-Market, portability, cost reduction, technical
debt avoidance
❖ HOW? Tech exploration/prototyping, Buy vs. Build
32
fi
Business Models
33
RT
Resources Transaction
RV TV
Value
Model Components
❖ Resources
❖ Tangible and intangible
❖ Specialized, unique
❖ Transaction
❖ Especially boundary-spanning transactions
❖ Value
❖ Creation and capture
❖ Bene ciary
❖ Tangible and intangible (again)
❖ Narrative
35
fi
Identifying BSTs
Bock and George: Supplemental material for The Business Model Book
Narrative
❖ Ties together the resources, value and transactions in a
single compelling statement
37
The Business Model Canvas
www.businessmodelgeneration.com/canvas
38
LEAN CANVAS Title: Created By: Date:
PROBLEM SOLUTION UNIQUE VALUE UNFAIR CUSTOMER
?
List your top 1-3 Outline a possible solution PROPOSITION ADVANTAGE SEGMENTS
problems. for each problem. Single, clear, compelling message Something that cannot List your target and users.
that states why you are different easily be bought or copied
and worth paying attetion.
KEY METRICS CHANNELS
List the key numbers List your path to customer
that tell you how your (inbound or outbound)
EXISTING business is doing HIGH LEVEL EARLY
ALTERNATIVES ADOPTERS
CONCEPT
List how these problems List your X for Y analogy List the characteristics
are solved today (e.g. YouTube = Flickr for videos) of your ideal customers
COST STRUCTURE REVENUE STREAMS
List your fixed and variable costs List your sources of revenue
Lean Canvas is adapted from The Business Model Canvas (BusinessModelGeneration.com)
and is licensed under the Creative Commons Attribution-Share Alike 3.0 Un-ported License.
39
Problems
❖ Whose problems?
40
Solutions
❖ Remember, your product is probably not a direct solution
41
Key Metrics
❖ Critical success factors
42
Customer segments
❖ Groups of customers with the same needs or purchasing
preferences
❖ Contrast the ‘market’ from Crossing the Chasm
43
Channels
❖ The paths to reach the customers
44
Unfair Advantage
❖ Discuss….
45
Unique Value Proposition
“A single, clear, compelling message that states why you
are different”
- Ash Maurya
46
Costs
❖ You may not initially have great insight into costs
❖ Start by at least identifying the categories…
47
Revenue Streams
❖ Can be more complicated than you’d think
❖ Your rst idea might not be the best idea
❖ The model may need to evolve over time
48
fi