Twitter and Slack are two of technology’s most talked-about companies. They are both category-defining products marked by hypergrowth, each amassing a large base of deeply loyal users and a valuation of more than $20B.

But Founders rarely get access to the product decisions being made behind the scenes, or the strategy and frameworks that guided them.

April Underwood was instrumental at both companies, first as Director of Product at Twitter and then as Chief Product Officer at Slack. She is a powerhouse product leader with an unusual depth of experience in growing both B2C and B2B products from 0 to 1 to ubiquity and building world-class product teams along the way.

April joins me on this episode of the NFX podcast to offer inside stories and lessons learned from leading product at Twitter and Slack. Founders and product leaders everywhere will benefit from the 3-part framework she developed at Slack for hiring great PMs, her insights about leveraging early adopters, and how product CEOs can stay close to their product teams without slowing them down.

Ultimately, great products are the result of great product leaders. And just as I experienced with Trulia, April’s biggest advice to product people is a testament that iconic startups are the result of talent x timing: “If you have the opportunity to work on something that sits at the intersection of a technological or even a business innovation, and also a cultural one, then run, don’t walk.”

Twitter vs. Slack: How Your Product Reflects Your Culture

• Your business model sets the tone. One of the biggest surprises for me and for others who joined me as we transitioned from Twitter over to Slack was just how different they were. Systemic differences. Obviously Slack is an enterprise software company where you can charge a fair price for it, whereas Twitter is an advertising-supported business. So fundamentally the way you think about the product, the business, your users and your customer is very, very different.
• Communication is the driver. Even though communication is really at the core of both of those products, their cultures were actually quite different. It’s amazing how communication is so fundamental that it can go in a lot of different directions in terms of business, culture, product experience, and more.
• Does your office feel like your product experience? When you would walk into the Twitter office in 2010, and it is probably still true in 2020, it felt like a trading room floor because it was so loud. It was kind of like the service itself — you’d see and hear employees talking to each other across the floor. There was a lot of laughter. There were a lot of surprises that would happen every day. Things would happen on the service that would catch us off guard and distract us in some ways from our work.
• Inside the Slack office. When you walked into Slack, back in 2015 when I joined, you could’ve heard a pin drop. It’s a product that’s built for work. It’s a product built for getting things done. And so when you walk into the Slack office, that permeates the culture, this concept of doing your best work and working hard. Employees were literally using the service they were building to get things done. We understood the value of having more of our conversation happen inside Slack so that other people could benefit from the back and forth, and so the next 10 or 100 employees could actually benefit from the historical backlog of those conversations. So there was less of the shouting across the floor than we saw at Twitter.

Run, Don’t Walk, To Join A Company When You See This Happening…

• Look for Timing + Talent. One of my main pieces of advice for product folks is that if you have the opportunity to work on something that sits at the intersection of a technological or even a business innovation, and also a cultural one, with a Founder that has clear product vision, then run, don’t walk. I’ve had the opportunity to do that twice.
  • When I joined Twitter in 2010, it was still the early days for mobile. To rewind, this was Barack Obama’s first term in office, this was a time when people were searching for ways to express themselves more freely in a public forum. There was a cultural shift happening that really made it feel like such a unique opportunity.
  • I felt the same opportunity when I joined Slack. From a technology point of view, most of our customers used to say they didn’t have anything to use before Slack, which suggests that there was just nothing that filled that space in their mind prior to Slack.
  • This paired up culturally with employees who now wanted to show up to work as their full selves. The ability for anyone to create a channel inside your Slack team meant that people created spaces to talk about things that were orthogonal or even completely unrelated to the work. But people weren’t getting distracted — they were moving their connection from the physical water cooler into that digital experience inside Slack.
• Early adoption begins with a clear vision like Stewart Butterfield had. To some degree, we tied ourselves to the secular trend that was already happening in the workplace. But the product was designed from the very outset for the vision that Stewart Butterfield laid out — which was for Slack to be the central nervous system for your entire company.
  • I would say that the clarity of his vision combined with connecting to that broader cultural shift in market need was what really lit the fire that drove that adoption early on.

Turning Early Adopters Into A Growth Channel

• With Twitter, our early adopters were influencers and journalists. With Slack, it was engineers and developers.
• The key is leveraging your early adopters toward your strengths, even if their use case first appears unique. At Slack, we were taking some heat that we were mostly used just by engineering teams. It finally dawned on me that this was a benefit, that we were popular among engineering teams for a few structural reasons.
  1) Finance doesn’t question the engineering team when they say they need a tool and gives them more access and bigger budgets for tools.
  2) Engineers are often the tastemakers for technology selections within the entire organization.
• Ask yourself this question: “Why is it fantastic that this is the first audience that we have? How do we leverage that to play to our strengths?”
  • We recognized that actually getting it right for our first engineering audience was the avenue for us to spread wall to wall.
  • We didn’t forget our original users to go chasing the next set of users.
  • At Twitter, we embraced journalists and celebrities by creating close ties with broadcast media to bridge online and offline communication by, for example, building a Tweet button and by promoting hashtags. This helped publishers on Twitter but it also drove our awareness and increased our audience.

The Product Is Not The Code

• The definition of a true launch. It needs to be stated explicitly that a product is not just the code.

• Great product leaders drive toward product-market fit. This is where the role of the Product Manager, and certainly the product leader, has to continue to hone that strategy, to help customers understand your vision, where you’re going, what makes you different from a competitor, and to lean into principled stances.

The long arc difference. I do think that customers over the longer arc have an appreciation for teams and companies that are dedicated to solving their problems in an earnest, honest, pure way.

Creating Network Effects At Twitter and Slack

• Product leaders need to understand network effects. Product teams think about this constantly. We might have called it “ubiquity” instead of network effects, but it’s the same concept.
  • It’s the driver to teach people how to use our product so well that they’re then driven to teach other people to use the product and it gets better when more people are there.
• Network effects in the early Twitter days: When I think about Twitter, getting a tweet button on every major news publication and encouraging creation of the content that might bring people into Twitter was a growth strategy and a way to drive network effects.
  • The work that Chloe Sladden and the media team did to convince the broadcasters to put hashtags in the bottom right-hand corner of television so that people would have a way to participate in an online conversation about this on-air experience was a massively successful growth strategy.
• Network effects in the early Slack days: Some of our developers started to use “Login with Slack” because they realized that if teams used their Slack logins, not only was it easier for them to get up and running because we took care of auth and profile and other onboarding steps but also that those people would by default have the Slack app installed. This was a constant avenue for notifications that would actually deliver more engaged teams that would be more likely to be sticky.
• Product teams should now be the growth team too. It’s no longer the case that you need to have a growth team that does all of this stuff because these elements are now table stakes; they are just part of building an experience that is easy to discover, easy to enter from lots of different avenues and easy to quickly engage with other people through that service.

Common Misstep for Product Leaders: Your API Is Not A Product

• Look for misaligned audiences. If you get confused about your developer platform and think two separate thoughts, “I’ve got to serve my developers and I need to serve my customers,” then I would argue that you’ve already made a misstep.
• The right frame of mind when you’re building for multiple constituents. You’re seeking to serve your customers and you’re seeking to bring developers along with you who have a vested interest in serving those customers as well. When you make that mental shift, then I think that that leads you to ensure that you’re building capabilities for your developers that allow them to solve the problems that you’re hearing about from your customers.
• Be careful prioritizing dev users. With both Twitter and Slack, we fell for a common misstep for early platforms, which is to think that the API is a product. Companies who think this way expose their API and think, “All this good is going to come and the developers are happy because they have access to APIs.”
  • But developers might be really unhappy down the road when they realize that some of the things they have spent their time and energy and money doing are not actually in line with your vision for where your platform is going.
  • At Twitter, when we built the “tweet” button, we were opinionated about what that consumer experience was going to be. We considered what publishers were really asking for in a tweet button — namely, traffic. We built the feature, we built a customer experience that was relatable, that solved a real customer problem in an opinionated way. And it worked. Publishers saw their organic audience build through the use of that feature. It gave them a ton of value.
  • If we had just published an API and said, “Hey, you could do these 14 things if you want, and here’s a spec for how you would do that,” it never would have happened consistently. And whatever they built wouldn’t have gotten the usage they got with our tweet button.
• Set a clear vision for the product experience. So in hindsight, it was clear we were moving into an era where we were demonstrating our vision for the platform and setting goals for the experience we wanted to deliver. Having that reflected in our platform features started to really give the platform some shape and purpose that it lacked when it was just an API.

“You Have To Earn The Right To Be A Platform”

• The definition of a true platform.

• Meaningful products are low on the Maslow stack. I often draw a Maslow’s Hierarchy of Needs for platforms. To have a really meaningful platform opportunity you need to be doing something well that’s pretty low, fundamental on the Maslow stack. For example, communication and exchange of knowledge is the most fundamental activity for knowledge workers, period.
  • That’s why I was drawn to Slack in 2015, to first lead platform before I stepped up to run all of Product. Because of the opportunity in solving that fundamental need.
  • Also, we were not just enabling back and forth communication, but also aggregating that knowledge set and building search on top of it and creating more value for the customer out of it.

On-platform vs. Off-platform? Your Business Model Can Guide You

• Slack’s business model drove this decision. We never needed to take (a fully on-platform) approach. The reason was, and I admit it’s a champagne problem, people were already spending all of their time in Slack. So, unlike ad-based platforms, we weren’t trying to coerce them to spend more time in Slack.
  • Our business model was such that we didn’t make more money if you spent eight hours in Slack versus seven hours in Slack. So we built this platform that allowed urgent and real-time information to come into Slack and for users to provide basic responses in a very short amount of time. Like sharing a Google Drive file without having to go back to Google Drive to set permissions.
  • But the minute a user needed to do something more sophisticated — like if you’re going to go design a wireframe — we thought they should go to the best place for that, which was their design tool.
• Key insight — the handoffs were part of the communication we enabled. We wanted to help route you there and enable those handoffs because those handoffs between people are ultimately communication and are best-suited to take place where people could already be found: in Slack.

Enterprise Products Should Be Even Better Than Consumer Products

• Why the bar for B2B needs to be higher. When we were building Slack it just made sense that, of course, the app should be intuitive and just as easy to use as the consumer messaging experiences you have. In fact, it should probably be even better than consumer apps, because you are more likely to talk to your colleagues in a digital fashion more than you talk to anybody else in your life.
  • So the product should just sing. It should be effortless. At Slack, we wanted to build the very, very best experience that we possibly could. We thought: This is too important to get wrong. It is rude not to get this right.
• A huge opportunity for Founders. Now that everything is going digital and more remote and everyone is working at home, the consumerization of enterprise is only just getting started.

How To Work With Product-CEOs — When The Product Is Their “Baby”

• Critical Tactic — bring everyone together on the journey. When I became VP of Product at Slack, I pulled together the CTO, the VP of Engineering, the Head of Design, to start functioning as a team so that we could ensure we were consistent in our vision and the role definition between our teams.
• Mind your rhythms. It really unlocked this rhythm where we could get things done together. We could build our teams, we could hold them accountable. We could review products and establish a roadmapping process and just get the engine going.
• Avoid product leadership in a vacuum. I could have gone and done all this in a vacuum as the product leader but instead, by working as a team, we all felt ownership of it. And we could also back each other up because you can’t have every leader in the room all the time.
• Bring the Founder into the room where it happens — for a long time. We also brought Stewart [Butterfield] along for that process. For at least four quarters we had Stewart in the room for all of those processes. That was an opportunity for the team to hear feedback directly from him and was an opportunity for him to observe the team’s progress, as well as just get a read on how the organization was shaping up and give feedback to me and to my engineering and design peers as well.
• Not doing this = failure mode. This calibration period was hundreds of hours but I think it was absolutely critical. A lot of product leaders come in and they want to get the CEO / Founder out of the room as quickly as possible. I think that’s a failure mode.

Signs For When To Hire Your First PM

• Are you an enabler… or a blocker? Founders of early startups ask me a lot: When should I hire my first PM? If you are consistently the blocker for your engineering and design team and preventing them from making progress, then you need to hire a PM.
• An obvious yet rarely-practiced technique. Especially as a Founder, ask your team! if you poll your team and you regularly find that people are waiting for answers from you, then you really have no choice.
• Don’t wait too long. Founders tend to wait too long before realizing this. So they may lose some amount of productivity for their team because the Founder must get to a point where they’re just not able to respond quickly.
• Your job is to keep firing yourself from various aspects. To be clear, there’s a lot of value in a Founder being very close to the product and close to the team for as long as possible. But in any growth-stage company — whether you’re in the zero to one phase or later — you always have to be thinking about how you’re firing yourself from various aspects of your job.

My 3-Part Slack Framework For Hiring For Great Product Managers

• There is no “PM” gold mine. First, nobody is born a product manager. It is a skill learned on the job. Ultimately everybody comes to product from somewhere else. Maybe they started as an engineer and moved into it, or maybe they were on the business side and showed enough understanding of the customer that they made the leap over into product. Maybe they were the Founder and decided that product was the thing they wanted to keep. So there’s not an obvious place to look for them.
  • To help with this, during my time at Slack as I built out the product team, I developed three axes for hiring PMs.
  • This structure forces me to pick which one of these 3 axes is most important for each hire. And then I use that to guide my sourcing and look for candidates that match that profile. It’s always a bespoke process for me to hire a PM.

Axis 1 — Functional

• What flavor of PM are we talking about here? If you go to one company, maybe every PM has a CS degree, and then at another company, the PM is expected to have an MBA and be more of a business leader. The requirements can be completely different, so you can’t just look at paper and assume all PMs are the same. You need to know their lineage, know what functional background they come from before entering product.
• You can oftentimes find somebody who can actually help round out some holes within the team. For example, if you’re hiring a product leader, but your engineering manager maybe is having some challenges scaling, you might hire a more technical product person because maybe they can help fill that gap.
• Maybe you don’t have anybody running marketing, and so actually you want a product leader who can just take that on and run with the ball for a little bit until you reach a scale where you hire somebody specific for marketing.
• From case to case you’ll be looking for PMs from fairly different companies and cultures.

Axis 2 — Subject matter expertise

• Sometimes it matters a lot. For example, at Slack, when I was hiring a product leader for the enterprise organization, I absolutely was looking for somebody who had built and sold enterprise software. So I hired Ilan Frank, who continues to this day to be the VP Product for the Enterprise Team at Slack. He was a fantastic addition to the team because he showed all of us in the product organization what it looked like to be a product leader for large customers. He showed us how you need to just show up for them and pitch to them and face objections from them, as well as have a deep understanding of the audience and their needs.
• Sometimes subject matter expertise doesn’t matter — especially in more junior roles, where you can just hire generalist PMs that can work on anything and they’re hungry to learn new problems and new audiences.

Axis 3 — Growth stage experience

• There are people who have worked in 20 person companies. There are people that have worked in 2,000 person companies. There’s a very small group of people who have been lucky enough to work at a company that grows along that trajectory from 20 to 2000.
• Finding somebody with growth stage experience is more important than the subject matter filter, or even what flavor of PM they are, because they just know how to lead through change.

What Product Career Advice Would You Give To Your Former Self?

• Having experience outside the lines of traditional product management has for me been incredibly valuable.
• The only way to be a PM is to build and ship product. And, frankly, that’s accessible to anybody.
• Focus on diversity as early as possible. The work that we’ve done as an angel investing group, #Angels is focused on actually putting real measurement around equality or lack thereof in the industry as it relates to equity compensation.
• Ask for sponsorship when you need it. Dick Costolo was CEO at Twitter when I was there. He was open to mentoring when I asked for it, and he took the feedback that there was an opportunity for him to do more, especially for women in the organization. Since that time he has done very much for me and for others from the ex-Twitter network. He inspired me to think about building my muscles as a sponsor and being on the other side of the table.
  • • [Dick similarly praises April]: “April is a forthright communicator, has a terrific sense of humor, but most important, has tremendous empathy for others. In a business context, specifically, this helps her understand that there are many ways to be successful — not just whatever worked for her.  It makes her particularly well-suited to mentor others.  We have this weird business culture in America that mythologizes leaders and makes it seem like there is a recipe book for success, or some definitive way you should do things if you want to succeed. There is not. April’s understanding of this helps guide the people she’s mentoring to be themselves leaders, not copies of her as a leader.”  — Dick Costolo
• Care for the craft. I learned more about product and care for the craft from Stewart Butterfield at Slack in the three and a half years that I worked with him than in the rest of my career combined on those fronts. He’s incredibly thoughtful about every decision you make and how that impacts the people on the other side of the screen using your product.
• Always try to pay that forward.