AMA stands for ‘Ask Me Anything’ where you’ll have the chance to ask our featured guest any question you’d like. Our product guest of honor is:
Kenneth Berger has spent 10+ years leading tech products through the full product lifecycle. He was the first product manager at Slack, responsible for the core product through its growth from 100k to 1M+ daily users.
He co-founded YesGraph (backed by Accel Partners, Founder Collective, NextView Ventures, and others) and built it from a nascent idea to a launched product in active usage by companies like Airbnb, Pinterest, and others. At Adobe, he helped build some of its first SaaS products, managed the $100M+ Dreamweaver business, and drove critical acquisitions including Typekit, Omniture, and Behance. He also work with the portfolios of several venture capital firms and accelerators (First Round Capital, Flybridge Capital Partners, Acceleprise) as a product management advisor/mentor.
He currently provides executive coaching to leaders at startups and other growing companies. In addition to his coaching work, Kenneth also offers consulting and advisory services for companies seeking to improve alignment and facilitate growth.
Kenneth earned a master’s degree in Human-Computer Interaction and a bachelor’s degree in Computer Science, Cognitive Science, and HCI at Carnegie Mellon University.
If there’s one book you would recommend to every PM, which one would it be?
Books can be tough since the world of product management changes so fast. Something broad on design and user research like The Design of Everyday Things would be a good place to start.
What do you think about getting PM experience in Silicon Valley vs. other places in the world?
The best way to learn product management is simply to do the work. While I definitely believe in mentorship, often it can be hard to find on the job. So I don’t necessarily think PMs in the bay area have a big advantage over other places in terms of learning.
As you came on as the first PM at Slack, how did you help grow the rest of the PM team/function? What did you envision and what roadblocks did you run into that you weren’t expecting?
To me the the most important thing about growing the team was doing it methodically, not being afraid to throw out process if it wasn’t working.
Part of the value of our earliest PM hires were bringing their various backgrounds and experiences so that we could try out different things and see what worked for our scale at the time.
Which classes in college helped you develop your product management skills?
I’m very biased since I started my career in user research, but the classes that focused on going out and talking to customers were really valuable for me at CMU. Those are fundamental skills I still use every day.
How do you think about building in customer delight into a product? How do you weigh it against other priorities? e.g. How did the team come up with & then roadmap / execute “several people are typing” and the customizable quotes that appear when slack is first loading?
I actually wrote a whole Medium post about this called Peaks and Valleys!
In short, give the team cultural permission to build in a scattering of quick, easy delightful moments for the customer alongside the meat and potatoes of core product functionality.
You’ve worked as startup founder, PM and now a coach. Can you share a bit about your career progression and the reason for the choices?
I moved from user research to product in order to have a broader impact: not just make recommendations, but make decisions.
I became a founder for much the same reason: to truly see the big picture.
But once I passed 10 years as a PM I became more interested in developing people than products, thus shifting to more writing, speaking, mentoring, coaching, etc.
When there are changes in product/roadmap priorities, how do you handle this with your engineering and design team? Any tips on how to keep team morale and energy high in these scenarios?
Having really crisp and clear company goals can help teams better understand changes in priorities. Maybe the feature roadmap has changed, but the top goals for the quarter or the year haven’t.
If you’re the first product hire for an early startup and you’re brought on to focus on growth, what would be a good framework to use to tackle growth? What would be the first few steps coming in?
A good mindset to start with when joining a new team is humility. It’s easy to feel like you need to have all the answers, but of course that’s unlikely when everything’s so new.
Instead, focus on simply collecting data. Talk to everyone on the team, understand their concerns and priorities. Talk to customers, talk to potential customers, talk to lost leads. Dig into analytics and see what jumps out at you.
Simply use the product, get to know it inside and out. Answering customer support requests can be a good way to do this. You’ll find simply bathing in data will help you find your way to the right priorities.
As someone transitioning to a PM role, which would be a good first position: a company which is in its maturity phase or the decline phase?
I find the best way to transition to a PM position is to transition to the role on a team that already trusts you. In some ways building trust is the toughest job a PM has, especially on a new team, and especially when you lack experience.
So I would prioritize finding a scenario where you can accomplish that over early vs. late stage.
When you started working on Slack, what were the fundamental problems you were solving for? And what was your strategy solving them?
When I started working on Slack, we had just launched and were already reeling from our unexpected popularity. So our fundamental problem *at the time* was simply keeping up with fixing bugs and not letting customers outgrow the product.
Good example of how sometimes you don’t get to focus on the sexy stuff of building a long term vision, you’ve got to fix an immediate urgent problem. It was months before we could really focus on big features again.
What’s your most memorable failure? What did you learn?
My most memorable failure was not bringing on sales and marketing expertise earlier at my startup YesGraph.
As PMs we have to learn everything fast, and I think it gave my cofounder and I a false confidence we could just read some books and figure it out.
Turns out sometimes you really need deep experience and expertise, and unfortunately we realized that too late.
Any advice on how to balance the team’s effort on new product discovery and executing known winners on the backlog?
I’m going to bring this back to company goals again. I feel like too many companies (and especially startups) don’t take goals seriously, like it’s a stodgy big company thing.
But if you don’t have true agreement on goals, it has a huge negative effect on the company, people can go off in all different directions.
Whereas with a real discipline to focus on the one or two most important things for the quarter (for example), it often can suddenly make clear what needs to happen now and what can wait.
Can you share product you admire nowadays? And why?
I’m a huge fan of Timehop in part because I know the team, but also because they’ve had an incredible dedication to iterating and refining the product. While many other products would have built lots of bells and whistles seeking growth, Timehop has simply redesigned the same core features over and over and over.
I’ve seen it happen over the years, and I’ve always been impressed by their dedication to building the best possible instantiation of the core product idea.
To build on your answer re: when you joined you were working on fixing bugs and not letting customers outgrow the product. How did you know what to focus on next (e.g. what were your inputs)? How did you (your team) discover the next set of problems to focus on?
It’s a simple answer, but honestly we just followed the customers we wanted. That’s different from simply implementing customer requests.
It meant that we were listening to what potential customers wanted, and seeing where that jived with the core product vision. So we didn’t build everything they wanted, we saw where what they wanted and we wanted overlapped. That’s a little vague but hopefully helpful.
I should also mention that we were in the lucky position of having a ton of customer demand. Obviously product development and prioritization is very different prior to product/market fit.
What’s one thing you’d recommend PMs do outside of their day-to-day to get better at product?
I don’t know that there’s one thing I’d recommend the same for every PM, but I do think that in some sense the PM job description is impossible.
Who could possibly be an expert at all the things you need to do this job?
The reality is all of us have areas we’re stronger and weaker at, so I would simply identify the areas you want to grow.
That’s how I started doing more coaching and mentoring, since I wanted to get better at management.
At what point did you know you had product market fit at Slack? Before / early in / or towards the end of the private release? What did you measure to give you the answer that it was time to go public release?
This is actually an interesting one, because though we already had pretty impressive growth and engagement prior to launch, we had not asked anyone to pay.
That was the key thing we tested with launch: OK, they like us, but do they like us enough to build a real business? So it wasn’t so much that we knew we had product market fit, it’s that we knew we had to test for it by charging. Thankfully that bet worked out!
To continue the question, what type customers were you seeking at that time? How did you know those were the right customers?
I hesitate a little bit to answer questions like these only because Slack’s scenario was so particular: few of us are so lucky to be riding a wave of such strong customer demand!
Product direction is always a bit of a bet, you’ll never be 100% sure. But take teams like this one we’re in for example: we had lots of demand for community team features, but community teams tend not to pay for Slack. And our company mission was about improving work, not about improving community tools.
So we focused on building features to support enterprises over those to support community teams (for example).
Which feature do you think was the killer feature that got you initial traction at Slack? Were you expecting it to be a hit with customers or was it an unexpected discovery?
One of things that’s powerful in how Slack teams grow is that they’re useful at a variety of scales. You can have a team of only three people and still have fun conversations, you don’t need to be 100 or 1000 or 10000 people.
And once people are talking, other people are curious what they have to say! So FOMO was a more powerful force than I expected. Not exactly features, but pieces of the extended onboarding from new team to mature team.
How do goals tend to evolve as startup grow rapidly? Also as the team at Slack grew in size, how did you guys ensure that everyone is aligned on the goals?
I think the most important change is the distance between individual goals and company goals get further.
I’ve always felt like building that connection should be one of the most important parts of building a goals program. i.e. Each and every employee should feel crystal clear and how their personal goals support the company’s goals.
I’m not sure we ever got this right at Slack, it was particularly challenging given how fast we were hiring new people. I think the average company may have an easier time since it’s a bit more stable.
When an experienced PM joins a company and a team that hasn’t had much experience working with product managers, how do you build that trust? How long should it take?
I would make much the same suggestions I made above related to joining a new team. Be humble, collect lots of data, try for a quick win if you can. Teams seldom want an outsider to come in with their own vision, often it’s more winning to act as a mirror: show them something they and/or their customers have been saying that they didn’t quite see yet.
What tool did you use to communicate your roadmap and backlog to stakeholders?
We were super flexible on this since what was appropriate changed a lot as we grew. In the early days we were using Hackpad (now Dropbox Paper) and a spreadsheet.
How many development teams and product managers did Slack have by the time you left, and how did you scale them? Group PMs? How did you scale goals and strategic planning?
I think Slack had about 6-8 PMs when I left, we were all still reporting to the CEO. That was just about when they hired a VP PM and promoted some folks to GPMs.
What did your hourly allocation look like as a PM at Slack? how much of your time was dedicated to user research and interviews vs. interfacing with engineers/designers or other work?
I’ve always hated the “PM is the CEO” thing since it my experience it’s a lot more like being the handyman. There is no typical day for the handyman! They just do whatever needs to be done, and whatever other people can’t or won’t do for themselves.
So in the early days I did a ton of research because our team was small and we didn’t need much coordination.
By the time I left I was doing a huge amount of project management and people management since PMs were now integral to the development process. So if I didn’t do that work I was blocking development!
What channels would you utilize for a startup with no marketing budget? I know Slack used PR, started a invite-only group, etc.? Which channels have proven to have the high new user conversion, retention, and overall growth?
It all depends! To me this is the tough thing about a “growth-first” product mindset, it sidesteps the fact that every company is unique, every product is unique, every set of customers is unique.
Sure there are a few best practices within consumer, SaaS, etc. But fundamentally I don’t like the approach of starting with growth techniques. I start with a product idea and a set of potential customers and go from there.
Join 18,000+ Product People and Get a Free Copy of The PM Handbook and our Weekly Product Reads Newsletter
Subscribe to get:
- A free copy of the PM Handbook (60-page handbook featuring in-depth interviews with product managers at Google, Facebook, Twitter, and more)
- Weekly Product Reads (curated newsletter of weekly top product reads)