Building and scaling a product team is a challenge that every successful product company faces.  Brainmates hosted this Sydney AU meetup where we talked about: - When and how does a startup hire its first product manager? - Division of labor: how do we grow from one to three to many product folks? - End-to-end management of product elements/features, or product owner and business owner roles? - How big is too big?

1. Building and Scaling
a Product Team
Rich Mironov
Brainmates / Sydney
1 March 2018
1

2. 1. Why We Need Product Management
2. Hiring Your First Product Manager
3. Product Organizations
4. How Big is Big?
Agenda

3. Founders and exec teams rewarded for shortest
path to short-term revenue
We balance enthusiasm with market honesty
• Market fit, whole product, real value
• Segments/scalable revenue vs. deals
• Represent customers and company-as-a-
whole
Why Do We Need
Product Management?

4. Context, conversations, market view,
priorities, problem statements,
roadmaps, epics, user stories,
backlogs, personas…
product
bits
Revenue forecasts,
commitments, roadmaps,
strategy
budgets, staff,
targets
“ input & feedback”
Sellable stories, segmentation, messages,
benefits/features, pricing, demos…
Markets &
CustomersDevelopment
Marketing
& Sales
Executives
Product
Management
What Does a Product Manager Do?
4

5. Customers are experts
in what they want to
achieve, not how to
achieve it.
- Alex Osterwalder

6. • Business cases (1980’s)
• Cross-functional teams (1990’s)
• Agile development (2000’s)
• Clearer problem understanding,
better solutioning (1990’s-2000’s)
• Jobs To Be Done, customer
development, validation, user
journeys, design thinking…
Where’s Our Product Leverage?

7. We don’t “gather requirements”
• Teams frame problems
• Collectively find elegant
solutions
• Earn customer trust, love,
renewals, referrals
Problem-Framing and Solution
Design are Contact Team Sports

8. 1. Why We Need Product Management
2. Hiring Your First Product Manager
3. Product Organizations
4. What Heads of Product Do
Agenda

9. Someone “Plays” Product Manager

10. CEO
CTO
DevDev/UX
Dev/Build
Startup Don’t Have Org Charts Or
Formal Processes
Pitch, funding, biz
model, vision, BD,
sales, marketing,
PR, legal, office
space, payroll
Architecture, code,
hiring, customer
pitches, hiring, code,
resolve tech
disputes…
Front end, code,
UX/UI, mobile client,
code, “how it works,”
user support
Back end, code,
cloud, data & APIs,
code, security, code,
performance, code…
Code, repository,
build, code,
backup, platforms,
testbed…

11. • N2
employee conversations
• Surprise customer
commitments
• Costly sales one-offs
• Pricing & packaging
• “I bet hundreds of customers
want that”
Problems At Scale

12. • 12-25 employees
• Complexity outgrowing founders
• Sales pressure warping product resolve
• Need scalability, less revenue friction
• Focus, focus, focus, focus
When to Hire Your First Product
Manager

13. • Need
• 3+ years experience as actual product manager,
with product manager title, on revenue products
• Not substitutes
• SME or deep technical expert
• Eager volunteer from another role
• Scrum master/project manager
• Product Management certificate
• “I did something just like that”
Choosing Your First Product Manager

14. • CEO or VP Sales stays primary
source of customer insights
• Daily “Can’t we just…?”
• Unsuccessful PM lobbying for
• Broad segment needs
• Outcomes for users
• Repeatable, low-friction products
• Clear commitment process
Top Failure Mode

15. 1. Why We Need Product Management
2. Hiring Your First Product Manager
3. Product Organizations
4. What Heads of Product Do
Agenda

16. Handoffs Are the Enemy of Insight

17. Reducing Distance
Product
Owner
Dev
Team
Biz Prod
Mgr
Users &
Custs
Dev
Team
Prod Mgr
Users &
Custs
Dev
Team
Users &
Custs
Prod
Mgr
Dev
Team
Sales &
Mktg
Our CustsProduct
Dev
Team
Gartner
Their
Custs
Product

18. Stable, complete
devt team
Users
(custs)
Prod
Mgr
Value/Functional Area
Frequent, in-depth, non-sales learning
conversations
Product Structure I Like
Prod
Line Dir
Stable, complete
devt team
Users
(custs)
Prod
Mgr
Value/Functional Area
Frequent, in-depth, non-sales learning
conversations
Stable, complete
devt team
Users
(custs)
Prod
Mgr
Value/Functional Area
Frequent, in-depth, non-sales learning
conversations
Stable, complete
devt team
Users
(custs)
Prod
Mgr
Value/Functional Area
Frequent, in-depth, non-sales learning
conversations
Devt
Dir

19. Learning conversations, problem
definition, solutions
Users
(custs)
Requirements
Product Structure I Don’t Like
Prod
Line Dir
Stable, complete
devt team
Users
(custs)
Prod
Mgr
Stable, complete
devt team
Prod
Mgr
Stable, complete
devt team
Prod
Mgr

20. Requirements
Product Structure I Don’t Like
Stable,
complete devt
team
Team
rotates
Prod
Mgr
Users
(custs)
Stable,
complete devt
team
Prod
Owner
Mkt
Mgr
Users
(custs)
Stable,
complete devt
team
Prod
Mgr
Prod
Mgr
Users
(custs)

21. • Write/accept/prioritize stories
• Available to team at all times
BUT
• Proxies define needs
• No time, training or reward for
direct end user discovery
• Productivity focus, not end value
• Assigned after big decisions
Product owner is a role, not a job
IMHO, Scrum-Defined Product
Owners Are Set Up to Fail

22. “The Business”
Product Structure I Hate
CIO
Project team
from pool
BA
Project team
from pool
Tech
PM
Project team
from pool
Prod
Owner
Tech Reqmts
Delivery Dates
Prod
Exec
Mkt
Mgr
CAB
Prod
Dir
Sales
Mktg
Prod
Mgr
Users
(custs)
“IT”

23. 1. Why We Need Product Management
2. Hiring Your First Product Manager
3. Product Organizations
4. How Big is Big?
Agenda

24. Largest practical product organization might be…
• 1 VP PM, 4 Dir PMs, 16 PMs
• 1 VP Eng, 4 Eng Dirs, 16 functional managers, 16 teams,
<200 total in Engineering org
• Developers, designers, test automation, DevOps, tech
writers, scrum masters/coaches, PMO…
• Frequent team-level or group-level releases to live users
• Must split larger product sets or problems
• Separate product sets with separate revenue pressure
• Brilliant architectural decomposition
• Explicit APIs: supported and externalizable
• Fully automated integration/performance testing
How Far Can We Scale?

25. • Cognitive load, dependencies, discovery,
complexity à waterfall
• Impossibility of fully spec’ing large systems
• Delivery plan > 12 months?
• Discovery/scope creep grow with duration
• Full system replacements/forklift upgrades?
• Details of “legacy” systems never fully
understood
• Delay of real market feedback (revenue)
• “Innovations” are less shiny 24 months later
Huge Projects Usually Fail

27. 1. Need for product management is
not obvious
2. Hire for product experience
3. Product managers own real market
value and direct customer learning
4. ”Too big to understand” probably
means “too big to succeed”
Takeaways

28. Rich Mironov
Mironov Consulting
San Francisco, CA, USA
www.mironov.com
+1-650-315-7394
rich@mironov.com
@richmironov
28