---

Who were your first 3 hires?

Our first three hires were Alan Ibrahim, who started out as an office manager and now runs our customer success team, Arthur Chiang, who is an engineer (he decided to move and go to Instagram), and Jeffrey Wang, who’s our Chief Architect and built Amplitude as we know it today

How you begin to define what skills Senior Product Manager is expected to have?

The biggest thing that separates a “senior” hire for me is the ability to work independently with little direction from a manager.

In general, when I hire product people what I look for is a deep understanding of the customer’s problem. If I were to choose a product person on one thing and one thing only it’s that.

How do you perform user research when you only have a few customers to test your solution against? Also, is there any good learning material/course online you recommend to get started with user behavior analytics?

If you have less than 100 users, don’t spend time with analytics! Go talk to all of them in person, that’s a small enough of a sample that you can interact with them directly and learn about their problem.

What’s the biggest opportunity that your company is unable to capture at this stage? How do you plan to overcoming the challenges?

There’s a new “biggest challenge” every month. It doesn’t stop and doesn’t get easier. I had to learn sales, learn how to recruit and hire, learn how to manage, learn how to create a winning culture, learn how to hire execs (which is even harder- you’re trying to convince people who are way better than you to work for you!), learn how to inspire people.

Each of these has been a multi year learning process for me.

How did it feel to enter a market with already quite some big/aggressive players (Mixpanel/GA). Why did you decide to enter it & how did you adapt to it?

We understood the limitations of other products in the market and were convinced that we could build something 10x better than what was out there based on our understanding of the problem from first principles.

We knew we could build something that scaled 10x better, and something that could answer questions that were 10x more valuable (figuring out what behaviors drive retention).

Would you call that domain knowledge?

Yes, absolutely! it might sound crazy, but our head of product, Justin Bauer, knows the customer and the customer’s story way better than I do – that’s because he WAS the customer for a number of years.

How did you find your co-founders?

My cofounder Curtis was a really good friend of mine from college. We went to MIT together and were close for 3 years there. It took me a year to convince him to join but it was worth it.

Looking back in retrospect, working with a lot of the other people I knew at the time would have been a mistake as they wouldn’t have been a good match as a cofounder. Curtis is a 99th percentile CTO.

What is the biggest pain point that your current customers face today while using Amplitude? How do you plan to solve them?

The biggest pain point our customers have today is setup and managing an instrumentation. We have a wonderful customer success team that spends a lot of time walking through instrumentation with customers but it’s still incredibly painful.

We’re going to be releasing a bunch of things around here later this year to improve the experience. Instrumentation has been the bane of successful analytics for the last 20 years.

How has your roadmap planning process changed as your company has grown?

We always joke that B2B is easy. Ask people what they want and will pay for, promise it, scramble to make it, sell it, and then repeat.

Analytics is also a little easier from a roadmap perspective. There are hundreds of reports that are out there that people want. We’ve spent most of the last 3 years making sure we’re covering all our bases people expect out of product analytics.

This year is the first year where we’re spending more time playing offense and pushing on more innovative things (instrumentation, different querying interfaces, custom querying, smart reports).

To do that, we started by identifying the biggest problems around product analytics success and we’re now thinking about the solutions to them.

How can I get more support from my tech team? I’ve tried the ask-and-you-shall-receive measure without much success, maybe I suck at asking or it could just be that my teammates hate me.

This sort of problem (bad communication between product/eng) could have any number of reasons: it could be you need to be more proactive, it could be there’s a lack of trust between the two groups, it could be engineering and product both misunderstand their roles.

It’s hard for me to say without more information or examples- this is where good management in engineering and product comes in and can really help out. FWIW we’ve dealt with this problem in different groups as we grow.

A good foundational book on team-building is 5 dysfunctions of a team which I highly recommend (I use it to run teams at Amplitude):

https://www.amazon.fr/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756

What are the main problems facing Amplitude and your field right now? (rephrased: what keeps you up at night?)

Execution. I feel good about the strategy and where we’re going. Now the hard part is executing it well.

We’re in scaling mode (50-> 100-> 200 employees and even faster revenue growth) and there’s a big temptation to slip on the execution bar, with hiring, with releasing features, with closing deals, and it’s super important to have the discipline to not do that.

Tactically, I’ve built out an exec team I feel good about, We’re in the middle of hiring the next layer of functional leaders (we’re looking for a sales leader, demand gen leader, product marketing leader, and a few others).

What advice would you like to give us and couple of things that a new PM should absolutely understand before deciding to jump onto the PM bandwagon?

I’d say the biggest thing about making a career in PM is do it for the right reasons. A lot of people see “manager” in the title and think it’s a more prestigious role because you’ll be “managing”. It’s not.

We celebrate engineers and salespeople way more at Amplitude than product people. If you’re ambitious, I recommend doing either engineering or sales because the upside there is unlimited.

Whereas product is more difficult for career advancement as it’s more of an artisanal role with a less clearly defined path to success. You should do product management because you love really understanding what makes a customer tick and the problems that they face and you want to be an expert in life around that.

If given an opportunity to change one thing from a year before the way you handling/operating Amplitude, what would that be?

It wasn’t the worst mistake you can make, but I was too late in hiring leaders who could help me scale Amplitude. I think we could have grown faster if we had gotten engineering/sales/finance leadership earlier.

That said, I’d rather have been slow on hiring than over hired.

Can you speak to how you your product and design team work together? What does the process look like and where do you draw, if you do, boundaries?

The key is to be super clear about what their roles are. Product owns the “story”, which means who is the customer and what is their problem.

Design owns the “system”, which is what the constraints are.

We strongly believe in engineering as owner at Amplitude and product and design should never be writing specs or doing handoffs or doing project management – the engineers should do that.

Product and design are there to create and communicate the story and the system.

A followup to your response. It’s clear that you define these boundaries relatively rigidly.  How does this work in the wild? When Product has defined the user and the problem, is this work passed off to design to develop a solution space? Where do testing and ideation come in?

I am not the best person to answer this but I’ll give it a shot (most of Amplitude runs without me these days).

The point is that product should be spending most of their time talking with the customer, gathering data, and then communicating their understanding of the problem with the rest of the organization.

That it’s not passed off is exactly the point – this should be a continuous process!

We’ve moved away from waterfall within engineering a long time ago and product should think the same way. They’re always updating and communicating their understanding of the problem.

I was at the Amplitude conference a few weeks ago. I think your focus on retention was great. But most of the literature was directed towards single rewarding experience/core loop. Let’s say after acquisition and engagement there are multiple paths of retention. Which caters to each user and what is good retention strategy?

That is an excellent question! We think a lot about the different ways users retain: for example, retaining new users is very different from retaining existing users on your product and you should think about having features that impact each one.

We go into depth more in our playbook! http://productanalyticsplaybook.com/.

What were pivotal moments for you that encouraged you to start you own company against overwhelming odds?

I spent a year studying and reading about startups before I decided to start one. One of the biggest things I took away was that if you stuck it out for at least 2 years, your chances of having some success were pretty high.

In contrast, I’d see a lot of founding teams who quit after 6 or 9 months. After seeing 50+ data points, that gave me the conviction that if I dedicated 2 years no matter what the chance of success was actually decently high.

That’s also what got us through our first failed company, Sonalight, on which we spent one year with no good outcome. But we weren’t deterred from starting again because we knew we had to stick it out for 2 years minimum!

How do you prioritise between what you do yourself and what you delegate at different stages of growth?

With the stage that we’re at (> 10MM in ARR, 50 people) the CEO should delegate as much as possible.

The two things the CEO cannot delegate is 1) hiring and running the leadership team and 2) setting the overall company strategy and direction.

You’ll still need to pinch hit a lot all over, but the idea is you don’t want to be a bottleneck for the rest of the org.

For example: I often don’t know about when features or updates ship out, I don’t read the blog before it goes out, I’m not involved in deals closing.

Now of course I often will drill down into any of these areas to understand what’s going on in the business, but you want to remove yourself as a bottleneck as much as possible.

This shift really started when we were 25 people, before that I had to be hands on with a lot more.

Right now, I’m working on: setting Q2 strategy (eg what product are we going to build, what goals are we going to set), hiring functional leaders, explicitly setting our culture (eg we should ship fast), and speaking externally.

What consistencies do you see across your customer base with regard to key metrics and what are good tracking/reporting opportunities outside of this core data set that people are missing?

Retention retention retention! That’s what the best product teams focus on improving.

What’s the most common thing users wish Amplitude could do, that it (probably) won’t do for years?

Really good question! it’s hard to say- I’d say the biggest thing we won’t do for sure is anything outside of product analytics- so no A/B testing, no push notifications, no ad network tracking.

Anything within product analytics is fair game though and we’re trying to tackle what we see as the biggest problems.

I really like how you describe product’s function as communicating user needs and design/eng as doing more specific specs/project management. I’m curious if you’ve picked up that philosophy from any leaders/books/articles etc. I’d like to advocate for it more and understand how that looks in action.

This one is hard for me to give a way to replicate- it mainly came from seeing us screw it up at Amplitude! I was frustrated that engineers kept having to go to product and design for little questions that they should have decided on their own.

I think the big change was explicitly saying “engineering is the owner is is responsible for driving towards a solution” and then figuring out what context around the problem product and design should give engineering to enable them to make more decisions on their own.