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.

1. How to Plan for Hyper Growth Success by
Slack Software Engineer
www.productschool.com

2. FREE INVITE
Join 20,000+ Product Managers on
productschool.com/slack-community

3. Product
Management
2-month part-time
Courses

4. Coding
for Managers
2-month part-time
Courses

5. Data Analytics
for Managers
2-month part-time
Courses

6. Blockchain
and
Cryptocurrency
2-month part-time
Courses

7. Include @productschool and #prodmgmt at the
end of your tweet
Tweet to get a free ticket
for our next Event!

8. Carly Robinson

9. Software Engineer, Slack Technologies
February 2018
9
How to Plan for Hyper
Growth Success
Carly Robinson

10. My Objective:
To empower you to lead efficient,
smooth, on-time product
development cycles in any
environment.

11. Hi!
I’m Carly. I’m a software engineer at Slack.

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

14. What is Hyper
Growth?

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

16. But first,
What is Slack?

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

19. Slack’s Hyper
Growth

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

23. This is how it feels.

24. Common
Challenges for
Hyper Growth
Startups

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.

26. Moving Fast
Projects move fast, leaving a lot
of room for miscommunication
and wasted energy.

27. Communication
Not enough
cross-team,
cross-platform,
cross-functional
coordination.

28. Issues Scaling Management
Engineers with expanding
departments tend to start
leading teams -
communicating, planning
full time - instead of
writing code.

29. Not enough engineers.
Engineers have to be willing
to expand out of their core
expertise.

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.

31. Question:
What makes a
successful PM?

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.

34. Everyone’s Problem:
Top 10 Reasons for
Slow Velocity

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

38. Case Study:
Slack MDM

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

42. Moving Fast +
Breaking
Things

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.

44. Fast.
Accurate.
Organize like your life
depends on it.

45. Prepare to Succeed
Your soft influence is strongest at
the beginning of the project.

46. The Product
Spec is Your
Power Tool

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

50. Leadership +
Storytelling +
Over-Organizing.

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.

54. Case Study:
Rest of World
Billing

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
“”

58. Good Luck
herding your
cats!

59. Thank You!
59
carly@carly.codes
@carlyhasredhair

60. Q&A

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