Building profitable products with customers

Hot take: All SaaS orgs want to deliver a solution that delights and excites their customers. (🤯..obvs.)

But it can be a mistake to think that addressing all customer demands naturally leads to conversion, retention and revenue growth. 🪴

How do you walk that tightrope between launching a dynamic product, while still meeting those all important revenue goals, without plummeting into financial ruin?

Well, in the episode of SaaScast, Jacqueline Porter, Director of Product Management, addresses this crucial question, with vital first-hand insights, including:

🛠 Building products for developers

📣 Prioritizing customer demands

👔 Communicating with senior stakeholders

🎖 The importance of customer advocacy

We’ve compiled the highlights here, but you can catch the full unedited talk right here.

The irresistible allure of product management

What first drew you to product management, and why has it been such an enduring passion for you?

This is always such a fun question for me to reflect on. For the last 10 years, I've been in the tech space. I've been working with companies on building successful products and delivering successful products to market.

A key part of that is working with developers and engineers day in day out and helping optimize the performance of those teams.

I did have an untraditional start though. My first career, which I spent about five years in, was in construction management. Most people may not be aware of how technical that discipline is.

A lot of software is used to plan, organize supply chains, and manage scheduling, for example, so I spent a lot of time working with software products to drive efficiency.

I decided to pursue my Master's in business after two or three years in the construction industry because I realized it wasn’t the right fit for me.

And then it was in Austin, Texas – that's where I was getting my MBA – that I connected with some people in the startup space and then made my way into my first tech job, which was a merger and acquisitions project management role.

I was quickly promoted at that company to manage a project management office with the idea of streamlining operations. For some reason, the leadership in the organization really had an affinity for someone who brought an outside perspective.

I feel like a lot of the people in that organization grew up in tech and didn't have diverse ideas on how to make things more efficient. After delivering some incredible results, I made a strategic exit from that company.

Then I started to get the itch to build something new. A big passion of mine is to improve things to continuously drive effectiveness across organizations, so I connected with another startup in the area with a little bit of a different focus: product implementation.

I was more on the customer success side, helping to deliver and implement products effectively.

I was again promoted really quickly, and then we were bought. I stayed with the company and I was promoted to a Director of Product role and was acting Chief of Staff for both the Chief Product Officer and the Chief Technology Officer.

In that role, my whole focus was getting our product to market as fast as possible with the best results for our company.

What was interesting about this is that I spent a lot of time thinking about all the bottlenecks and pain points of our developers, engineers, product managers, and product designers so I could improve our throughput and deliver the most value for our customers. That was a very exciting role.

Now I've been at GitLab for almost three years, and I've been promoted into a Director of Product position again. I’m spending my time now building product teams and delivering the GitLab value to our customers for a particular segment of our platform.

Why it’s essential to capture the voice of the customer

You mentioned how you've become mindful of customer pain points and that's been part of your journey to excelling in this career.

How important is it to capture the voice of the customer and set up that continuous feedback loop between the customer and the org?

This question takes me back to when I read books like Inspired and The Build Trap because when you’re starting to think about building a new product, you feel like you should be delivering exactly what the customer says, but that's not always what's going to lead to success.

In the end, customer feedback should definitely be one input into the product development lifecycle, but it can't be the only one.

Customers will often ask for what they need now, and they often already have a solution in mind. If you’re building what they're asking for, you might not deeply understand the pain points in their workflows; then you can't build the next step because you're waiting for them to tell you how things should work.

It's important that you deeply understand the user, their dreams, their pain points, their desires, their joy, and what's delightful for them. Then you're going to be able to create an expanded product rather than just solving the problem that they have right now.

The challenges of targeting developers

At GitLab, you're targeting developers, which is a very particular kind of persona.

We're always hearing about how developers are quite a discerning kind of audience and are quite difficult to engage with, especially for feedback because they’re often just so busy. Is dealing with developer customers a unique challenge, or do the usual rules apply?

I don't think you have to use any different skills to deal with developers, but you do have to think about what a developer's task is and what's specific to that user – just like any other end user.

At my previous company, I was in martech, dealing with technical marketing professionals who create social media campaigns, are very much disciplined for their tools, and understand the firehose ingest of Twitter and Instagram.

They're very technical in that discipline, and if you don't listen to what they need, their problem is going to be better solved by a competitor’s product.

In business-to-business SaaS companies, customers’ organizational pain points are distinctly different from those of individual developers.

Some B2B companies now have roles that are exclusively for things like developer experience, so we're starting to see this emergence of developer evangelism because companies are very much focused on how to improve that throughput and optimize workflows for their developer audience.

That’s because – let's face it – every company is becoming a technology company. Almost every company has an app. Dry cleaning has an app. Grocery stores have apps. Every company using technology has developers on staff, and the best way for them to be successful is to drive efficiency through their products.

Something I’ve noticed that’s specific to developer personas is the BS factor. Typical marketing speak and typical pitches aren’t going to work as well on them as they might on a different user.

Developers generally need to accomplish a particular type of task, and they need to do that as fast as possible, so when you’re marketing to a developer it needs to be about efficiency, optimizing, and saving them time.

Bridging the gap between you, the developer, and the buyer

There’s often a gap between the people who are actually going to be using the product – the developers in the company – and the buyers, who may be more senior stakeholders in the organization.

They’re both crucial players, and you want the buyers to buy something that the end users will be able to use. How do you balance your approach to the two?

What we're noticing in the technology space, especially when it comes to DevOps tools, is that the buyer has less authority than they do when it comes to marketing solutions or even education or municipality software, where buyers are typically super important.

For technology purchases, there's this process of CTOs asking their teams to evaluate solutions technically. GitLab has the advantage of being a developer-first product because developers can be our buyers or can sway the traditional buyer persona.

It’s important to prioritize investment cases based on the value they're driving. Let's say you have a free offering and a paid offering, and you have an investment case that says you need to improve some features on the free side because that will increase your conversion to paid by 2%.

However, the other option is to invest a bunch in your premium offering – a move geared towards your buyer persona – and that's going to increase your revenue by 5%.

Well, if you look at the conversion from free to paid, that could be a million users – that 5% revenue increase might be worth way less than the conversion.

The product manager may decide to place their bets on the free features so that they can optimize conversion and get more value for the organization, which in the end results in revenue, rather than investing for the buyer to make them either retain or buy more.

That's the balance. If you keep your eye on the prize, which is what you’re trying to drive for the company, and then weigh those two options, that's how you know whether to drive for the buyer or drive for the user.

Getting C-suite buy-in for product ideas

We've talked a little about the importance of customer feedback and knowing customers’ pain points when you’re building a product. Now let's move on to the next part, which probably makes some people feel a little bit uncomfortable – balancing all of that with profitability.

When you bring an idea into a pitch with your most senior stakeholders, you probably have to be mindful of those all-important metrics. Does every product manager know how to speak that language when they go into those meetings?

The biggest mistake I've made and I've seen other product managers make is overselling what their product is going to do. That doesn't mean that the product isn't eventually going to get there; it's just that there's a lack of awareness of how long it's going to take to start seeing meaningful results once we build and deliver something, and how long it's going to take to make back our money.

Product managers generally don't think in payback periods when they look at the opportunity. What they hear is, “I have a problem and I'm going to pay for the solution.”

However, if you're a seat-based product – like GitLab where you have a price per seat and the organization has to pay for a tier – it could be a long time before an organization wants to move up to the next level, which could be significantly more costly for an incremental feature improvement.

This is where a product manager goes into a C-suite and says, “This is gonna drive millions of dollars of revenue… in 10 years.” But C-suite people are there because they've managed risk really well. They've placed their bets where it counted, they know what kind of risks to take, and they know what risks to avoid.

It's critical that product managers bring a full picture, with all the risks, of what their product improvement is going to do for the business.

Sure, a short-term investment that increases immediate revenue or usage is really attractive, but long-term bets have to be made in order to be competitive in the market, and there has to be a long-term investment strategy for innovation.

A tool that I've used to convey this to a C-suite member is the lean canvas. I create a five-slide page, a five-slide deck, or a five-page readout of that lean canvas, which highlights the opportunity, the problem statement, the target market, and what kind of influence we're going to have on the market by delivering this.

Then there’s a 50-page appendix, which outlines the business case, projected ROI, payback period, projected usage models.

That allows me to very quickly show executives what this product or feature is going to do, who it's for, and what we think it's going to do over time. Then, if there are questions about the model or the forecast, we can scroll on down to the appendix and take a closer look.

That has been the most successful way that I've had new teams added to products. It’s also helped me get executives to think about changing strategy if we were headed in the wrong direction.

The gist of it is that what you present has to be short and sweet, but then all the details have to be provided at the end. You also have to make sure that risks are holistically considered and product improvements aren’t oversold.