The document summarizes a presentation given by a Slack software engineer on how to plan for success during periods of hyper growth. It discusses common challenges startups face like rapid scaling, communication issues, and lack of experience. It provides a case study of challenges Slack faced with an MDM project and lessons learned. The key messages are to provide strong leadership through documentation like a living product specification, use concise user stories, and over-organize to avoid issues as a company scales rapidly.
12. Relevant Experience:
- 2.5 years of engineering through
Slack’s hyper growth phase
- Feature lead on cross-functional
teams, deadline driven projects
- Several PMs: different styles,
experience levels
- Lots of mistakes, lots of lessons
13. Agenda
1. Hyper Growth Environments
2. Common Challenges for Software Teams
3. Case Study: Slack EMM
4. Avoiding Pitfalls with A Living Product Spec
5. Case Study: Rest of World Billing
6. Closing Remarks
15. “”
During the past decade, as technological
convergence has moved progressively
forward, rapidly rising companies have
astonished the global public with their
ability to expand and scale at a pace
that was previously unknown. From this
phenomena the term “hyper growth”
was coined.”
- World Economic Forum
17. Slack is making work
simpler, more pleasant,
and more productive.
At Slack, we’re building the platform that
connects teams with the apps, services,
and resources they need to get work
done.
18. Slack is Building the Ecosystem for Work
Cross-Workspace Communication
through Shared Channels
Searchable Archive of Messages
Leader in Enterprise Security
1,000 of Apps and Integrations to
Streamline your workflow
20. Slack is a Hyper Growth Startup
Unprecedented adoption rate
to date
6M Daily active
users
55%of users outside
the US
2.25 Hours of daily active
user engagement
21. Slack is a Hyper Growth Startup
Fastest company to reach 100M
in ARR
22. Slack is a Hyper Growth Startup
Fastest Startup to reach $2B
Valuation
25. Lots of Projects, Lots of New People
When you are growing fast,
everyone is new. When
everyone is ramping up at the
same time, everyone is a
beginner.
28. Issues Scaling Management
Engineers with expanding
departments tend to start
leading teams -
communicating, planning
full time - instead of
writing code.
30. Engineering Codebase Compromises
1. Over engineer a system for massive
scale, putting time intensive
processes in place to make things
flow smoothly
2. Chase rapid growth with a system
constantly stretched over capacity
and accept things will be messy.
32. Product Development Life Cycle (The Product Book)
1. Find the right opportunity
2. Design the solution
3. Build the solution
4. Share the solution
5. Assess the solution
33. Product Development Life Cycle (The Product Book)
1. Find the right opportunity
2. Design the solution
3. Build the solution
4. Share the solution
5. Assess the solution
Majority of
your time.
Limited soft
power.
35. Top 10 Reasons for Slow Velocity (svpg.com)
● Lack of strong product owners
● Lack of strong project
management
● Infrequent Release Cycles
● Not including engineers during
product discovery
● Not utilizing user experience
design in discovery (having
engineers try to do it in sprints)
● Lack of product vision + focus
● Lack of dedicated teams
(engineers treated like chess
pieces)
● Lack of dedicated rapid
response team
● Inflexible product architecture,
technical debt
● Missing a holistic view
36. 2/10 Slow Velocity Causes: Hard for PMs to control
● Lack of strong product owners
● Lack of strong project
management
● Infrequent Release Cycles
● Not including engineers during
product discovery
● Not utilizing user experience
design in discovery (having
engineers try to do it in sprints)
● Lack of product vision + focus
● Lack of dedicated teams
(engineers treated like chess
pieces)
● Lack of dedicated rapid
response team
● Inflexible product architecture,
technical debt
● Missing a holistic view
37. 7/10 Slow Velocity Causes…. You can avoid!
● Lack of strong product owners
● Lack of strong project
management
● Infrequent Release Cycles
● Not including engineers during
product discovery
● Not utilizing user experience
design in discovery (having
engineers try to do it in sprints)
● Lack of product vision + focus
● Lack of dedicated teams
(engineers treated like chess
pieces)
● Lack of dedicated rapid
response team
● Inflexible product architecture,
technical debt
● Missing a holistic view
39. MDM: Ingredients for a Perfect Storm
● Cross functional (iOS, Android, AppEng)
● New PM (first xfn project)
● New EM (first project)
● Not enough engineers
○ Two Senior Engineers => 1 Jr.
Engineer
● Novice Product Spec
● Marketing Driven Deadline
40. The Build: MDM for Enterprise
● Rookie “Agile” Approach
● Scope Creep => New iOS App
● Confusing Bugs
● Ownership unclear
● Jr. Engineer working in New Code.
● Lots of long days...
41. All the Mistakes!
● Lack of strong product owners
● Lack of strong project
management
● Infrequent Release Cycles
● Not including engineers during
product discovery
● Not utilizing user experience
design in discovery (having
engineers try to do it in sprints)
● Lack of product vision + focus
● Lack of dedicated teams
(engineers treated like chess
pieces)
● Lack of dedicated rapid
response team
● Inflexible product architecture,
technical debt
● Missing a holistic view
43. Studying Hyper Growth Startups
- One size does not fit all.
- Facebook’s “Move Fast and
Break Things” works for many
consumer facing companies.
- Slack has to move fast, but
breaking things results in
millions of dollars in losses
for our customers.
47. “”
“There’s not always one perfectly clear,
right answer for every problem. Instead,
we want to focus on the customer’s
underlying needs and motivations to
make sure whatever answers Design
and Engineering come up with will solve
the problem.”
- The Product Book, pg. 160
48. The Product Book: Chapter 5 - Product Specs
- Clearly explains why you are building this Product
- Addresses internal goals, customer goals, key metrics
- User Stories outline exact scope - features and functionality
- Clarifies what you are not building
- Feature Lists: essential, really want, nice to have.
- Open Issues
- Documents Key Decisions
- Documents Relevant Information
49. Product Specs:
- Waterfall
- Unchangeable
- A Novel
- Dictating
- Lacking Detail
- Incomplete sentences in bullet
points
- A Living Document
- Collaborative
- Flexible
- A Go-To Document for
key decisions
- Concise user stories to
convey requirements
- Updated as project
progresses
51. Leadership
- Lead in person. Lead on Paper.
- Explicitly define roles and ownership.
- Facilitate collaboration with Tech + Design
Leads early and often.
- Don’t be afraid of the details (feature flags)
52. Storytelling
- Keep your user stories concise. If they get too
long, break them down more.
- Use complete sentences: context, action,
result.
- Your audience = engineers : your user stories
should translate into trackable units of work.
53. Over-Organizing
- Be thorough: know your resources.
- Be Prepared to be the Project Manager
- Automate as many details as possible.
- Check and recheck the requirements are
satisfied.
55. TL;DR:
- Similar MDM Team Dynamics
- Very Tight Deadline
- Development finished 2 weeks ahead of
schedule.
- No Post Launch Bugs
56. Key Messages: Leadership, Storytelling, Over-Organizing
- Set clear boundaries of
ownership.
- Know your team’s abilities and
plan accordingly.
- Get everyone in the room as early
as possible (esp. Design +
Engineering)
- Design influences engineering
Implementation.
- User Stories=Units of Work
(Concise, Full Sentences, Top
Down, Bottom Up)
57. Ever tried. Ever Failed.
No Matter. Try Again.
Fail Again. Fail Better.
- Samuel Beckett
“”
61. Part-time Product Management Courses in
San Francisco, Silicon Valley, Los Angeles,
New York, Austin, Boston, Seattle, Chicago,
Denver, London, Toronto
www.productschool.com
Notas do Editor
When you checked in tonight, you got an email inviting you to join our slack community
In that community, we have 15k product people who have come through different companies like google, facebook, uber
Sharing information about events, job offers from our partner companies, and valuable online content
Please check your email and join - it’s free
In our PM Course, we teach how to build products and how to get a job as a software product manager
All our classes are 2 months, part time, and compatible with full time jobs. We have two options, Tues/Thurs in the evening and Saturdays in the morning
Instructors- are senior level product managers from companies like Google, FB, Uber, etc
In addition to our PM class, we offer our Coding for Managers class
Also two months and part time tailored for professionals who don’t come from a traditional engineering background
The goal of this course is not to make you a software engineer, but to give you enough technical background to build a fully functional website and pass the technical interview
Similar to our coding course, we also offer our Data Analytics for Managers
Tailored for people who don’t have a technical background but to give them enough knowledge of analytics to become product managers
Also two months, compatible with full time jobs
The goal of the course is not to make you a data scientist, but to make you technical enough to understand web analytics, learn SQL, and machine learning concepts
We are also live streaming our event to our online audience
If you want to share, please tweet @productschool and #prodmgmt for a free ticket to our next event
What I know about the audience
What they know about me
My authority:
Non-engineers, engineers perspective
For engineers,
Be thorough: know your resources.
Work closely with your EM
Know what you are missing + delegate.
Be Prepared to be the Project Manager
Automate as many details as possible.
Set reminders to follow up.
Keep a spreadsheet
Checklists
Check and recheck the requirements are satisfied.