Ep. #4, When Should You Hire A PM?

Craig Kerstiens: A couple weeks ago we dug into getting your first PM job, on what skills you need. This week, we're going to look a little bit at the other side of the equation: when do you need a PM? How do you go about hiring one? What's that process, the other side of the table, look like?

Rimas Silkaitis: When do you really need a PM? This is going to be maybe a biased answer here, but since we're PMs on the show, I'm going to say: almost immediately. Would you agree with that?

Craig: Little bit, not so much. I've been a first PM at a couple places now, and I think that's a very interesting, tough kind of time, going from founders. So this really depends on the size of company you're looking at.

Rimas: Okay, so let's be clear here. We're talking about startups here, or very small companies.

Craig: Yep. We'll get to the other side of it, of when you're a large enterprise, how the PM looks, that kind of thing. But I think a lot of our listeners are startups. A number of Heavybit companies, or familiar with Heavybit, early-stage companies.

At that point, you've got the founders doing a lot of this early-stage, truly, product work. So we're on the same pages there.

Rimas: Okay, good. I'm glad we got that covered.

Craig: Now, we've got to scale up. We add some engineers. At what point do you hire the PM?

Rimas: I personally would say: when it's time for the founders to start doing more business-type work and they need to offload the rest of that to somebody else. Because, physically, they're getting to the point where they can't do everything anymore.

Craig: I think that makes a lot of sense. I think I've seen some counter examples. I've actually seen an interesting company that's scaled to about 200 people.

Rimas: Without a PM?

Craig: Without a PM.

Rimas: Holy (bleep).

Craig: I think they're the exception. But it's very interesting to say, now what kind of engineers do you put in place? So I guess that's more the exception. Rule of thumb, what size of company would you say that you should be thinking about hiring your first PM?

Rimas: In terms of number of employees?

Craig: Yep, and assuming this is mostly engineering.

Rimas: Yes, let's assume. You know, tax-software type companies. I'm probably thinking number five, six, seven, eight, somewhere in there. Definitely before number 10.

Craig: I think we're going to end up disagreeing, still, for now.

Rimas: Oh, man!

Craig: Because that was our, a little bit here. I would say a little bit more like 15, 20. Usually you've got the split of founders, one that can run a lot of the business. One that can do a lot of the product. At Heroku we actually saw this. We saw the founders still wearing a lot of that PM hat a long time, until about 20, 25 employees.

This probably bleeds into the question of do you hire a full-time PM, or do you hire someone that's partially PM, partially something else? In which case, you can do it a little earlier.

Rimas: Yeah, I'd agree with that. So, we'll meet halfway.

Craig: Alright, alright. About that point when, you know, founders are busy with a bunch of other things, busy with customers, busy with the business things, they may still be involved in the product, but maybe 15, 20 people, you start to bring in an actual, true PM.

Rimas: Of course. And you know, from my perspective, I think it's important that, when you bring that person in, they're really dedicated to talking to those customers.

When we talk about the founders getting stretched a little bit too thin, that's the opportunity where the PM can really shine and say, okay, what's going on in the marketplace, what the customers are saying, and really collating all that information so that that can get looped back into, you know, what the engineering team should, quote unquote, should be building.

Craig: Completely, and I think that founder's status has a certain power in selling and talking to the customer that no one in the company will have. So you need to utilize that where it's most valuable.

So, at about that 15 to 20-person size company, when you start to hire the PM, I want to talk a little bit on, where do you find that person? I think that person is very, very different from a 50-person company, a 100-person company.

That first PM is a very kind of foundational role, and comes in with a lot of barriers overall.

Rimas: I think, if I were to go look for a PM at that size of an organization, I'm looking to my network. Who do I know that has had good experience with somebody as a PM that has maybe had prior experience? Because you need to put a lot trust in that individual. Because they're coming on so early, that the business may be ambiguous, the product might be in a place where some features or things might be ambiguous.

Being able to pull all that out and undo that ball of wax, understanding where the direction should be going, I think that's very important. And going to your network, and back-channeling, whatever you've got to do, getting those recommendations, is probably going to be more critical than going to a job board or something else like that.

Craig: Yeah, I would agree completely there. I think within your network is huge. Because at that early stage, that trust is so important, that you do a lot based on trust. You don't always have the bandwidth to do as much deep dive and analysis as you'd like to.

Sure, they should be doing that, but you don't always have the bandwidth there. And not coming with the backing of the founder. A founder has a certain extra level of credibility, no matter what. Maybe in part because they can get rid of you if they want to, which a PM can almost never do.

But there is that authority. They've poured blood and sweat and tears, years of their life probably, into it already by this point at 20 people, that you need to have some level of trust.

From a network, a positive experience from either a founder or another employee or coming very, very highly recommended from someone you've trusted is usually really key at that early stage.

Rimas: Just touching on the trust part a little bit more, if you're that founder and you've got a PM, that you recognize that you need a PM, having that trust will allow you to offload some of the, like you said, you've got this baby, and it's tough letting go of certain things.

But you need to as your organization scales, because your role kind of changes over time. And especially at that lower employee number, if the trust is not there, you're going to find yourself diving back in and saying, "Ugh, I've got to do this stuff," and that's not where you want to be.

Craig: I think even, regardless, you'll find yourself diving back in. But that's a separate talk, for a separate episode on how founders do this kind of work with PMs and other kind of parties. But as much as you can give them that trust and then be as hands-off as you possibly can, if the rest of the org doesn't see that trust coming from you as the founder, when you first make that call...

Rimas: Oh, then it's over. Then no one else is going to trust that individual.

Craig: Exactly.

Rimas: Let's say your network isn't as robust as it should be. You, through friends of friends or acquaintances of acquaintances, you don't have a strong PM candidate. What do you do?

Craig: I think you hit on something there. You find someone as a PM that has done it before, maybe worked at a small-stage that you know, done good work. My favorite thing to do is, throw out one of those pieces that has been a PM before, I think you look at counter-areas.

Now, this is a hard one because, as a founder, you probably weren't a PM before. You may not have that practice, no one else in the org may. So they've got to start to learn it really quickly. But I think if you find a good engineer, you find a good sales engineer, some of these roles transition really well into product management.

Rimas: Maybe. I've seen it kind of go both ways. I've seen it go really well, where the individual transitioning from one of those roles, let's say engineering, recognizes that their role has changed. And they take it with gusto and start talking to customers and defining scope and doing all that kind of stuff.

I've seen it go the other way, where the engineering individual will take on the PM role, but it ends up becoming into more of an architect role where they're defining implementation. And that's actually gone horribly wrong.

Craig: In thinking on it a little bit more, I do think that when they've made the shift to a new company, and they have to prove their credibility, they can't shift to that architect role. They have to rebuild their credibility, and they have to do that by building.

So when you're looking at that, maybe, sales engineer that's looking to come over to be product, or engineer that's done some customer-facing things, it's better if it's a shift, that first one at least. Now, it may change on the second, third, fourth PM. But in that first PM hire, if it's a shift from another company, usually they still have to actually do work to get that credibility, which makes it go a little bit smoother.

Rimas: So if I'm looking from outside and I see somebody that's a sales engineer and they're coming in and this is their first PM role, would I have the expectation that that individual grows into a much broader PM role, meaning that they start hiring PMs themselves?

Craig: I think, very possibly. It depends on how successful they are. That takes a lot of question of how do they grow into that role, how do they move up? It's a big open question there and really depends on the person.

Rimas: I really want to talk about the skills that you're looking for in PMs, whether it's within your network or you're just going to have to go out via maybe a job board or accelerator or something else like that, where they can give you references. What kind of skills do you look for in a PM?

Craig: I actually tweeted this a couple days ago.

SQL is one of those skills that, whether it's PM or not, I can't underestimate it.

The ability to dig in, do data analytics on your own, is absolutely huge. If they can't do their own analysis, if they rely on a data analyst team whether this is a 20-person company or a 2,000, the ability to actually get your own insight, for me, is almost a deal-breaker if you can't do that.

Rimas: But I've seen so many good PMs that may not have that technical prowess when it comes to SQL, but have the logic to kind of back it all up, come on.

Craig: I think there's an exception there. Yes, you can understand reason about it. In most cases I've found they still aren't afraid to dig in, and I think maybe that's the difference, the afraidness, the, "It's not my job to dig in and deal with the data."

Rimas: I hate those words. "It's not my job." I should almost never hear that.

Craig: But I think it's a common thing you'll hear of, you know, whether someone likes a PM or not, if PM says, "This isn't my job, you go do this." Like, you're not going to win any friends inside the org, whether you're 20 people or 2,000.

Rimas: Oh, man, I fear for the person that says that. So, listeners out there, please don't ever say, "This is never my job."

Craig: But I think on that SQL side still, the PMs that you have found that are proficient, that can do their own analysis, there's immediately that higher level of respect already there that they can do the work. They can figure out what needs to be done and then make the right calls.

Rimas: I will say both of us on this program are data people, and again, I don't want to recognize there's a bias here. But...

Craig: Even some of us are better than others.

Rimas: Oh, easy, tiger. I will say that you can get pretty far, even with just simple counting of rows, and those other things with SQL that, even with understanding distributions and things like that, you're going to get pretty far. You'll be much further than, let's say, 60-70% of other PMs out there. So, I'm not saying the bar isn't that low. But I kind of am.

Craig: Yeah, and not necessarily just SQL. I think SQL is the lingua franca of how we do data analysis. But it could be Splunk, it could be writing some scripts to pull it up. SQL is the one I would encourage, but if you are familiar with one, whether it's like Splunk or some other kind of deviation of SQL, the ability to do some form of analysis puts you ahead of most.

Rimas: Okay, so this sounds like we're implying that this PM needs to be data-driven. Is that always the case?

Craig: Not all are. I mean, there are absolute visionaries. You look at a Steve Jobs. Was there any data to say probably remove buttons from the original iPod?

Rimas: Probably not.

Craig: It was probably against all sort of data.

I think there's a balance there of vision and being data-driven.

I actually really like Facebook's term of being data informed. You look at Facebook Beacon when they first launched it, and all the data said it was an absolute failure. Now, if you look today, Facebook Beacon has basically been rolled out identically, again.

They redid it a little, rolled it out, not so much negative press. I think they actually did that two, three, four times. I'd have to look back. But there was still a broader vision that they were going for. So I think having some vision there matters. But yes, absolutely, being data-driven is, hopefully, an obvious requirement.

Rimas: Does that matter on the stage of where your company's at? I mean, we talk about smaller companies needing a lot of vision there to be able to sell your product sometimes to other customers and things like that, to get them onboard, that you're going to get to this place. Is that more important, to have that at a smaller stage?

Craig: I think it depends on your level. At a bigger company it's a question of whether you are more of that visionary PM, at a larger company, which you do as you move up in the ranks. If it's at a smaller company, you've got to be both of those.

If you're at a 20-person company, you've got to be able to say, "Here are the 10 features we're going to pull together." And the engineers absolutely may care about the broader vision, but they may just want to go work on their feature.

What you need to be able to do is tie these things together for a bigger launch, for a bigger coordination, to actually do all of the marketing. There's a whole lot more that goes into that earlier stage. Some of it is vision, and there's still a whole lot of being data-driven.

Rimas: I'm getting a little worried here. Because if someone needs to have the vision plus, you know, be data-driven to some extent, are these individuals unicorns? I mean, I know you and I are, but, you know.

Craig: I think you can sway one way or the other more so. And knowing where you're weak, knowing where you're strong, is helpful. I personally would not have seen a case where pure intuition, at least at an early-stage company, wins, long-term.

I've seen those people get hired and get a lot of excitement, but over the long haul of, refining the product, iterating on it, those things aren't as exciting to them. And the product tends to rot over time. But, what are your thoughts?

Rimas: I would agree with that. I think the intuition, the vision-type PM, is somebody that, depending on where you're at in your organization and the products that you're working on, I think makes a lot of sense.

If you're talking about a greenfield project, like for sure, I want somebody that has that intuition and vision, I would like somebody with that data-driven bend to them to help out when it comes to assessing what's going on in the marketplace. But that's not a deal-breaker.

Like you said, if this is something where the product's been out there, it's been vetted, and you're starting to get some traction, I'm less inclined to have the visionary. Unless you're going for some bigger play where you're building a, to use big-company parlance, a program or something else along those lines.

Craig: I think there's a couple things in there. I think that that visionaries are getting their data in different ways. You hit on that a little bit. At the big, 2,000-person company, you're looking at things like a Gartner Magic Quadrant, you're reading user reports. You're thinking on a three to five-year timeframe, and you're making big, big, big investments.

So, you're taking your data in, and it's a little more qualitative than quantitative, but it still exists. At the smaller company the visionary does tend to drop down a little bit, and your vision is "What's six months from now?" and how do all these features tie together.

Rimas: For sure. One of the topics that I'd really like to talk about is like doers versus delegators. I don't want to imply that visionaries aren't doers, but you know, sometimes that line can blur a little bit. And I think the two are a little bit orthogonal. Is that distinction even important when you're looking for a PM?

Craig: It definitely is. At a small company, I've seen way too many times where they've brought in a person that's been a VP of Product, a Director of Product, five times over, and is used to having 10 people under them. And I think it applies outside of product too. It applies to marketing. It applies to sales.

Rimas: Oh, even engineering. I mean, possibly?

Craig: Right. A VP of Engineering probably hasn't written code in a few years. And if you need them to actually shift some stuff, unless they have 20 people under them, it's hard to do. So, it definitely applies on the size of the company.

I would tend to encourage, especially on the product side, to steer more towards inexperience and that ability to "do" and enthusiasm, than a, and again, delegator probably is the wrong word.

If you loosely couple that delegator/visionary that needs the resources under them, you're going to be a little disappointed.

I think that's oftentimes where some sour taste comes, when you talk at a startup-tech-focused company and say, "Marketing gets a bad rap, product gets a bad wrap. Sales gets a bad rap, because you've brought in high-level people that don't communicate on the lower level and actually get (bleep) done."

Rimas: Yeah, I don't want to imply that one or the other is bad. I think it really depends on your situation. Sometimes the delegator, even in a small company, can still do fairly well. I mean, it really depends on how many of those delegators you have across your organization and where you really need that individual.

Let's be honest, even at the 20-person companies and below, a lot of the roles are somewhat fluid in terms of what people need to do. I mean, I still remember having to jump in and do sales, basically. I think we've talked about that in past episodes.

Craig: Yeah, and I'm with you a little bit there, too. Delegators is probably the wrong term. Think of it as a coordinator, someone that maybe isn't doing the legwork but is coordinating a lot of the pieces. We'll have to come back, maybe, on a good term for it.

Rimas: We could probably spend a whole episode just talking about naming things.

Craig: I think that was cued up for a future one.

Rimas: Okay, so we've got a set of skills. We talked about being data-driven, we talked about SQL, doers versus the unpopular term of delegator. We've touched on big versus small company a little bit.

When do you decide to kind of say, "Okay, I'm going to pull the trigger on this individual?" Or let me even rephrase that. What kind of things do you do during the interview process to say, "Okay, I have vetted this person and I think they're a good hire"?

Craig: This probably devolves right into your interview process, which I'm actually really curious if there's another Heavybit podcast that we can refer to about interview processes for startups. If not, maybe we could do a cross-collaboration there with a few others.

For me, one thing is: get them doing it. Get them doing real work. That's huge, to actually test it. It was described to me that Heroku created startup projects way back when, which used to be a one to two-week trial.

You would be a consultant. We would pay you. It's like you're working for us. It was described to me as dating before you get married.

It's a commitment on both sides; you're really trying this out, you're invested, and at the end of it you know if you're going to take the next step.

For me, it's something like a starter project where you're coming in, and maybe you don't have two weeks. Actually, I think a lot of startups do. You can find people that are consultants, that have this time, that are sitting around. If they don't, work with them. But startups can pretty easily say, "Yeah, we can bring you on as a contractor for one to two weeks. Let's try this. We have this project, get to work."

Rimas: I will point out that maybe you don't even need one to two weeks. Maybe you can do this in two to three days. The point is that I think you need some extended period of time, more than just one day, where somebody comes in and sits down and talks, interviews, actually about the mechanics of doing the work.

I will point out that from my perspective, I really think that if you do go down the starter-project route, you really need to have that individual do something that you're not sure of whether they can fill that gap and the gap that you need in your organization.

Because if you do not do that, then what'll happen is you could misfire, hire the wrong person, and then you're going to pay for it for, you know, who knows? And if you have trouble firing, then that individual could be there for months to years.

Craig: And I think, on that firing piece, that's one thing if you're making a lot of investment up front in the hiring process, then you should be slow to fire. If you're not making that investment up front, then you should be very quick to fire them and say, "We hired you too quickly. This was our bad, we're sorry."

Be long-invested on both sides, or be quick on both sides.

Rimas: I'm sure we could spend a whole other episode just on firing. Personally, I think it's demoralizing to the company when you're quickly hiring somebody and then firing them, so caution. Spend as much time up front as possible when you're hiring.

Craig: Agreed, on the same page there. I think you do have to think, if they're not working out, then you have a responsibility to everyone else in the company to get rid of them quickly. But yes, I think it is far preferred to spend the time up front, spend the investment.

If you are doing a two to three-day starter project, don't assume that you don't have to do more work up front. I actually think with the one to two-week ones, it's a little less work, maybe. You spend more time over the aggregate of it, but it's less up-front work. So, if you're doing that compressed, two or three day, and it's an actual project, you do have to do a lot of work up front to make sure it's productive.

Rimas: Somebody's come in, they've done a starter project with you. What signals are you looking for to actually pull the trigger on a candidate?

Craig: There's a whole lot, and I actually want to get into that. But I want to come back a little bit first. What are they doing during that starter project? What are some of the best ones that you've coordinated and run and done?

Rimas: On the engineering side of things, they're actually writing code, doing some kind of project there. On the PM side of things, it is actually things like, "Can you go through a planning process?"

If I do not think you can do that kind of thing, is it, "Can you dive into customer feedback and tell me what the real issue is here, and then present it to the team as what we should take on?" Things like doing presentations, mock sales calls, things like that.

Craig: Yeah, I think that's spot on, and I was a little sad there because I thought you were about to say, "It depends." The prototypical project manager answer.

Rimas: Well, we should rename the show to "It Depends."

Craig: Absolutely agreed there. And I think a previous episode with Raj, we highlighted a great one, actually. I mean, in sales. We basically did a swap that was essentially a starter project where he interviewed, like, 10 customers about this potential feature we were looking at building, figured out what we needed to do, and then made a proposal at the end.

We talked to the engineers about what was feasible. It was almost a perfect one, end to end, that was talking to customers, talking to engineers, figuring out the value, and then making a proposal. And the rest of it is pretty easy to manage, relative to making those up-front decisions.

Rimas: One thing I think we might have left out in all this is what kind of commitment does the whole team need to have, relative to the starter project?

Craig: This is something I kind of wanted to hit on, in that two to three days is really important for me, to pay attention to when they have coffee, when they have beers, how they are interacting. The team is super critical in all of this and should be involved, you know, time-wise, too.

I think there's the official capacity, but then there's the casual capacity. Because as a PM, chances are if you're a traditional org, no one's going to report to them, and if so, it's a more junior PM.

No engineers are ever going to report in to the PM, which means you have to get engineers to buy into what you're trying to do, to support you without any of them reporting to you. So you actually have zero authority.

Rimas: Yeah, trying to pull that off in two to three days is pretty challenging. But I think you can overcome it. I know I have in past jobs.

Craig: But you're generally just looking for the indicators. Does the team like the person? If you like them, it's a huge difference.

Now, for someone like sales, not to crap on sales, which we tend to do, but well, to crap on sales, you know, it's not my ideal, to go out drinking with a salesperson, usually. If you think of the used car salesman type, the stereotype...

Rimas: Do those exist anymore, I mean?

Craig: Well, with Tesla, probably not soon. But yeah, I mean, I've seen salespeople come in with their black books. I've seen those get hired at startups, and I've seen those close deals. So it's a question of how you want to structure your org.While they might be right for my business, the engineers aren't going to have to hang out with them.

With the PM, your engineers are going to have to interact with them on a daily basis. So I do want to see that there's a rapport there.

Rimas: I sure hope there's a rapport there. If not, then you have to really question this individual during the starter project. You know, one of my favorite things to do is have PMs get up and give that presentation. I think that is probably the seminal activity that I've had all of the ones that I've interviewed actually do.

They do the slide where, sell me on some idea, and I'm going to come back at you. Whether or not the questions I'm asking are based in reality or not, I am going to poke holes in everything that you're saying up there to see how you react to pressure.

Craig: See, it's really interesting because I take a different approach there, where I heavily coach and prep them, but then basically tell the engineers to go at them.

Rimas: Oh, so you tell the team to do it.

Craig: I tell the team to do it and see how they defend themselves against the engineer, how they hold up, how they look at that sort of probing. Within the starter project, I try to be their cheerleader, their support, prep them on every step of the way. But then I want to see how they debate with the engineers. I have to do it all the time. I want to see how they do it.

Rimas: So if there is any dissent within the team, if anybody says a maybe, or there's that one person that says no, is that enough to just kill the whole hiring process for that PM?

Craig: This comes a little bit back to your company's hiring policies. I've seen where anyone says a no, and that's an outright no, across the board. I think if you do build really high-quality teams, fow much do you build teams that are too homogeneous, there is an open debate.

I think it depends. There's a little bit on the why. Why are they saying no? Is it because they didn't think they understood the technology, and was that the goal of the starter project you gave them? The engineers don't always have the full insights.

You set them up with some info, hopefully your engineers aren't spending all three days with them. You're spending the bulk of that, but the engineers are spending some time. So, you've got to make a call there, based on why they said no, why they objected, and can you reason about it with them? How strong is that no? It really varies there.

Rimas: I wholeheartedly agree. I think it really depends on your situation. There I go again. I said, "It depends."

You know, if you're in a situation based on your company's hiring practices, where it's not like your hands are tied, but if you're in a situation where the candidate has been vetted, but there's minor dissent, sometimes that's okay. That's good enough.

I would concur with what you're saying, that it really depends on the goals that you'd set for that candidate when they came in and whether or not they made those goals for you as hiring manager looking for this PM.

So, you've gone through, you've finished your starter project. Is a starter project the only way to do this?

Craig: No, I think there's plenty of ways. It's a matter of how much time and effort you have. You can go through a traditional interview process. You're still looking at a lot of commitment from the team; can you give them homework? Can you give them, here's what we're talking about, interview an engineer?

I actually used this for a product marketing candidate, "I'm going to have you interview the engineers about this stuff, and now I'm going to have you write the launch blog post and create the launch plan. And I'm going to see what you come up with."

I understand it's a little throwing them to the wolves, because they didn't understand the technology. But there's other ways that you can do this. I think it is really imperative, at least on a first PM hire, to actually have them do some of the work.

Rimas: I think I'd agree with that. So, you make the decision, you say yes. What happens next?

Craig: At that point, hopefully, you make the job offer, they accept. And you're done...? No. The starter project I really like because it is more of that dating before you get married. You're both trying each other. Hopefully, you both walk away knowing that, "Yeah, this is great. This is what I want to do. This is going to work."

Rimas: Have there ever been instances where the candidate doesn't do that? Like, the opposite direction? Do you know what I mean? They're not really interviewing you, they feel like they're just being interviewed?

Craig: On a first-PM candidate, I have not found that to be the case. There's still a little of both sides. Now, at a later-stage PM, at a PM two, three, four at a 100-person company, yes, I have seen that.

That's a completely different discussion, and there you know you have a very capable PM, they've come through references, you're seeking them out. And at that point, there's a whole different playbook of whather you really need this person.

Rimas: For sure. When I finish a starter project, I think one of the last things I like to do, before saying yes to a candidate, is just being clear the tasks that they have to do, so they understand what they're getting into before it actually happens: "The starter project should illuminate a lot of that, but just to be clear, PM candidate, this is where I need you. This is what you need to do, and these are the expectations."

That way, so long as it's written down and you guys are agreed to them, when they show up to the organization, especially the 20-person company, they should know what they're getting into starting in, and where to focus their time and energy.

Craig: I like to do the alternative to that side as well, and say, "What do you want out of this? What's your goal here?" Especially on the first one. On the later ones, it's pretty clear there's a clear growth path.

If you're coming from someone that's maybe not a first PM, but it's their first PM job, that's a big one of, "What do you want to get out of this? Where do you want to grow in your career? What skills do you want to improve on? You're helping out, in a way, here, but I also want to support you long-term."

There's both sides of that, and I think having that discussion is really important.

Rimas: I don't want to imply that it's a set of tasks that need to be done, but it's more of, like, "These are the problem areas that we have that are acute right now. I need you to go and fix those things."

Craig: So you don't want to imply it's a set of tasks that needs to be done, but it is a set of tasks that need to be done.

Rimas: It depends.

Craig: Absolutely. Like, "Here's what's burning, does this make sense?" Then, "What do you want to tackle?" It's an open-ended discussion.

Rimas: For sure. I think on that note we've rounded the horn on hiring. If you have any more questions or want to dive deeper into this, hit us up at practicalproduct@heavybit.com.