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