For the last 8 years, a big part of my job has been product management. Prior to Outseta I never worked as a Product Manager and like most, I have no formal training in product management. But here we are.

This post is a round up of what I’ve learned about product management—my learnings, opinions, and some of the ideas that I’ve developed some conviction around.

Before I dive in, there are a couple of circumstances and caveats that I feel are important to mention as they may impact the relevance of this post to you.

Product management is a tough job

Product management is going through a rough patch in the world of tech at the moment. Particularly in small companies, it’s become en vogue to cut out the product management function entirely—often relying on a developer or person with topical expertise to absorb the product management function. When I’ve gone to tech events recently, they all seem to be filled with Product Managers looking for work.

I understand why this is and I can’t say that I totally disagree with it. I’m not here to make a case for when a dedicated Product Manager is or isn’t needed, but I feel very strongly that there are many instances where a dedicated Product Manager is essential.

Product management is a tough job. Product Managers sit at the intersection of design, development, product, marketing, and possibly other departments. You need to work cross-functionally, you need to move your area of the product forward, and you need to make sure your work fits into the broader context of your company’s product and business strategies. You’re not just making decisions on product functionality, but also need to consider areas like packaging and pricing.

It takes vision, tactical skills, and soft skills to pull all of these chords together effectively—we should celebrate great Product Managers more than we do.

Product management is very different if you’re building something net-new

The main caveat that I want to share with you before I dive in is that product management at Outseta is quite different from product management at companies that are building something more new and novel. Outseta offers payments, authentication, CRM, email, and help desk features—these represent some of the most mature and competitive categories of software out there. There is a lot of precedent (and expectations) in terms of what features such tools should offer, and in most cases this makes the job of product management easier.

When my Co-founders and I first sat down to mock-up the first versions of Outseta, we simply looked at the best-in-class tools across these categories of software. We borrowed the ideas, workflows, and UI components that we liked from each and talked about the areas of each tool that frustrated us.

The point is that there is plenty of precedent for what a good email tool or authentication workflow looks like—the work of product management at Outseta is not so much focused on figuring that out. It’s much more focused on pulling together all of these components into a cohesive platform, where 1 + 1 = 3 as a result of these tools communicating with one another.

Even today, we’re rarely at a loss for what to build. It’s much more a matter of how quickly we can build what we want to.

I feel that this is an important point to share up front, because product management when you’re building something that’s more new and novel is a very different game. The work is in figuring out who your customer is, how to solve their problems, and what even needs to be built in order to do so. We simply don’t wrestle with this set of problems nearly as much at Outseta because we’re building in very established categories and for types of buyers that are well defined.

Now, on to what I’ve learned.

Saying no to good ideas is the work

If I was forced to distill the work of product management into its simplest form, it goes something like this…

A customer comes to you with a feature request that’s well thought out, well articulated, and would absolutely be beneficial to them. It’s a genuinely good idea, and it’s likely applicable to other customers, too.

The work of project management is telling the customer, “This is a good idea, I get it, but it’s not something we’re going to be able to add to our product.”

It might be that the feature adds complexity to your product. It might be that the feature isn’t applicable to as many customers as it really needs to be. There could be a whole host of reasons, but ultimately you are the gatekeeper and steward of a product experience that needs to be as user friendly and efficient as possible. You need to fight for that, everyday.

So many great features simply detract from the overall product experience. Your job is to learn to recognize when seemingly good ideas are bad ideas.

I’m against public product roadmaps

I used to think that the decision to maintain a public product roadmap was mostly a cultural one. If that were the case, Outseta would surely have a public roadmap—we’re extremely transparent with almost every aspect of our business.

I’m now pretty firmly of the opinion that public roadmaps are net-negative—for all parties involved. Look, I get it—customers want to know what’s coming and always appreciate a look behind the curtain. But public product roadmaps:

• Typically end up being little more than a marketing ploy
• Put constant “Is it ready yet?” pressure on product teams

Over the last few years a competitor of ours maintained a public roadmap—it promised that unicorns, ferris wheels, and large swirly lollipops were just around the corner. Their customers cheered while their competitors shuddered.

Over the course of a few years, basically none of it came to fruition. Customers became frustrated and the company increasingly pushed out half-baked features in an effort to keep up. The result was net-negative for everybody.

As a Product Manager, maintaining a public roadmap is a near guarantee that you’ll have a steady stream of work in simply replying to “Is it ready yet?” questions from your customers—customers who generally don’t have any insight into all that goes into building a great product.

For example, just a few months back we were in the middle of developing a major new feature. I woke up one morning to alarm bells from Stripe—Outseta had been flagged for an issue related to PCI compliance, an important industry standard related to how we handle credit card information. This came as a complete shock, as everything we do related to handling credit card data is exactly “by the book.” Yet this issue had the potential to shut our ability to process payments down.

It took us more than a week to figure out exactly what was causing the issue—we had a customer who was not capturing credit card information via the sign up forms Outseta offers. They were instead capturing raw credit card data from their customers, then entering that data directly into Stripe (initially circumventing Outseta, causing the alarm bells to sound).

Issues like these—and far more predictable ones—happen all the time and product teams need to respond. I find it far better to have space to deal with all of the things a product team may need to address—and to have the opportunity to delight customers when you do release well thought out and well-built features.   

Backlogs should be small—and obvious

In the early years of Outseta, we did what so many companies do—every time a feature request came in, we dutifully documented it and organized it in our product backlog. Before long we had hundreds of feature requests documented—so many that it became impossible to keep track of which ones were even relevant anymore.

In late 2024, I went through our product backlog one day and slashed it—from 233 items down to 42. About 8 of those features ended up in a “Prioritized Backlog”—features that we truly intended to build over the coming months. It gave our team much more direct insight into what was coming next, and generally a lot less confusion.

I can’t name a single negative repercussion that came from this aggressive pruning of feature requests.

In fact, I probably should have cut those 42 remaining feature requests down to about 20.

Beyond this, I’m very much of the mindset that the most immediate and pressing priorities should be obvious to your team—they shouldn't really even require documentation. If you are consistently close to your customers and their problems, the “Hell Yes!” features and product improvements should be very apparent. This is particularly easy at Outseta because everyone on our team contributes to support and interacts with customers directly, every day. 

In larger companies or those with a more specialized division of labor, this will take additional work.

Define your arena and stick to it

One of the things I’m most proud of is we identified the core tools that SaaS and membership businesses need, and we’ve stuck to building those tools:

• Payments—To collect money from customers.
• Authentication—To log customers in and out of your product or site.
• CRM—To track prospect and customer data.
• Email—To communicate with prospects and customers.
• Help Desk—To provide customer service.

To be fair, our arena absolutely represents an abnormal amount of real estate for a small team to cover—but we’ve defined these tools as the arena in which we’ll play and we haven’t wavered. That's not because we want to have a large surface area—it's because the power of our product is derived from its all-in-one nature. Outseta is very intentionally a platform rather than a product that solves a single problem well.

This is easier said than done—there’s always pressure to expand. For example, one of my Co-founders has been pushing us for years to offer an NPS surveying tool (a popular method of measuring customer satisfaction). It’s relevant to nearly the entire customer base! But time spent building this is time taken away from the laundry list of improvements that we need to make to the five core tools listed above—it’s a dilution of focus. 

Similarly, customers are constantly asking us for features like event registration tools. Again, a feature that would be super relevant to many of our customers—but also one where a third party tool can actually work quite well.

Because of the amount of real estate Outseta already covers, we’ve been very aggressive in “bouncing” completely new feature sets away. Most software companies start with a much smaller surface area and eventually the work of product management becomes figuring out where to expand to next, but I’m still a big believer in identifying your surface area and fighting to maintain it as much as possible. I’ve yet to meet very many software products where the core features are “too good.”

More? How about better

I think there’s too much emphasis in product management on shipping MORE features. While my previous point was about identifying the key components of your software and sticking to them, this point can be applied more granularly.

Let’s use email marketing as an example. Many Outseta customers have asked for more robust tools to create visual workflows around email automations. For example, if someone is part of drip campaign A and clicks a specific link, then they should automatically enter drip campaign B. If they click the link in the second email of drip campaign B, then they should enter drip campaign C and be removed from drip campaign A. That sort of stuff.

These features are valuable and fall within the bounds of email marketing, but I always try to ask myself “Should we be building this new stuff, or should we focus on making our existing email functionality that much better?” For example, we could instead improve the user experience of our email designer or work to ensure that our email deliverability rates are as high as possible.

As we sit here today there are a slew of improvements I’d like to make to our existing, relatively simple email tools. I think you’re usually better off making what you already offer that much better.

Options equal ambiguity

I am also firmly of the belief that the more options a user is presented with the more you generally hurt yourself—you need to solve for the most common use case rather than trying to appease everyone.

For example, Outseta’s onboarding experience today focuses heavily on walking customers through the process of setting up our payments and authentication tools. These are the features of our product that buying decisions are most often made on, and they’re also the features that most directly indicate that a customer is adopting Outseta once they are set up successfully. 

80% of our customers start here, so we optimize for them—even if that means that the onboarding experience isn’t well optimized for the other 20%.

There’s no doubt that some of our customers sign up, and aren’t yet at a point where they need payments or authentication features—they might just want to throw a “Sign up for our beta” email form on their website as they work to develop their product. We previously offered customers many more options in terms of their starting path with Outseta, but we found that the more options we surfaced the less progress anyone made. Present someone with a fork in the road and they’ll hesitate; offer them a single path and they’ll carry on.

A visual representation of this idea can be found within Outseta in places like the dropdown menu shown below that says “Show Advanced Options.”

In this example, expanding this menu surfaces a bunch of additional settings pertaining to Outseta’s sign up forms. There’s some good, powerful stuff in here relevant to our sign up forms but it’s generally stuff that’s not required to use our sign up forms successfully. By tucking this stuff out of sight, more people have been able to get through implementing Outseta successfully.

The point here is not to tuck everything under an “Advanced Options” menu—there’s plenty of problems in doing so. But removing clutter and eliminating options tends to get users through software workflows more effectively.

Personalization = permutations = problems

I have a feeling that this one will go down as the most controversial of the opinions I’m sharing in this post, with a lot of people scoffing at it…

But I’d go so far as to say that I’m *relatively* anti-personalization.

I can hear the disgust already—of course more personalized product experiences are better. They speak more directly to each user and their unique needs. They’re hyper-contextualized to fit like a glove—how could that not be better? Convert higher? Be more sticky?

From an intellectual standpoint, more personalized product experiences are absolutely favorable. But I’d argue product management is more practical than intellectual.

As you take user data and use it to further personalize the user experience, you add more permutations of possible user experiences to your product. Instead of maintaining one user experience, you now suddenly need to maintain five—and with each new variable that you fold in, the number of possible permutations grows even further.

While there are certainly tools that can help you deliver personalization at greater scale, the point remains—beware of the additional complexity that personalization adds. 

I have seen far more software products catastrophically hurt the user experience when well-intentioned attempts at personalization go wrong than I have seen companies dramatically improve the user experience. This is another flavor of less is often more. 

Explain your decisions and problems melt away

This one sounds so simple—and it is! Oftentimes customers will come to me asking for a feature, and I’ll know that my response is not going to be what they are looking to hear. In these scenarios, I’ve found that taking the time to explain my thinking often completely solves the problem. Customers may not have thought about the problem from your perspective, and sharing your thinking with them will often help them identify other paths forward. People almost always appreciate the explanation.

For example, a customer recently came to me hoping to set up weekly subscriptions. It was a high potential customer that I really wanted to do right by—couldn’t we just add a weekly subscription option for them?

This is a feature that sounds like it would be super quick to add, but in reality it’s quite non-trivial to build. Additionally, there are real-world reasons why we’re not crazy about offering a weekly subscription option. I sent the email below to this customer:

Frankly, my response here is relatively short and not particularly well reasoned—in retrospect I wish I had taken a little more time to explain my position. But a reply came quickly:

I’ve seen this pattern play itself out over and over again. A short explanation buys you a lot of understanding—and you should always try to present users with alternative options when you can. 

Notify customers when you release their feature requests

The most obvious item in this post, but all too often forgotten… if you build a feature request that a customer submits, shoot them a quick note to let them know that the feature they requested is live!

Yes, this may be covered in a product update that you send to your customer base at large but a personalized email goes a long way. Sure, there’s an aspect of “getting credit” for building something that the customer requested but it’s much more about showing them that you are listening and acting on their feedback. It’s important to make your customers feel like they’ve been heard. 

Doing so helps customers feel invested in improving your software and the good ju-ju flows both ways.

Opportunities for delight = broadly applicable and fast 

Perhaps the biggest competitive advantage that start-ups have over bigger organizations is how nimble they can be. We all love the stories of start-ups pushing out new features or fixes for customers just hours after they are requested!

Use this to your advantage and make sure your product work is fluid enough in terms of timelines to leave space for this type of work. Don’t make promises, but if a feature request is truly broadly applicable AND something that can be executed on very quickly, jump on it. Customers love this stuff so make it happen when you can.

Learn to disqualify potential customers quickly

While this may sound more like sales advice than a product management tip, I think it’s equally important that Product Managers learn to quickly disqualify less than ideal fit customers. Move on, and move on quickly—the more time you spend with customers that don’t quite fit, the less effective you’ll be in product management.

To this end, I’m always on the look out for “Can we make this work?” type of conversations. Whenever you find yourself in this scenario—where you know your product doesn’t quite fit the needs of the customer—be direct about that, suggest alternatives if appropriate, and move on. 

It’s not about being difficult or not being willing to work with the potential customer to find a workable solution—it’s about saving you both time. 

I am absolutely positive that if you look at the resulting output of all of the “Can we make this work?” conversations that have been had between software companies and potential customers all-time, it’s massively net-negative relative to the time invested in such discussions.

Documentation (and support) are product, too

I can’t emphasize this one enough—Product Managers like to think that their domain is the product itself, the code that delivers the feature set that they oversee. But there is massive opportunity in treating your documentation as part of your product, too.

I’m the first to acknowledge the sentiment that yes, no one reads the document. Trust me—I have literally emailed customers documentation that offers a word-for-word, exact answer to their question and they have responded asking for a meeting. I’ve then read the documentation to them—word-for-word— and the problem is solved. The point here is just that everyone absorbs information differently, but some people will turn to your documentation.

Writing good documentation is hugely beneficial in terms of creating clarity around your own understanding of your product, and it has the potential to massively reduce your support load too.

It’s called software-as-a-service for a reason, and I see only benefits to treating your documentation and your support team as a part of the product experience that you should consider as a Product Manager.

I want to end with two more points that represent things I haven’t fully figured out or adopted yet, but that I’m generally hot on.

Balancing big items and small items

There are countless approaches that Product Managers take to balancing the time they devote to big items versus small items. Some PMs assign “points,” others call some items “rocks” and others “pebbles,” and we dream up all kinds of crazy matrices that reflect the level of impact versus level of effort each new feature requires.

I’m not dogmatic about any of it, but I do think it’s critically important that you find some balance. There should always be ongoing work on big, strategic features—but how do you fold in smaller enhancements or bug fixes?

We have not formalized anything in this direction at Outseta, but it’s something we should think about more. I know for a fact that there are 6-8 items sitting in our backlog right now, that are truly minor updates, that collectively add up to making the product significantly better. I think every Product Manager should have some sort of approach to tackling these items somewhat routinely, celebrating how much progress you can make with a bunch of little improvements collectively.

Consider paid feature development as funding

I see more and more start-up teams doing this and I think it’s super smart. The idea is simple—if someone submits a feature request that’s a good idea and one that you genuinely intend to build anyways, be open to prioritizing the development of that feature if the customer is willing to pay for it.

This is a great way for early stage companies to make some additional money, you release a feature that you would have gotten to eventually anyways, and the end user has their needs met—this can be a win-win. We’ve never done this before at Outseta, but it’s an approach I’d be open to and wish we had utilized in our early years.

‍

So much of product management boils down to identifying how to solve your customers’ problems, remaining focused on solving those problems, and prioritizing ruthlessly. It’s a tough job, but it’s one I’ve come to enjoy. I have never considered myself a “product person,” but that’s a self-description that I see slowly melting away.

‍