The JH Forster Hypothesis: The First Product Hire at a Startup Needs to Be a Player-Coach

JH Forster is a product leader with deep experience helping teams ship solutions for real user needs. As SVP of Product at User Interviews, he oversees the Product Management and Design departments—and geeks out about all things user research as the co-host of the Awkward Silences podcast.

In this episode of the Product Science Podcast, we cover how he found a job as the first product hire at a startup and what challenges he’s faced as the team and company have grown.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, YouTube and more. Love what you hear? Leave us a review, it means a lot.

Resource Links

• ‍Follow JH Forster on Twitter‍
• Follow JH Forster on LinkedIn‍
• Follow Holly on Twitter‍
• Follow Holly on LinkedIn

Questions we explore in this episode

What was it like being the first product hire at a startup?

• The biggest thing was making sure he made time to hear from the founders about what they thought and where they wanted the product to go.
• He had to span every level, from doing nitty-gritty details like doing design work and writing microcopy to the 30,000-foot view of business metrics and planning.
• Made space in his days for reviewing feedback, assessing product performance, planning for the future, and doing execution work.

What challenges did JH face as the team developed?

• They had team members jump around from one team to another, so context-switching became costly and people wanted more of a sense of ownership than they got.
• Doing the player-coach thing is hard. You’re spreading yourself across 3 buckets: execution, management, and leadership.
• It’s difficult to give people space to experiment when the company is still embryonic - you have started a fire, but it’s not a bonfire yet.
• They struggled to decide when to add additional layers of hierarchy to the team and too easy to try to keep the organization flat.
• They thrashed around on the process too much.
• It's really hard to set a good proxy metric that can be moved in a quarter.

How do they develop products today now that the company is about 130 people big?

• They have a product trio of a Product Manager, a Product Designer, and a Technical Lead and are aiming for about 5 engineers per PM.
• Give the pods a lot of autonomy to manage their own work day-to-day.
• They align around a quarterly outcome and do a quarterly review meeting where they debrief how they did on their outcomes, what went well, and what didn’t go well.
• Every two weeks they do a full-team demo to show what the teams have been working on.
• The teams do retros and stand-ups but get to decide how to approach them.

Quotes from this episode

The in between of the player coach stuff is really messy. And the reason I say that is you're now spreading yourself across three buckets. In the early days when you're doing everything, you're jumping around the leadership strategy stuff and execution. The moment you start to build a team, you throw a management layer in there as well. So now you're still doing some amount of execution work because you probably haven't hired enough yet on the IC front. And you start to get spread really thin.

I mean when I came in it was six people…I think the biggest thing that I found that worked really well was just making sure I made space to hear what ideas the co-founders had that kind of like are already on their radar. It's so small in that type of scale that I think approaching it as a partnership is really helpful.

We're in a nice balance now where with the research team, there are certain projects that we identify that are really strategic and the methodology and facilitations are going to be really important to get right. And so we'll have those be research led. And then we'll have a whole other category of stuff that the pods want to do and it's maybe more usability testing or some quick discovery calls that can just be research supported. So they'll help do some coaching and making sure that the plan is sound, but we still let the ICs go and talk to users directly. So that's been a nice hybrid for us.

A lot of people really beat the drum on outcome oriented product management, and I think for good reason. I think something that kind of gets glossed over is it's really, really hard to set a good proxy metric that a team can move in a quarter that you have enough conviction that actually ladders up to an important business higher level metric.

The Product Science Podcast Season 5 is brought to you by Productboard

Check out their eBook: Dangerous Animals of Product Management 2.0
 
Every organization has challenging stakeholders and situations that can get in the way of our product plans. Learn how to manage them using a mix of soft skills and hard frameworks.

Get Your Copy

Transcription

Holly Hester-Reilly: Hey, Holly here. Before we dive into this week's episode, I wanted to share some information with you about some workshops that we're running. Here at H2R Product Science, we love to teach workshops, both public workshops, private workshops at companies, and even an online workshop for people who can't come to see us in person. If you're interested in learning how to identify the right products and features to build and how to develop the support to do so with the product science method, come and join us. You can learn more at h2rproductscience.com/workshops.Hi, and welcome to the Product Science Podcast where we're helping startup founders and product leaders build high growth products, teams, and companies through real conversations with people who have tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host, Holly Hester-Reilly, founder and CEO of H2R Product Science.I'm excited to share a conversation this week with John Henry Forster. JH, as he's known, has been the SVP of product management at User Interviews and he oversees product management and product design and he's also the co-host of the Awkward Silences podcast. Welcome JH.

JH Forster: Hey, thanks for having me. Glad to catch up.

Holly Hester-Reilly: Yeah, I'm excited to talk with you. I've been a big fan of User Interviews for a long time, so I'm excited to hear more about what it's been like inside the company. So I thought we could just start with that. Tell me a little bit about how you got started at User Interviews.

JH Forster:So I had previously in my career done kind of the big company thing and the startup thing. So I had experience on both sides of the fence and had some experience managing a team and some direct reports, but also coming in as an early product person and doing a little bit of everything, so to speak. And so when I was thinking about what I wanted next my career, I really wanted the chance to be the first product hire somewhere and build up and scale the team from scratch, that was something that seemed really exciting to me. But I also wanted it to be in a problem space that I found interesting and with founders and a team that I was eager to work with. And so, turns out that that's pretty hard to find. And so I did a lot of searching, a lot of networking, talking to folks.The challenge is when you're going early, usually one of the co-founders is doing the product stuff and is not ready to give that up or doesn't make sense to give it up from a budget perspective and it's hard to find early opportunities where you think there's real potential for success and it's an interesting problem area. And so long story short, I got connected to the User Interviews founders through a former boss actually who was a very early adopter and client of User Interviews. I mean, he connected with me with them and I spent some time hanging out and getting to know them and there was just an opportunity for them to bring on product expertise. They didn't have that amongst the founding team and saw the value in bringing it on early. And so it was sort of just a fortunate point in time where I was really interested in that space having done a lot of user research myself and they needed somebody with my background. And so it kind of just worked out.

Holly Hester-Reilly:Oh, that's awesome. I love hearing stories from people who've done that sort of very targeted "I decided I wanted a job that met A, B, and C criteria and then networked my way into it." I'm curious if you could tell us a little more about that. How much time did you spend or how long did it take until you found that perfect role?

JH Forster:Yeah, yeah, it's a good one and it's one definitely that I was in a fortunate spot with a good amount of privilege to be able to pull it off, where before my wife and I had children, we had a pretty low cost of living. I could bomb off her health insurance for a little bit. And so I probably took about two months. I left my last job and I really wanted to be open with everyone that I was looking and this is the type of thing I was looking for because I think when you're trying to find your next job while you're currently employed, you're doing it a little bit secretively and you can't lean on your network as much. And so I decided to step away from my current opportunity so I could tell everyone this is the type of thing I'm looking for is what I'm really eager to do.It was up and down. I got a lot of different intros, some through VCs, which I thought would be a good lead because they'd have all their portfolio companies and they would know maybe who's looking for product hires, which was useful. A lot of just ad hoc introductions through friends of friends and stuff like that, like, "Oh, this team's doing something interesting, you should talk to them." So I don't know that I have a great playbook on it. It was enjoyable. I call it maybe six weeks of full-time trying to find my next thing and being able to do it, but it's also stressful because you're living off savings and you're not sure where it's going to land and how long it's going to take.So if you're in a spot to do it, I think there's advantages to it. But I don't know. It became more of a full-time thing than I thought. I thought I'd have a little bit more downtime where I could do some house projects or have some time off between roles. And it turned out that pretty much every day I was either going to meet somebody for coffee or hopping on an interview or doing something else. So it was a pretty full-time search.

Holly Hester-Reilly:Yeah, that's really interesting. And frankly, it's faster than I would've guessed so that's great that you were able to pull that off.

JH Forster:Yeah, I was lucky on that front. Going into it, I budgeted like, "Okay, if it takes three months, that's okay, we can make that work. We're in a spot where we can manage that financially." If it had started to go longer than that, it could have been doable, but I would've been getting a little bit more stressed out. I did do a couple small consulting engagements for some people I knew and they were at smaller teams and had some product work that needed eyes on it so I'd be able to bring in a little extra income that way. But I didn't do a ton of that, one, because that's not really my specialty doing that sort of business development and selling yourself as a consulting service, but also it kind of then distracts from having the time to do the search. So that helped. But if we had gotten past three months, I probably would've shifted my focus and done a little bit more of that.

Holly Hester-Reilly:Yeah, that makes sense. So tell me what it was like when you got started there. How did it begin? I mean, what is onboarding like for the first product hire at a startup?

JH Forster:Yeah, I think that's a good question. It's interesting, right? I mean there's not really a playbook at that scale. So I think if you're interested in doing this, you got to be somebody who's pretty comfortable with ambiguity and figuring things out, which was appealing for me, but maybe overwhelming or scary for others. Yeah, I mean when I came in it was six people. So there was three co-founders, myself, one other engineer, plus the CTO, and then somebody running operations. So it was a really bare bones team. I was just looking at some data on this. We were doing a couple thousand completed research sessions in a month, whereas now we're doing well over 10X that five years later.So it was a real business. They had some traction, they had some users, it was doing tens of thousands of dollars of revenue in month, so it wasn't like nothing, but it was pretty nascent. And when you come in, there's really no systems. So there really hadn't been any design work. And so I started standing up some of the basic components in Sketch at the time and then we quickly moved to Figma. So I was taking that on. We didn't have any analytics support. So back then if I wanted data and pull stuff out for a brief period, I was actually just querying off the prod database, which is not our best practice.We had mixed panel early on, so we had some of that data which was helpful and easier to access. But I think the biggest thing that I found that worked really well was just making sure I made space to hear what ideas the co-founders had that kind of like are already on their radar. These are the people who took the chance to start the business, took on a ton of risk to do so. They've been hustling and been really close with all of the customers basically to build the business to where it is. And so they're going to have a lot of ideas on what you need to do in the product and where we want to go next. And my general intuition was it's better to just hear those and get all those ideas internalized and then start to supplement them with my own ideas versus trying to come in and be more territorial. It's so small in that type of scale that I think approaching it as a partnership is really helpful.The thing that I think is also good to be aware of is you really have to span every level. So you're doing all the execution stuff. So I'm doing the QA before we ship new features, writing the copy, you're doing all the nitty-gritty, but then you're also doing the higher level strategy of like, "Okay, the next two quarters might look like this and we might invest in standing up the ability to do B2B targeting in our case, so you could recruit off professions and stuff like that."And so you're really going from the 30,000 foot view of business level metrics and planning to the most granular details of getting something out the door, which again, I think is fun, but it's a lot of context switching. So I think onboarding is tough and what I tried to do a couple times is figure out how we divvied up my time to try to make space for all those things so I didn't get lost. I didn't totally work, but I would try to be Mondays I over-index here, Tuesdays over index here. That never totally clicked, but I was really mindful about not just fixating on a single part of the job and trying to make sure that I was keeping all of the balls in the air in the early days.

Holly Hester-Reilly:Do you recall what some of the things were that you were focusing on on different days of the week or attempting to focus on?

JH Forster:Yes. It just didn't work as well as plan so I'm hesitant [inaudible 00:07:36], but I knew I needed to make space to go through all the customer feedback we were getting. So having to do some of that, I wanted to make space to look back on all the recent stuff we had shipped or iterated on to see what the impact was getting traction if it was a driving impact. So some of that look back space planning and kind of forecasting with the co-founders of what we wanted to do next and having that rolling roadmap that we were adjusting month to month basically at that point. And then the rest of it was really just execution work, because again I was doing the design and the product requirement stuff for a decent stretch. So I'm not a designer by trade, but I had done a lot of UX coursework and experimentation and I got really comfortable in the tools. And so given the staffing and what we could afford at that point, it worked but was very excited when I could bring on a full-time designer.

Holly Hester-Reilly:Yeah, absolutely. A lot of startups in my experience, like early stage startups, have a product manager before they have a designer or before they have a full-time designer. And so it's interesting to see how different companies deal with that.

JH Forster:Yeah, And so to foreshadow a little bit, so the team now, I have a team of 12. So I have six product managers, six product designers. Really like five ICs and then a director or manager of each of those teams. The company overall is about 130 people. So it's changed a bit over those five years. Now it kind of works at scale. A lot of the things you read about for product best practices or how to organize teams and operate in squads and all this kind of stuff is much more directly applicable to the stage we're at. And so it's easier to lean on some of those frameworks. The in between of going from the solo IC leader person to having a team was a very interesting journey.

Holly Hester-Reilly:Yeah, I definitely want to unpack that more. But first I guess I'm curious, some of our listeners won't know what User Interviews is. So seeing as how we're sort of diving in here, obviously the title tells you something, but what problem were you guys really solving and what was the vision back when you joined?

JH Forster:Yeah, so the vision has always really been the same of trying to help teams discover and embrace user insights is kind of how we talk about it internally. But basically the belief that nobody's doing the volume of research they want to be doing. Usually the reason for that is there's some barrier that's getting in their way. Like, it's taking them too long to do research that they don't have access to the users they need to talk to. There's some point of friction that prevents them from doing something they otherwise would do. And so the earliest implementation of the product and where we found traction in the market was really around recruiting for a certain target user. So prospective users who maybe don't use your service but meet all of these qualifying criteria and doing that really quickly so you can fit it into your product development cadences.And so that was really the core of the business when I joined, was we had this network of participants, we had some pretty good targeting capabilities and we could then source new people kind of on demand pretty quickly. What that's evolved to is being a little bit more holistic where we'll help you with any participant you need now. So we have sort of a research CRM where you can manage your own users called Research Hub. The big belief of ours is we are methodology agnostic and so we will help you support running research with those participants in any sort of methodology or tool that you want to use. So if you want to do moderator or unmoderated, that's fine. We integrate with a bunch of different testing tools. If you want to bring people in person versus doing online, we support that as well. So that's kind of been our unique take on it whereas a lot of the tools are a little bit more all in one. We'll help you with some sourcing but you have to use our testing tool or things like that.

Holly Hester-Reilly:Now I think that what you stated there as the problem when you joined the problem that was being focused on, there's a pretty broad range of people out in the business world who have that problem. Did you have any more specific targeting around whether you were focused on startup clients or enterprises or something in between?

JH Forster:Yeah, that's something that we've refined a lot over the years. I think back then what we found was we could do a pretty good job through organic acquisition, so our content marketing has always been really strong from the start, around finding people who had that acute need of, "I need help finding people like this right now." And when you find people like that, there's a pretty strong motivation to get up and running on the product. And so their motivation kind of will take them through some of the friction or gaps in the experience because they need access to these users. And so in the early days we weren't really getting into a ton of segmenting or ICP stuff yet. It was a little bit more of, "Let's just make sure that we're out where people are searching or looking for how to find and do recruitment and we'll bring those people in."And then what we started to see naturally to some degree was, okay, we would acquire somebody from Spotify or something, we'd help them find some users. We would see that then they invite a teammate and then there's a second user and then they do something and then you start to see this organic diffusion. And that was where we started to realize that the larger companies had a little bit more of an interesting fit for us because we could get our foot in the door with one user and then do things to kind of help that organic diffusion. And then you have a larger pool of users who are using more often and there's expansion potential and all that kind of stuff. So we've learned a lot there. But in the early days it was a little bit more about just who needs help finding users and then we'll kind of figure it out from there.

Holly Hester-Reilly:Yeah. I actually really love that because I think that a lot of times people get too focused on the firmographics or the specifics of the businesses that they're targeting. And at the end of the day, it's really in some areas like this just finding people who have that acute need is the most important thing. And maybe that acute need isn't so different between the enterprise user and the startup user.

JH Forster:Yeah, yeah. A very specific example of this on the very early days how hustley and targeted it was like, for a brief period we actually had an intern on the team who would just go through Craigslist and major markets and find people who were trying to do their own hustle recruiting of like, "We need participants," whatever. And we would reply to those ads and be like, "We can do this for you. Here's the rates. We can get you these people by the end of the week." And a lot of people would just be like, "Sure do it for me." And so that's not a scalable channel, but when you're trying to just get traction and build the business, some of those types of tactics early on worked really well.

Holly Hester-Reilly:Yeah, that's awesome. So what did the journey look like from there? How did you get to the first product hire beyond yourself?

JH Forster:Yeah, so I mean as the team started to grow, especially on the engineering side, we always had an idea in mind I think around the ratios we wanted of how many engineers you have and then what sort of product and design support you need for them. And so as we started to grow the engineering team, it started to become evident that, okay, the product team needs to grow with it.We were in a fortunate spot where we had somebody on our operations team, so sort of doing a lot of customer support and managing of the internal systems. As you can probably imagine, so the recruit product I was describing, it's like a marketplace where you have participants, you have researchers, you're trying to match supply and demand. In the early days of marketplaces, you do a lot of manual steps in between to make it work. And that was what our operations team did. And so we had somebody on that team who had expressed a ton of interest in product management work and was really fluent in our product and what our users needed. And so that carries a lot of weight with me.I'm somebody of the mind, "Product skills are real and there's a lot to learn on being a good product manager in particular." But you also, when you come into a new business, you need to gather a ton of context on the application, the users, to best apply those skills. And so having the opportunity of somebody who's really strong in those areas and is really curious and eager to learn on the product side was something that... We actually just had her as an internal transfer. So she came on as the first product PM in addition to me. And then at that same time we also hired product designer. So we went from just me to having a dedicated PM, a dedicated designer, and I think at that point probably around six engineers. And so that was the journey. I forget the exact timing, but those two were in pretty close successions. Yeah, and then all of a sudden I had a team.

Holly Hester-Reilly:Yeah. And at that stage, were there any improvements you made to what it was like to onboard your new team member? Or was it still pretty ad hoc, one-on-one apprentice?

JH Forster:More of the latter. The thing I'm always leery of is optimizing before you need to while I probably then wait longer than I should. I think in the early days this is still a little bit messy, some of the things you're going to read. I did point her to a lot of resources that are helpful to learn about product management and books and different webinars and things like that. But it's like some of these things are not going to apply directly to us yet because we're still a little bit smaller than what's being portrayed here. And so it was a lot of like, "Let's just spend a ton of time together and make sure we're aligned and talk about the way we do things." This was still back in the days where we hadn't figured out how to make easily testable review apps so that a non-technical person could jump in and testing.So we'd either promote it up to a staging environment which had some limitations, you could test it there. Or you even had to have the app running locally and then you could pull the branch and run it on your own machine. And so we were doing some hands-on stuff back then. I wouldn't recommend that, but that was where we were. And so yeah, I was really just spending a lot of time together with the new designer, with the PM and just making sure we were aligned. I think the thing that in retrospect which I had done differently was when you're in a really small team, when it was just me and three or four engineers, everyone knows everything, everyone's worked across the code base. No one specialized but you have this broad breath.And so you can do... What I heard somebody described me once, it's kind of like what you feel is "perfect prioritization." You can just move from problem to problem even if they're not related. So the first thing we're going to solve is this pricing issue for researchers. The second thing we're going to solve is this scheduling thing for participants, and there's no coherence and you're going to jump around. And it's a small group and so alignment is really easy. I have to convince myself about this new problem space, get a couple engineers on board, we do it.And as this team started to grow, now we have six, seven engineers, a PM, a designer, as we started to make squads and groups, we kept yo-yoing people around like that. We were like, "Oh we're still small. We can put these people on this problem area for a quarter and then move them over here to something totally different the next quarter." And what you started to see as we did that a couple times was that context switching actually gets really costly as the team grows and people want more of a sense of ownership and specialization in certain parts of the experience.And so I think a big lesson learned from me is the moment you go from one team to two, I think it's probably a really good idea to figure out who wants more consistency and coherence in their work. Because this differs by person across engineering, design product. Put those people on a team that's like a core area where you know you're always going to need surface coverage and you can imagine two years of investments and let them start to own that and localize it and then take the remainder of the group and be like, "You're going to be kind of the flex group for a little bit" because you are going to have a wide range of business problems you're solving with a really small team. And so you still need some of that nimbleness. But I think we tried to do it where we tried to juggle everyone. And I think if I could do it over, having some people localize in a really key opportunity area and another group that kind of hops around.And then as you add more people, now you have a second group of people localized in a swim lane or an area. I didn't realize the value of that consistency until it had bitten us a few times.

Holly Hester-Reilly:Yeah, it's really valuable to hear you say that because I've worked with much bigger companies that don't realize that value.

JH Forster:Yeah. Yeah.

Holly Hester-Reilly:So it's like, "Oh you could even see it at that size." People want that sense of ownership. I mean, not everybody does. Some people love jumping around. But the people that want it can be really valuable to give them that, "Here's your directive. This is the thing that you have to move forward and go and run with it."

JH Forster:Yeah. Yeah. I was talking to some other peers, but a more mature company. So I found a couple people that were in director or higher level roles at startups that were like let's say a size or two bigger than us and had been there for a while and I was able to catch up with them for a little bit and being like, "What were mistakes you all made at this area?" or whatever. One thing that really stuck in my head that somebody said was, "You know you haven't organized your teams right if the teams are starting to just give themselves random names, like the Awesome Team or the Dragon Squad or whatever." Our two teams at that time were, one was called Gem, they'd named themselves as the Gem Squad or something. And then one was called Gi Jo, which was a port man two of names or something, and clicked so obviously because he was like, "If they're in areas of a coherent ownership that are important to the business, they'll just call themselves like the Matching Squad."

Holly Hester-Reilly:Right.

JH Forster:And that was such a tell that we hadn't done the organization right because people wanted an identity. The work that they were working on was all over the map so they couldn't do it that way and they just came up with something fun or silly. And so I think if you do see that in your team, it's probably a decent tell that you might need to come up with a clear charter and objective like, "This is what you all work on and own. Here's some of the long-term outcomes that you're going to affect and here's some of the quarterly goals." So that's just an easy thing I think to look out for that. Once it was pointed out to me, I was like, "We need to reorganize some of this."

Holly Hester-Reilly:Yeah, that's really interesting. So then you got your first product manager under you at this company and the teams started to grow. What did the next phase of the journey look like?

JH Forster:There was a good stretch in there where doing the player coach thing is pretty hard. I haven't seen a ton written or discussed on this, but there's sort of the three phases. There is the do-it-all phase, like you're the only person, figure it out, wear a million hats, which is fun if you're wired that way. And then you get to some scale and it's clearly the leadership phase, like I'm the head of the product function, I oversee director and a senior manager. They oversee their teams. I'm setting a much higher level of strategic vision for the company and holding people accountable to that and really not in the day-to-day at all.The in between of the player coach stuff is really messy. And the reason I say that is you're now spreading yourself across three buckets. In the early days when you're doing everything, you're jumping around the leadership strategy stuff and execution. The moment you start to build a team, you throw a management layer in there as well. So now you're still doing some amount of execution work because you probably haven't hired enough yet on the IC front. Now you have to manage people, so you're responsible for their careers and feedback, keeping them engaged and all of the important stuff that comes with that. And you're still doing this leadership longer term, like, "Here's where we're trying to go" and you start to get spread really thin, especially as you add the second PM and the third PM. The management layer just really starts to become much more of your time.The thing that's the really stressful crunch on this all is you're at a scale and size where the business is still sort of embryonic. It hasn't fully... You have product market fit, you're growing but it hasn't fully taken hold yet, if that makes sense. The way I would describe it is you've started the fire but it's not a bonfire yet that's going to be pretty hard to put out.

Holly Hester-Reilly:Right.

JH Forster:If this thing falls over and the wind picks up, the fire's gone. And so why I say that is there's still a lot of pressure to make sure that everything you're doing is really impactful in driving the business forward and you're getting it done quickly. That makes management really hard because you want to empower people and give them autonomy and give them space to do work. And with that comes some risk of failure. Not to say that I wouldn't fail or make mistakes on myself, but it's hard to get that right in those early days where it's like once you're bigger, giving people more space to try their things and maybe the experiment crushes it, maybe it fails a little bit, but that's okay.But in those early days, it was just really hard. I really struggled with getting the right balance of giving the people a my team space to own things and do their work and be fulfilled but also put my thumb on the scale and be like, "We need to get this done a little faster or we need to be a little more decisive here because we need to hit our target this quarter because we only have so much cash in the bank and so much runway" and that kind of stuff. And it's a stressful phase. I think the player coach phase was definitely the hardest for me and that probably was two year stretch until we got to a stage of really having managers within the teams and that kind of stuff.

Holly Hester-Reilly:Yeah. So that was a two year stretch. I'm curious if you can give us any more sort of markers. How big was the company when you finally got out of that stretch?

JH Forster:That's a good question. We were probably in the 50-ish people range as a company. I think the way it happened for me was somewhat lucky where somebody I'd worked with previously who was a really experienced product manager, almost closer to a peer for me, was interested in coming over and joining the team. And so to make space for her to be interested in joining the team and get on it, it sort of forced the conversation of, "Well, I think we were at a scale now where we should just have somebody running the product managers." That was coming, but it got pulled forward a little bit because there was this great person that we had the chance to add to the team. And so once that happened, it became so obvious that this was valuable and the right time for it. It was one of those things where I think if I left my own devices I probably would've delayed another three or six months. And then we pulled it forward a little bit because of this opportunity.And then once you see it in real life it was like, "Oh this is so much easier." She's taken those three direct reports, she's still doing a little IC work. I'm freed up to really think much more strategically in the line with the other functions of the business and do a little bit more of the longer term planning. And so I feel like that's true in a lot of things in life. You are not sure and then you go on the other side of it and you look back and you're like, "Oh of course we should have done that." I think the hesitation I had was adding another layer of hierarchy to the team. When you're small-ish, when you're like 50-ish people, it starts to feel kind of heavy. Now there's like the CEO, there's me, there's a manager, and then there's an IC.And in the earliest days, it's me, a manager, an IC. The tree is very narrow, it's like one or two. It just feels off. It's like, "We should have a flatter team. We're small. We don't need these levels." But by getting it in place what happens is, "Well then when you need to hire the next time. This manager's the one who's going to run the hiring process and do all the interviewing and that takes a ton off my plate." Or when you come into reviews and that person has three direct reports and the design leader has three direct reports. Previously I had six direct reports I was writing reviews for, which is that kind of on the upper limit of what you can do well.So you see the benefits really quickly, but I was maybe stubbornly in the camp for a while of, "I can make this work with a flat organization for longer." And then the moment we got out of that, I was like, "Oh this was the right time to do this."

Holly Hester-Reilly:Well, it sounds great. I think your statement about how often that happens that you realize after that you did need to do the thing you did is a great position to be in rather than, "Whoops, we should have done this a lot sooner."

JH Forster:Yeah, it's kind of like a slowly than all at once thing with a lot of this stuff where something that's working for you in the earlier days, whether that be a process or a staffing or a team design thing works and works and works and then all of a sudden it doesn't work. And then once you realize it's not working, you suddenly feel very underwater on it. It's hard to know when that's coming, and I think that's some of the biggest lessons learned from having some of that pattern recognition and things like that.I think the way to do it, I've given this advice to some other people who joined early companies, is if you can get your first product person, whether it be a PM or a designer on the team who's going to do IC work but who's interested in becoming a manager and has either done that before or you think has the aptitude or experience to grow into that, then what you can do is you can almost just put people under them as the team grows further. And it's like the timing of how you get that right is a little bit of a question mark in the team shape and stuff like that. But you set yourself up into a very nice path versus you hire three or four IC people and then you later have to come in and hire a manager over them, which can be a little bit more awkward sometimes. They joined early probably because they wanted proximity to leadership and now they're getting kind of layered.It's doable and it's totally workable but it's a little bit more awkward in terms of that transition. So if you can get an early employee on your team who's interested in management and you think has the potential or skills to do it, you can have a lot of flexibility in how you grow the team that way.

Holly Hester-Reilly:Yeah. And I think the same advice goes in the other direction for people looking for that management experience or that chance to grow a team, that joining a startup can be a really great place to get a chance to grow into that.

JH Forster:Yeah. Yeah, I think it's one of those things where in a perfect world, you would've had a chance to do it before so you're not learning it fully. Because I think the challenge of learning how to manage in a startup is you're not getting this level of support you would like in a big company. When I first became a manager, I was working at a public company and they had this whole thing that was an 18 month program called Manager Development Program. It was every two weeks and you were in these cohorts and you were reading books and doing discussion groups on it and doing assignments with your direct reports to go through learning styles. There was all these prompts about how to write good reviews and give good feedback and how to do coaching well. That was just hugely beneficial to me and there's just no way... I didn't provide that level of assistance to the people on my team who were in management roles just because we don't have that scaffolding. We don't have a L&D team that can do all that stuff.So it's a great place to get the opportunity but you'll have to make a little space on your own to go out and do some of the learning and find some of the resources that you'll likely need. And so it's kind of a toss up because it's harder to get those opportunities at large companies sometimes, but when you do you're going to be really well supported and then easier to get them in a startup. But you're going to have to feel okay learning some of that stuff on your own.

Holly Hester-Reilly:Yeah, I think in my experience there is a sort of an in-between where when I was in companies that were scaling from a hundred to a thousand employees, they had a much lighter amount of learning and management system than what you described at your public company, but more than you get at a startup where I was getting training on management skills and things coming in, but it was not a cohort of people that were meeting every two weeks. So there's some in between out there as well.

JH Forster:Yeah, totally. I think it's one of those things where, just to go on a little bit of a tangent, it's hard to know how to get it right. There's a lot of advantages to starting your career in a bigger company if you can get into the right role. You'll see a lot of good best practices hopefully and have support resources for these other things. But if you are interested in moving to a startup at some point, you can't stay on the big company track forever because if you go middle management, not a big company, you're salary expectations are probably going to be a little inflated to what you can make in smaller teams. At some point the skill gap becomes actually kind of weird where you're really good in that large environment but the startup's not going to be sure if you can actually come in and operate at their scale and do the things that you need to do. So how and when you make those transitions between larger and smaller companies is a whole other conversation, but very interesting.

Holly Hester-Reilly:Yeah, absolutely. Maybe we'll see if we have time to talk more about that. So it sounds like you had a lot of really interesting growth experiences. What were some of the things that maybe didn't go so well? Were there some things where it was like, "Man, I made a mistake here"?

JH Forster:Yes, there's a lot of mistakes. I think a couple things. One, we probably thrashed around on process too much at times. One of the things I was really excited about and remain excited about coming in early and getting to lead the function was being able to put my own spin a little bit on how we do the work. I've said this to a lot of people on the team as I pitched them and try to get them on the team is that I think there's a lot of the frameworks and practices out there that are right in ways, but when you get really dogmatic about them, it sort of start to fall apart. So agile I think will be a classic example people will point to where the original principles and some of the core ideals of Scrum and stuff like that early on are I think really good, very enduring. When you get to the capital A, Agile, that's cottage industry of consultants and telling you exactly how to do things and how to write your stories and stuff, I think you lose some of the soul of it a little bit.And so we definitely played around with process a little too much because I would get excited about maybe we should do some more fixed time variable scope stuff of just saying, "We're going to spend a month on this and we get what we get" or, "You know what? Let's do a little bit more rolling kanban style and do this." I think with that it just needed a stronger opinion on how we wanted the team to work. And so I wish we could have stabilized on where we are now earlier. So where we did land is we give the pods a lot of autonomy to determine how they manage their work day to day, but we make everyone align around the quarterly goal, quarterly outcome that's kind of negotiated between myself and the pod leads. So we set that. "This is what you said we're going to move in terms of an outcome for the quarter."Every two weeks we do a full team demo type meeting where we show off what all the groups have delivered or what they're working on. And we find that that is both good just for accountability to show rhythm and show progress, but also it lets all the other teams see different parts of the app and different parts of the code base that they wouldn't maybe other see, [inaudible 00:28:20] see in their day-to-day work. So the fluency of how things work goes up across the team, which is really good. And we ask them to do standups and retros, but they can determine the cadence and how they pull that stuff off.So what we've seen is what I was hoping to get to, it just took us a while to get there, is the pods in how they like to do standups, async, on quick calls, the amount of rigor of how they like to break down the work. Some teams are really making stuff into really small tickets and pointing everything. Other teams are leaving them a little bit bigger with checklist and just coordinating really tightly on it. That's something that I never wanted to be overly opinionated or optimizing for, but instead show progress of what you're delivering in small batches every two weeks, work towards this goal.And then at the end of the quarter we have a quarterly review meeting where we go back and basically have them put together a debrief on the quarter. Here's what's really well. Here's some lessons we learned. Here's how we did against the outcome we set." And we found that those are really helpful in terms of building trust across the rest of the company, of seeing the amount of thought and effort that went into all these different initiatives, but also just that moment of reflection of, "Oh, we were way off on what we thought we could get done this quarter and here's why we can factor that into future work." So the process thrashing has definitely been a lesson learned.I think the other one that comes to mind is as we tried to move towards more centric work for the pods of, "Hey, let's make progress on this type of goal this quarter," it turns out it's really hard to set good outcomes.

Holly Hester-Reilly:Yes.

JH Forster:A lot of people really beat the drum on outcome oriented product management, and I think for good reason. I think something that kind of gets glossed over is it's really, really hard to set a good proxy metric that a team can move in a quarter that you have enough conviction that actually ladders up to an important business higher level metric. I've made a lot of mistakes on setting bad goals and having to learn a lot of lessons there. So we actually now in a Notion doc, we have things we've learned about setting goals. It's a checklist of heuristics of, "Don't try to actually give a team three goals and pretend it's one goal" and all this kind of basic stuff, but you fall into all these different traps as you do it. And so that's something that I think honestly to be very candid, I don't think we're still great at. I think we've gotten a lot better at. But that was something that, again, I thought would be easier just the way that people talk about outcome stuff, and as you actually try to apply it, it's very hard.

Holly Hester-Reilly:Yeah, that's something I've seen as well, how difficult that can be. I think that you're right, there's a lot of drum beating about outcomes and I think it is with good reason, but we need more skill as an industry at how we actually set those outcomes. I feel like it's one of the things that I was trying to teach my MBA students a bit about this and saw their presentations last night about what they picked as in context with a whole bunch of other work that they did, but they picked a KPI a North Star metric. It was really interesting to see which ones were even anywhere near something reasonable and which ones were like, "Nope."

JH Forster:Yeah, yeah. I think the biggest trap or I think the one that bites me the most is when you give a team a metric or an outcome that's actually quite broad, so there's a number of different opportunities you could pursue to achieve it, if you harbor strong opinions around which of those opportunities is most important, handing the metric off of that level without also conveying your biases or beliefs just sets you up for a bad interaction, where, "Here's a broad metric, like an activation type metric or something, there's three big categories of ways we could go after it. I feel really strongly that we should just do number one for these reasons." I don't tell the team that they go off and do some brainstorming and they come back and they're really excited about option number three, and now you're setting yourself up for this really demoralizing interaction where you're like, "I don't want you to do three" unless maybe they made a good enough case and you're like, "Sure, let's do it."But if you have that kind of opinion and conviction in a strategy or direction, then just set the outcome of level lower so that it's an outcome that's clearly around path one and just explain that and own it. Don't do the thing where you're pretending to give them this wide swath of autonomy, but actually holding really strong opinions about which path they should choose, because that never works.

Holly Hester-Reilly:Yeah, absolutely. So I think you mentioned the company now is at 150-ish or so?

JH Forster:Yeah, I think 130.

Holly Hester-Reilly:130, yeah. So what is the breakdown at this point of engineers? How many engineers per product manager and designer? What are the teams look like?

JH Forster:Yeah, well we have some open roles on engineering, so if anyone listening to this is excited about anything I've said, please come check us out. We want to be in a spot where we're around four or five engineers per PM and designer. We're a little bit below that as we've been hiring and staffing up the team. We are fortunate to be a little faster on the PM and design hiring over the last few months, and the engineering hiring is ramping but not quite there. So that's what we're aiming for. Right now it's probably closer to three engineers per PM, per designer across the team.This is something that I actually don't have a strong opinion on. What I mean by that is, is it better to bring on product resources early so that they can get familiar with the business, the users, the strategy, and then have a chance to develop the roadmap and opinions of where they're going in their area and then you bring the engineers on later to have the resources to do it? Or is it better to onboard a bunch of engineers, kind of have these larger pods or squads than you would ideally have, let everyone get comfortable, and then when you bring on a product person, there's immediately stuff for them to take over and run with? We've done it both ways over the years. I've seen both works. I don't really have a strong opinion on how you sequence it, but we're in a phase where we're scaling up on the engineering side. But yeah, that's the intended ratio.I think we might play around with stretching that a little further. Not too far, but I do think product is relatively high leverage work, so you might be able to get away with six engineers or more to a PM and designer. One thing that we are also starting to poke on a little bit is we do very much do the Trio or the extended Trio model popularized by [inaudible 00:33:20] and others of PM, a PD, a technical lead. We usually have an analyst and then a researcher on some sort of shared basis as well. So there's some other people in that kind of leadership level there.I think there's maybe a world where we would entertain a higher design ratio. So if you had a group of 10 engineers, it's two designers and maybe one PM. The PM could really be focusing on some of the strategy prioritization stuff and the designers would really have space to do more of the usability and solution creation. So I think we'll probably keep the one to one-to-one ratio across technical lead, design, and PM. But that's something I want to explore. So people actually listening to this have experience with different ratios, I'd love to hear perspectives on that.

Holly Hester-Reilly:Yeah, that's interesting. I mean, there have been times where I was a player coach within a mid-size startup that I had two teams under me and I was the PM on one team and I had a PM on the other team. When I lost that PM and I had to do both teams myself and so it was that structure of 10 engineers to one PM and two designers, I was definitely felt pretty underwater.

JH Forster:Yeah, yeah. That's the concern for sure.

Holly Hester-Reilly:I remember feeling like I had a choice between either can I focus on getting the engineers and the team what they need or can I focus on the communication to the larger company, and I can't get them both done really well.

JH Forster:Yeah, I think that's certainly the challenge.

Holly Hester-Reilly:Yeah. Yeah. So one other thing I'm curious about is I always love to ask companies that make products for product people. Does User Interviews use User Interviews?

JH Forster:We do. We do. Pretty often I would say. One of the things that's maybe been interesting for our team is we now have a research leader and a research team and it's been a huge asset for us. But we went a fair amount of time without that, which I think sometimes people from the outside looking in find a little strange of like, "Aren't you a user research company? You value research. Why didn't you have a researcher on the team earlier?" Which is fair critique. But our general thought was, we have a product that makes it easy for anyone to do research and we want a team of people who are really empathetic to what our researchers experience. And so we want people doing research.There's a little bit of a slippery slope there with, "You're not your user and stuff," but I think there's something we found powerful when you have an engineer go through the project creation process for a real project that they're going to go talk to people on. Some of those rough edges or things that we need to improve hit a little differently than when you're breezing through a staging environment and just creating a fake project as fast as possible to test something.And so we went along period between the PMs, the designers, and even the engineers of just having the team run the research. I think there was benefits of empathy and familiarity with our users, but we definitely did some of that research in a much shaddier way than we would've with true research professionals involved. And so a bit of a cost there, but we're in a nice balance now where with the research team, there are certain projects that we identify that are really strategic and the methodology and facilitations are going to be really important to get right. And so we'll have those be research led. And then we'll have a whole other category of stuff that the pods want to do and it's maybe more usability testing or some quick discovery calls that can just be research supported. So they'll help do some coaching and making sure that the plan is sound, but we still let the ICs go and talk to users directly. So that's been a nice hybrid for us.

Holly Hester-Reilly:Yeah, that makes a lot of sense. It is kind of funny. You might think that you'd have had a research head sooner, but I get the argument about having everybody get exposed and use the product.

JH Forster:Yeah, it's one of those things. I mean, we would've loved to, but in the early days you're trying to be really tight with your budget and so it's hard sometimes to make some of those decisions.

Holly Hester-Reilly:Yeah. One thing I want to actually circle back to, you mentioned that you found peers who were a stage or two ahead of you in terms of their company's growth. How did you find them?

JH Forster:It's a good question. I honestly sat down for an afternoon and was trying to think of companies that were not direct competitors but would have product challenges that were analogous to what we do. And so one thing that came to mind really quickly was applicant tracking software. So they have candidates, they have hiring managers, they put them through these flows with the different statuses to move them forward. And then we have researchers, we have participants, we're trying to get them connected. There's a scheduling component. It actually felt, there's like, "Okay, there's a lot of parallels here." And so then I went out and looking at companies like that. So Greenhouse was one that was really interesting. And so I was just sleuthing on LinkedIn and I was like, "Okay, this company is 200 people. So they're a fair amount bigger than us and raised more money, but if I can find somebody in the product function who's been there for a long time, maybe they've seen some earlier stretches."And so basically I found somebody who was a director there who'd been there for six years and I was like, "I want to talk to this person" and had some adjacent connections and was able to find some sort of warm intro through that. And that's when somebody who's been a really helpful person to connect with. I actually still connect with him monthly. And basically tried to do that, repeat that formula a couple other times. So that worked. And then honestly there's a group in Boston called Boston Product that used to be much more of an in-person thing and connected through there. And so through there, I also know a few other folks who've been just less than a head camp, but more in the same boat of we're joining an early place and have been able to connect and build some relationships there as well. So a bit of luck, a bit of intentional searching, that kind of thing.

Holly Hester-Reilly:Yeah, that's super valuable. I think I've heard that from other people as well, how helpful it can be to get people from outside your company who are going through similar things that you can talk to.

JH Forster:Yeah, really I think part of the reason the Greenhouse one has worked so well and why we stay in touch is having similar problems that you're going to wrestle with is really helpful. If I had found somebody that's like super successful B2C mobile app, I think there'd be helpful things that they learned through the scaling challenges that I could learn from, but I don't think it'd be as directly applicable of, "Oh, we also have to juggle two user groups and investments across them and have all these complexities in our flow." Some of those things have been so analogous that the conversations can just get much richer. So definitely prioritize something that feels analogous to the problem space that you're working on, but is non-competitive so that you can be open with one another.

Holly Hester-Reilly:Yeah. Awesome. Well, this has been really, really interesting. I really have enjoyed our conversation. How can people find you if they want to follow you or learn more?

JH Forster:Twitter's probably the best bet, so I'm @jhforster on there. I usually will just link out to other stuff. I had a newsletter that I was keeping up very briefly. I'll try to resume it. Kids and life got in the way, but I do want to pick that back up. I enjoyed writing about this stuff, and then LinkedIn as well.

Holly Hester-Reilly:Cool. And how old are your kids?

JH Forster:We have a three-year-old and a one-year old.

Holly Hester-Reilly:Oh, you're in the thick of the young.

JH Forster:An interesting stretch being parents. Yeah, yeah.

Holly Hester-Reilly:Yes. Yeah, absolutely. Well, congratulations on that.

JH Forster:Yeah, the startup thing and little kids is a lot, but it's been fun.

Holly Hester-Reilly:Yes, I hear that for sure. Well, thank you so much for your time today. It was a pleasure to talk with you, JH.

JH Forster:Yeah. Thanks for having me.

Holly Hester-Reilly:Hey, Holly here. I hope you enjoyed listening to this week's episode as much as I enjoyed making it. I wanted to share with you that at H2R Product Science, we run lots of workshops and we'd love to have you join us. We teach the product Science Method, a step-by-step process for evaluating product opportunities and laying the foundations for high growth product development. We help product leaders and startup founders identify the right products and features to build and develop the support to do so. We do this at private workshops. We also do it at public workshops, both in person and online. If you'd like to learn more, check it out at h2rproductcience.com/workshops.The Product Science Podcast is brought to you by H2R Product Science. We teach startup founders and product leaders how to use the product science method to discover the strongest product opportunities and lay the foundations for high growth products, teams, and businesses. Learn more at h2rproductscience.com. Enjoying this episode? Don't forget to subscribe so you don't miss next week's episode. I also encourage you to visit us at productsciencepodcast.com to sign up for more information and resources from me and our guests. If you'd like the show, a rating and a review would be greatly appreciated. Thank you.

‍