Coffee with Cara Meverden
This week, I met with Cara Meverden. Cara runs Publisher product at Medium — building the toolset for bloggers (like you & I!) and professional publishers. Previously, Cara ran product at Indiegogo and launched some of our favorite Twitter features, including Twitter photos, during her time there as a Senior PM. #badass
How did you get into product management?
I started out as a software developer — I used to program in high school then spent several years in software development. I’ve always been geared towards product management — I think it comes from being a bit of a control freak!
As a developer, I decided I wanted additional visibility into how decisions were made, and to participate in the decision making itself — I didn’t enjoy having the decisions handed down. This now speaks to my style of product management, which is to try to not hand down decisions. I never want my engineers to feel the way that I felt having decisions handed down to me!
I think the way that most people get into product management is that they find an area that is chaotic and exert order on things. You can do that from any role — as a developer you can take something that is an independent project, start organizing it, communicating with stakeholders about what’s going on, and you essentially become a product manager.
When I was at Google, I was a Technical Account Manager — there were areas of development that didn’t have any oversight, so in an effort to provide value, I “inserted myself” — helping developers to organize their work, connecting them with stakeholders, and giving their work visibility. I did everything I could think of to help them deliver value to the company, and feel good about the work that they were doing. By doing this, I made myself a product manager. I eventually codified that going from 50/50 account management and product management to 100% product management.
Inserting yourself as a product manager is a trick, and how the majority of PM’s I know got into product management. The question is whether you’re at a company that will support that transition. The advice I always give is to show the value that you’re providing and demonstrate how this project (that you were managing) had a positive impact on the company. Make a case that you’re more valuable as a PM than in your current role.
I think the way that most people get into product management is that they find an area that is chaotic and exert order on things.
How have you developed as a PM?
As you mature as a PM, you realize it’s a lot less about knowing the direction and a lot more about making sure everyone is going in the right direction. It’s a lot of helping the team determine which direction to go in.
One of my biggest launches was photos on Twitter — I had an “aha moment” when I was digging through the data with a coworker, Doug Williams. I knew that we, as a company, needed to host photos — that this would be a big win for us, but we needed to convince everyone else. I think that’s actually the job of a PM —championing what you believe to be the right direction.
At this point, I think of myself as a software development coach, where I have this team of developers and designers — at Medium our team is really talented, so we have a lot of really smart developers and designers — and it’s up to me to coach that team to solve the company’s problems as best we can. Rather than telling the team what to do, it’s working with the team on what the end goal is. I would be arrogant to think that I have better ideas on how to get there than they do — sometimes I do, only because I do so much research and I’ve been doing this for years, but they’re all really smart so I spend more of my time trying to synthesize that research and share it with the team so that we can all develop a shared intuition about what direction we should take the product.
If you tell somebody “here’s where we’re going”, there’s a million little micro decisions they need to make when developing software or making designs, and you can either sit there and say “no not that, yes that, no not that” or you can communicate as much as you can about the problems you’re trying to solve so that your team can make those micro decisions on their own. Not only is that more efficient for you and your time but it’s a lot more fulfilling for them. You create a better product and create it more quickly if you don’t dictate exactly where you’re going.
I did everything I could think of to help them deliver value to the company, and feel good about the work that they were doing. By doing this, I made myself a product manager.
How do you approach researching a new feature?
If your process starts with a feature idea (i.e. a feature request from users or your CEO), the first thing you do is take a step back and set the goals — what are we actually trying to accomplish? It’s usually tied to a problem that you’re trying to solve.
Once you have the “problem”, you figure out as much as you can about that problem. I’ll use competitive analysis (what is everyone else doing to solve this problem?), and user interviews (to put myself in the shoes of the user as much as possible). I’ll document all of that research, then bring in the team — starting with a developer and designer to ideate on potential solutions together.
When we have a potential solution, the first thing I’ll do is go to our Partner Strategists at Medium (my team works with external publishers) for a gut check — “do you think this solves the problem?”. Then I’ll go to the partners (the publishers) to get confirmation that it’ll actually solve their problem.
As you mature as a PM, you realize it’s a lot less about knowing the direction and a lot more about making sure everyone is going in the right direction.
When you have the solution, how do you coach that through to release?
If I’m working with a product-minded developer and designer, I’ll typically write up a high-level spec — “here’s what we want to accomplish with this”, which is not a prescription of how we’re going to do it. I hand that over to the developer and designer to work together to write up a tech spec of a back-end solution and come up with designs of how this should work.
Senior designers or developers can totally handle everything on their own and don’t need much oversight. Junior developers are going to need some help breaking down the project into much smaller pieces, so I’ll work with them on breaking it down and prioritization. With junior designers, we’ll define the MVP together — decreasing the scope of the thing that they designed because the thing that they designed is always bigger in scope than what you actually need.
Another critical thing in this process is estimations — working with the engineering team on setting milestones for the MVP. I never set milestones — that’s rule number one as a PM, developers set milestones, and I work with them to make sure that the milestones get defined, and on how we’re doing against those milestones week-to-week. The angle on that isn’t about blame — we need to deliver things and if they’re not being delivered on time there’s a reason for that. Part of my job is to help the team figure out why, and clear the blockers or bring in more resources if we need them. This goes back to providing value — I am here to help.
What books do you recommend to PM’s?
I highly recommend The Power of Habit — this is great for consumer software. And Creativity, Inc. — there are a number of great principles in Creativity, Inc. including the Braintrust and the notion of iterating on a product until it’s great and being okay with changing direction when it’s not.
What do you consider the traits of a great PM?
If you asked me this question several years ago, I would have had a different answer. Now, I think the traits of a great PM are the same as the traits of a great manager.
- Someone who can really empower their team
This involves having the selflessness to allow your team to be right, and allowing them to lead where they can. - Someone who is willing to do whatever it takes for their team to be successful
At the end of the day, we’re there to make the company successful. We do that by solving user problems and we solve those problems using software. So, if you can figure what the problems are and how to solve them, then you’ll be successful.
I’m dedicated to trying to always make the right decision. When you’re a junior PM, you have your CEO being like “do this thing” and then you go to your engineers and you’re like “the CEO says we have to do this thing”, which is obviously the worst thing you could do. The idea of always trying to find the right solution and being open-minded — this goes back to coaching a team — I have an idea but the key is sharing all the information to get the best ideas out of them.
I left coffee with Cara in awe of her experience, and approach to product management. And with many more questions about both! Thanks for grabbing coffee, Cara :)
And thank you for reading. If you enjoyed this post, say hey on Twitter or in the comments below — I’d love to know what you think!
Hungry for more? Find more “Coffee with” interviews here.
