Stage VP’s Startup Growth Series with Karen Ellenberger - Part Two

Please welcome back Karen Ellenberger to Stage VP’s Startup Growth Series. As a reminder, Karen is the VP of Product at Till, at Stage VP portfolio company. This interview is the second installment of a two-part interview with Karen. In the first installment, we focused on developing and iterating product at a startup. In this installment, we’ll learn from Karen how a product leader can effectively organize a product team.

SVP: You mentioned in the first part of this series that you've worked on product decisions and product leadership at everything from your own bootstrapped startup, to a company with a big budget like Mapbox, to a Series A company (Till). How are those roles different and what are the different things that need to be prioritized at each type of company?

KE: I’ll start out by saying that no matter the size of the company or the level of funding, there is a common thread that goes through any company: you need to understand your customers’ problems very deeply. There is a universal truth and understanding of how to ask questions and to understand the core problem of your users. So always start by asking questions and walking into any conversation with a customer with an opinion or a position, but then be willing to give that up immediately as you start learning things from your customer.

And then I think the thing that differentiates being a product leader at different sized companies is understanding how much to take on and how much support you have. When you're working in a bootstrapped startup, your job is to do everything — you are a one person show. You need to be able to traverse efficiently between the highest level of thinking about the strategy and then you need to be able to go all the way down to the bottom where you're doing customer support. You are the person behind that ‘help @‘ email address.

As you move up to a bigger and better funded company, it is important to learn how to maintain a vision and direction for a team. Your most important role becomes enabling people to work autonomously, giving them everything that they need to be able to make good decisions independently. Your job becomes unblocking people. It becomes more of a facilitator role where you need to establish and maintain vision across the company, and make sure everyone has the context to then be able to make decisions independently.

SVP: What does unblocking mean to you in the context of what you do as a product leader at Till?

KE: When you've done the work to understand your product vision and the appropriate timeline for goals of the company, your job is to be scanning all the time across the different milestones and projects that are moving and to be able to see when people are slowing down. You want to create a culture where people will be able to raise flags soon if they're having a problem or if they have a question that isn't answered that's preventing them from moving forward. You should strive to build a culture of teamwork and accountability that allows people to raise flags early and not feel like they have to labor in the dark and silence towards an impossible goal. The sooner you can get people to raise problems and work together as a group to solve issues so that everyone can move forward, the better. To me, unblocking people is creating a culture of allowing people to ask questions or raise flags if they're uncertain about the path forward and then working together to work through that problem towards a solution.

SVP: You brought up a point which we can relate to: plenty of our portfolio companies have that one or two product people who are doing it all: building product strategy, answering the help emails, and doing a bunch else. As these companies scale, the product team usually grows. What skills would you recommend that a product leader at an early-stage company learns over the course of 6 to 12 to 18 months as they go from being a one person product team to much larger?

KE: I think there are two ways to look at this. There's a size of the team question and then there's also a maturity of the product question. I think those two things are separate but related. You can be working on a very new product at a big company and you would treat that new product differently than you would treat a product that's more mature, even if it's at a smaller company. Creating a vision for your team is very important because everybody needs to be able to rally around the same goals. The question is going to be, are you looking at a point that's three months or three years or 10 or 15 years down the road?

As a product leader, you want to make sure you know the time horizons you're working on. Sometimes it's a very bad idea to pick product goals that are too far out; everybody wants a long term vision and a long term roadmap, but the reality is that you can set a trap for yourself by picking something that's too far away. By doing so, you restrict your ability to move with agility.

When you're working on a very new product that hasn't matured yet, one of the cautionary tales is to be too entrenched in your expectation of what the product goal should be such that you're not willing or able to see the lessons that you're learning at that very early product stage. Make sure that you're agile and always asking questions. You can make assumptions, but you should always be proving or disproving those assumptions with data. You need to be willing to change your course as you learn new things, and so a shorter term roadmap is appropriate for a newer product, no matter the size of the company.

As you mature, you need to be pushing your roadmap further out into the future. Then you’re talking about a three, five or ten year roadmap and those goals can be very long term. When building up a team, make sure that everyone has a very clear, common, shared understanding of what the goals of the product are and what that roadmap is. Creating a roadmap takes some work. I think there's a perception that someone sits down and in two or three hours has a vision quest conversation with people and they develop a roadmap that's months or years out in advance. That's not true. This takes a ton of work.

Leading through influences is one of the most critical skills for a product manager to develop. As a product manager, most often your work is very high impact and it's broad reaching, but you often don't have direct reports. Rarely do product folks have direct reports. Yet, you have a great deal of influence over the company, the roadmap, what the engineers are working on, etc. So you need to learn how to lead, without necessarily having direct reports that you can tell what to do. You need to make sure your sales team has the right talking points and the right information. You also need to be able to tell engineers what they need to be working on.

A skill set that product managers and product leaders can develop, no matter their role in the company, is learning how to effectively advocate for what you need and to communicate very clearly. Whether educating employees about the product or creating a long term vision, you need to build consensus and then communicate out what the results of that consensus building exercise are.

SVP: Some companies scale quite quickly and only have a person or a couple people working on product. What are your thoughts around when it's time to start building a product team around you?

KE: I think it depends a lot on the type of product that you're building. If you’re working on a more technical product whose consumer or customer is primarily technical, I think you can actually get away with fewer product people. If you have a consumer product, it's harder to scale up engineering teams to a very large size without product folks. If your product has significant visual design elements, having people working on product becomes very important because you need people who are essentially translating user needs and ensuring that you're solving the right problems.

It’s vitally important to make sure that the people who are doing the building are working as efficiently as possible. I’ve seen organizations under-value product people and this can lead to solving the wrong problem. You need someone or multiple people in the organization who are able to think very deeply about what your customers need and often that is a product person's job. 

When I was at Mapbox, I was on a team of 25 engineers with one product person. That's one extreme example in terms of the ratio of product people to engineers. Most consumer facing product teams have one product manager working with a group of somewhere around six engineers and UI/UX designers. At Till, we are doing a lot of early stage product development right now and you need more product people to do that because there's a lot of market research and discovery that needs to happen.

SVP: We are well aware that as a product leader you are constantly pulled in a lot of different directions. What tools and processes do you use internally to keep track of what really seems like just endless amounts of tasks?

KE: There are some frameworks that we use and it doesn't matter which tool you use to develop these. I love a methodology that fundamentally comes from Amazon and AWS: you start with what's called an operational plan. There are two operational plans per year that are created six months apart: one at the beginning of the year and once in the mid-year around June.

The operational plan is a document that outlines your 12 to 18 month product vision. This is a long-looking document and every six months, you revisit it. You update what you've learned in the last six months, what you've achieved, what’s changed about the business, where you're going, and how you're going to get there. The foundation of everything we do is this operational plan. When working on the operational plan, you should do some really deep thinking about where you're going in the next 12 to 18 months and how you're going to get there.

I come into the operational meeting prepared with many, many hours of thought. I work across the organization to understand what's blocking our sales team, what's blocking our customer success team, etc. Based on this research, I come in with a proposal for where we could go and the operational meeting is to talk at a very high level about what the needs are of the company in the long run and making sure that the whole company is aligned.

Based on the operational plan, we do planning work in quarters and we have a combination of tools we use for that. Our leadership team uses Asana for task management to track high level milestones and projects across the organization. We organize it into projects so that anybody in the organization can drop in at any time and see all of the tasks for a project, what's been done, what’s coming next, and who the owner is for each piece of the project.

In terms of product development, our engineers use GitHub. I’m a little bit unusual in the product world in that I am conversant in GitHub and used to working in GitHub. We start with the operational plan that I talked about and create GitHub tickets out of it.

As for meetings, I know a lot of companies do stand-ups daily and for some teams that works really well to meet once a day and talk about what you did yesterday and what you're doing that day and tomorrow. For us, that cadence is a little bit too frequent and ends up being disruptive to people. So we do it just twice a week.

It’s really important to never underestimate the power of writing. Doing things like using Excel and expecting everybody to get full context out of sending around an Excel spreadsheet is a terrible idea. It’s critically important for the product development process to do deep thinking and writing thoughts down to make sure that everyone is on the same page. We use Notion as our place to compile what we’ve written. 

SVP: What determines the metrics you pay attention to at Till and what is the process of discarding and updating metrics as the business changes?

KE: As part of our operational planning process that we do every six months, we put together a KPI pyramid that encompasses the most important metrics that we care about as a business. We sit down as a leadership team to develop and debate the pyramid . For our last operational planning session, we were all vaccinated and did it in person, for the first time since COVID. We sat down in a conference room with a whiteboard and we put together all of the things that we think we care about, and then we ranked those and determined what is the one most important metric that drives everything else for the business.

Through this process, you end up with a waterfall of metrics that define what everybody's going to be working on. This is useful because it is a tiebreaker in conversations about priorities. Once you have your metrics and your roadmap, the very next conversation is what do we do next, and what do we do after that. The KPI pyramid gives a really good framework for discussion, discussing trade offs and prioritization exercises.

We revisit the KPI pyramid every six months; we may not necessarily change it, but we do want to explicitly have a conversation about whether these are still the most important things for us as a business. The rest of our metrics are part of the product work that we do when we're talking about bringing a new feature to market or fixing a problem that exists. 

The very first thing we do is try and measure where we are now, as we want to have a baseline measurement. For example, if we’re looking at a new onboarding workflow for our customers, the first thing we want to see is how many customers are getting through the workflow at present. We want to understand the places where they're struggling and why. This gives us a baseline that we can measure any improvements against. Even if the initial metric is really, really bad, you want to start with an understanding so you have a way of measuring the impact.

If the answer is that you can't really measure something right now and you don't really know how good or bad it is, then your first job is to figure out how to measure it. Then, you’ll want to make changes and figure out how to measure the impact of those modifications. Sometimes, this leads to a conversation along the lines of: ‘Oh, this is actually going to be very, very hard for us to move this metric. Do we care about this enough to do the work required to move this metric?’ Sometimes the answer is ‘No, we don't care about this enough; this is going to be really, really hard and we've got other things that we should be doing that will be easy to do, let’s pick up the low hanging fruit first.’

The conversation about how we measure things is often a great way for us to talk about level of effort and level of impact. How much of the market will this change allow us to capture and how much of an impact on our customers will it allow us to have?

SVP: When you're thinking about building out a product team and looking for those early first hires, what types of backgrounds or passions are you looking for?

KE: I think that the best product people that I know generally have diverse backgrounds and have done many things in their career. In some cases, they do need to have domain expertise. They need to deeply understand a specific area because I'm looking for someone to complement what my expertise is. I need someone who can come in and have extreme ownership over a certain domain of the business. I want to have great confidence that they're going to be able to develop and execute a roadmap.

They may also just need to have a history of being able to take ownership, set a vision, and execute against that vision. Execution is incredibly important; you need to have people that have a demonstrated track record of achieving results and being able to set goals for themselves. When you're interviewing, ask lots of specific questions such as “Tell me about a time when you xyz?” Make them answer the question with specific examples, not just at a high level.

In addition to the ability to execute successfully, curiosity is another trait that I seek. It is incredibly important for product folks to have the ability to ask great questions and they should be humble and have the ability to leave their ego at the door. The reason this is so important is that you need to be able to jettison a bad idea very quickly.

In early product teams, I’m generally in favor of hiring people with more experience. They don’t necessarily need to have a traditional product management background, but depending on the kind of business you're running, they may need to have some specific domain expertise. Especially if you're a Seed stage startup, it can be a mistake hiring junior folks. It’s tempting because they’re less expensive and you're trying to tend to your books and your runway. However, you should be careful when hiring product people, especially early on, because they have outsized impact. Hiring junior product people can lead to moving slowly when you need to move very quickly. You can just completely miss on your product goals which can severely hurt the company.

SVP: Do you prefer hiring product managers and product folks who have deeply technical backgrounds?

KE: I think it depends on the type of product with which the product manager is working. If it's a product manager that's running an API, they need to have some basic technical fluency. They don’t necessarily need to have been an engineer, but they do need to be able to understand the concepts that go into making an API function, for example.

It isn't necessarily that you have to have a deep background, but you need to be able to onboard to that domain very quickly. When interviewing, I will test for your ability to learn new things quickly; can you self serve and ask questions? I believe that there are no stupid questions, and I am always the person who asks the dumb question in the room, because somebody else has that question. Cultivating openness to asking questions and expecting a sincere answer to that question is really important. When interviewing candidates for product manager positions, I look for the ability to ask great questions more than deep technical understanding.

SVP: Karen, is there anything else you’d like to share?

KE: One other thing that I do want to touch on is the relationship between product and engineering teams at a tech company. My advice would be that the product and engineering teams be as integrated as possible. There is a notion sometimes that a product team is a very separate entity from an engineering team, and that can lead to a lot of problems. Making sure that your product team and your engineering team have very close relationships is really, really important; they need to be like one team. Your goal is to lower the barriers between the product and engineering groups as much as possible while being respectful of people's time.

To make this happen, we make sure that our engineers are involved in a lot of the product conversations. We are inviting engineers into our product world so that we don't have high walls. If they would like and if it's valuable for them, engineers are invited to participate in our product strategy conversations, because the product team needs their voice and wants them in the room to help us understand the implications of the strategy we're developing. Our product managers attend our engineering scrum twice a week to absorb what's going on and to develop better context around what the engineering team is handling.

Writing is really important to give people the ability to ingest information on their schedule. For example, a member of the product team can share a document with updates for the engineering team that an engineer can read and drop comments and questions in with their morning coffee or at the end of their day, whichever is convenient for them.

Also, to preserve time, it is really important to come into meetings prepared with an agenda. I know this is basic: you’ve got to come into a meeting with an outcome that you need. You need to do your pre-work to make sure that you're using everyone's time well. Sometimes you’ll find you can just avoid the meeting all together.

Thank you, Karen, for sharing such seasoned wisdom about leading product teams. We believe that your insights will be extremely helpful to product people at startups.