At FOSSA, we’re fortunate that our product and engineering teams include a wide range of experiences and perspectives. This includes developers and product managers who have worked at the earliest of early-stage startups — like FOSSA during our formative years — and the largest, most established enterprises like Google and GE.

In this episode of The FOSSA Podcast, our senior product manager and one of our longtime engineers discuss product development and how it evolves as companies grow. We cover engineering-product team collaboration (and friction), product management tools, when to hire your first product manager, and more.

Note: If the embedded podcast recording is not visible in your browser, you can access the direct link by clicking here.

Episode Outline

  • Introductions
  • How engineering figures out what to build when there’s no product manager: 2:00
  • Product management at smaller companies vs. larger companies: 4:35
  • Product management - engineering collaboration (and areas of friction) for midsize companies: 15:50
  • Growth vs. customer retention during the start-up phase: 20:50
  • How engineering-product management collaboration evolves during company growth: 26:30
  • Ticketing and why (and when) it’s necessary and valuable: 28:40
  • How accountability changes as companies grow: 33:05
  • Product management tools (and how needs change depending on company stage): 39:30
  • Whether startups should focus on agile methodologies: 47:19

Episode Highlights

Note: This section does not include a complete transcript of the podcast; we encourage you to listen to the audio recording for the full version.

Software development without a formal product manager

When you're a small, early-stage company, not having a product manager is actually kind of easy. At FOSSA, a PM became very useful for us when we grew to the point of having too many customers for our developers to talk to and do full-time engineering work at the same time.

Of course, when you start out, you have no customers at all. And, as it turns out, it's very easy to talk to zero people. It’s also easy to talk to one person. Probably somewhere between $0 and $1 million in revenue, you can get a pretty good gut feel even on the engineering team because not only are you the one writing code, you're also the one talking to customers, answering support tickets, doing on-premises installations, and interacting with customer engineers.

What’s great about being an engineer for that sort of very early-stage company is the pace. I remember going into a customer's office to do a deployment on Thursday. And then we drank a bunch of Red Bull on Friday, we hacked out a thing, and then we came back the next Tuesday and we shipped it. And that was truly an incredibly surreal feeling at the very beginning.

It was so different from what I had learned at a large enterprise where a PM mysteriously drops a project into your lap that has somehow gone through the digestive tract of the corporate beast.

Product management in an early-stage start-up and/or small unit within a larger organization

In my previous role, working at Puppet, I was on our SaaS team. Basically all the other products were on-prem. so that was very similar to what it was probably like being the first PM or being the improvised kind of PM in a relatively early startup.

One of the most immediate takeaways at that stage is that the engineers are the pulse. You haven't really earned the right to say that you're the pulse of the customer because the engineers know significantly more about the space, they've interacted significantly longer than you have, and they have a deeper understanding.

So, being an early PM is really trusting and leaning on the expertise that the engineering team has and not coming in with this unnecessary pompousness and confidence of, “I'm the PM and do what I say.” That’s not helpful.

Whether startups should prioritize growth or retention

Before the startup phase, you have no customers to retain. And that phase is a ton of fun because you don't have to worry about any of this stuff. At the startup phase, I don't really think there's a one-size-fits-all answer.

I think it depends on the dynamics of your funding: the way in which your company was originally funded and how much you prioritize financial responsibility and sustainability. There are many companies where it’s not the priority, and there are many products where it doesn't make sense. If you're building a hard-tech product or you're building something that has no existing analog in the market, then you're going to have to do a ton of R&D before you have anything that you can sell.

And so that kind of company operates in a fundamentally different way. And there are many, many kinds of these fundamentally different companies.

I will offer what I think is a nice additional insight which is that I am strongly of the belief that if growth and retention are consistently in conflict for your organization, then that likely means you have two diverse sets of customers and you should only be prioritizing retaining the customers whose asks are in line with your product direction and your growth plan.

Now, of course, that plan can change very, very quickly. And you have to make sure that you're willing to deal with the consequences of changing that ideal customer profile. But, nonetheless, what I've seen play out more frequently than not in other startups is that the customers they're retaining are asking for a completely different functionality than the customers that they're building and growing with.

How the interaction between engineering and product management evolves as companies grow

Even the level of definition in interactions between product management and engineering should be orders of magnitude more descriptive as the organization grows. I think the root cause is the distance between the maker and the buyer. When you are a 10-person company, literally every engineer should be on phone calls with every customer.

When you have 50 people, maybe your engineers jump on a debugging call once every month or two. As you grow, you’ll have entire engineering teams that have never once spoken to the buyer or user of their product. And, in that case, I think you’ll need more words to convey the feature that you are trying to build because there's just so much more tacit knowledge about who this user is, what they want, what they don't want, and what they actually care about in this feature. That is no longer tacit knowledge in the maker.

You have so many more scalability concerns, migration concerns, and security and privacy compliance concerns. Of course, you don't have time to talk to customers. And so figuring out how to split the brain of the company effectively I think is a really hard needle to thread.

The evolution of accountability from startup to enterprise

One of those pieces on the accountability side that we haven't spoken to yet is around: Are we working on the right thing?

I feel like that manifests typically with engineers really digging into requirements and asking, “Who's actually asking for these things? What evidence do you have of the mass need for these things? And what evidence do we have that this thing is actually going to solve their problem and that we won't have to build another thing in the future?”

I tend to find that tickets or our product requirement documents (or your version of those things) tend to be these great places for having that negotiation and discussion: Here are the conversations that I've had with customers. Here's the evidence that I believe exists for why this feature makes sense. And then here's the actual feature that I think we should build based on the evidence.

Justifying feature development as the company grows

Every customer you get results in x new feature requests. When you have 10 customers, you're going to get 10x requests. When you have 1,000 customers, you're going to get 1,000x requests. In many cases, the number of requests that you get dramatically outstrips how your capacity to deliver on those requests.

And so I think you actually need more justification, not because the thing that you're doing is more valuable, but because you have so many more opportunity costs since you have so many more requests and all of these requests are backed by so much more money.

However, when you transition from the startup to the enterprise phase, I'm of the opinion that you actually have to justify less specifically to engineering. This is because you are typically at a level of maturity where you are working through this massive backlog of feature requests. And it's just a matter of picking which one to work on because somebody has already put in the thinking. But I think the justification toward your manager becomes orders of magnitude increased as you get to these larger phases.

In a large enterprise, you need to do a whole presentation a quarter in advance and convince the C-suite that you’re building the right things. So it almost feels like the justification is tailored more toward the internal stakeholders versus the makers in some of these earlier stages, right? And that switch kind of naturally happens as opportunity cost grows.

Product management tools for different stage companies

In startup phases, you can get away with Excel for just about everything. Google Sheets and Jira tickets are probably about all that you need as far as tooling. I think everything else frankly actually just slows you down.

An example of this is ProductBoard. I think ProductBoard is a great tool for being able to consume insights from various other tools like Zendesk, Jira, Slack, and so forth. But it’s also another full-time job to manage, maintain and keep up, which is the opposite of what you want during this particular stage.

We are now at the stage where we're using baby Jira; we're using cloud Jira with minimal customization. I have heard rumors that certain very large companies that use grown-up Jira, which is Jira that has been heavily customized by consultants, Scrum masters, and agile people with certifications of five-letter acronyms that I am not familiar with.

I think that the tools are actually much more impactful for anything that's customer-facing rather than for internal use only. Internally, Google can get us a long way. Of course, the design team is definitely going to need Figma. And from there, I think the world becomes your oyster.

I think Gong, for example, becomes extremely powerful to be able to record customer calls, reference those, and use them as justification in the future for feature development or why you're not building certain functionality.

Then, what are you using for your documentation, and how do you keep that up to date? Are you able to ingest open API specs so you can keep your API documentation up to date? Those decisions are actually far more impactful than whatever internal tool you're using.

How the role of product manager evolves from startup to enterprise

Ultimately, the evolution of being a product manager in the startup to an enterprise phase boils down to: If you work on two-week sprints, every month, you get two chances to be right. Every quarter, you get six chances to be right. Every year, you get 24 chances to be right. And, in early-stage companies, the only thing that you need to focus on is being right more often than you're wrong.

And, by right, I mean building something that your customers actually want and use and then ideally something that they actually pay for or something that gives them a reason to renew.

I think in the enterprise stage, you could be wrong all 24 times and it wouldn't matter as much because you probably already have this giant backlog of functionality that you can lean on.

In a startup, if you're wrong all 24 times, there would be devastating consequences. And so I think that if I were to kind of give some very general advice for someone thinking about being a product manager in earlier-stage companies and maturing throughout larger enterprises, I’d say: Really focus on how you can be right. And then figure out what information you need to be right? The answer is typically relying heavily on your engineering team.

Being a product manager at the enterprise level is a lot more about not killing the golden goose. But with startups, there is no golden goose, so let’s throw everything at the kitchen sink and see what we can sell.

Episode Host and Guests

Sara Beaudet, Support Engineer, FOSSA: Sara is the host of the FOSSA Podcast. They are passionate about cybersecurity, open source software, and helping people explore the world of technology.

Cortez Frazier Jr., Senior Product Manager, FOSSA: Cortez is the product lead for FOSSA’s SaaS and on-premises enterprise applications. He joined FOSSA following roles as a product lead at Puppet and senior cybersecurity architect at GE Power.

Leo Zhang, Software Engineer, FOSSA: Leo is an engineer on FOSSA's Platform team, which owns the back-end analysis services that power FOSSA's underlying data platform.