2 Important Lessons on revamping a struggling SaaS Product

For product managers and founders struggling with products due to internal engineering mis-alignments

A couple of years ago [September 2019 to be precise], I accepted an offer to lead product advisory for one of the most challenging SaaS verticals — Workplace Productivity and Collaboration.

In these 2 years, I watched our stories go from “huge losses” the organization had incurred in 3 years of competing with giants, to press articles about us coming full circle to profitability. You can imagine how great that made me feel.

Given the uncertainty of the pandemic in May 2020, I decided to document bits & pieces of our journey for posterity, and I have decided to share 2 big lessons learnt on this journey with you.

Productivity tools are quite tricky to build and they come with enormous levels of ambiguity. As with most products, the metrics were tacky and my team and I took roots downwards.

PS — All goals & metrics are important, but prioritizing a metric in early stage products, precedes success or failure thereof.

Establish Metrics that Align strictly with your Goals, Then Cut Everything That Doesn’t Improve those Metrics.

My strong recommendation to product orgs is to build scientific mechanisms to help differentiate vanity metrics from important metrics per time [quarterly] . Diving deep in 2019, one huge problem we found was that the team had previously prioritized a vanity metric- new user signups- as a primary goal and consequently, everything they did was judged on that goal.

One could only wonder the rationale behind prioritizing that metric over others, despite the racing dip in adoption.

We then decided to drive two high level goals:

• Business success [i.e. incremental revenue / long term strategy].
• Value / Customer satisfaction [Desirable product experience].

As a result, all our engineering efforts will either tie back to one of those two goals in a metrics driven fashion or support them indirectly, whilst still keeping their own metrics [e.g. improving deployment or build timelines].

Nothing amazes me more than finding a product org with thousands of engineering man-days but when asked how these can be measured to demonstrate revenue growth, drive incremental improvement, improve customer satisfaction or developer productivity, everyone goes silent.

My recommendation is to cut such product innovations as you will keep burning investor dollars.

For profitable results, I recommend these 2 steps

1. Build a Positive Perception Around Execution.

- The Core Product Org.

At its core, a struggling product team is one where getting things done counts for nothing.

Once you have clear goals and metrics [that are revisited and validated quarterly], the next thing you need is drive a culture with a clear action bias.

You need to build a team with a culture that:

• Identifies a need [that aligns with the overall goal] and fills it.
• Anticipates user problems and prioritizes correctly.
• Continuously seeking ways to run better and faster for the customers.
• Drive immediate value for customers in need [strong Customer Support culture].

Since the product is struggling, you will likely encounter people who have the exact opposite mindset.

Your job is to tweak their mindset till they develop the bias for action.

- The Engineering org.

Did you know that 75% of product orgs fail due to the wrong engineering culture?

As an engineering team, you need to drive efficiency to repel the stagnation.

I recommend these 4 best practices -

• Team Composition — For growth stage companies, you do not need more than 8 people writing code. Optimize the PM:engineer ratio to a maximum of 1:8. You can validate this on your team by testing out 2/3 dev-ops practices & getting more out of your team without compromising the product.
• Authenticity — At the core, please do not copy/paste culture, be inspired instead based off your product and peculiar team circumstances.
• Autonomy — Let your team figure out how to solve problems, whilst you decide what problems to prioritize and solve. This way, they get to decide the best tools and framework to do their best work.
• Innovation — Overtime, we learnt that engineering is a lot more about assembling stuff available on Github than building solutions from scratch. These solutions might also require paying a 3rd party for a service or component. And that is okay.

I can guarantee you that it is often far cheaper to pay an offshore team, than what it actually costs you in salaries, to have your engineering team build out solutions. If you are always building from scratch, know that you are loosing time to market, feedback loops are going loose, your customers are impatient and your tech debt is rising.

2. Know your user segment and serve them well.

Very often, many product teams get stuck on deciding how to build an experience to delight customers since diverse categories of people use their product in many different ways.

It’s really important to know your audience and how they are different. Even more important to know what segment aligns with your product stage and prioritize them.

This makes your product easier to build, drives more organic adoption, and builds real and consistent value for your customers. For the product org. I advise, our most valuable customers are advertisers who spend considerable amounts of money with have lots of relevant & useful ads for consumers.

Now that you have prioritized these users, build a roadmap to re-visit your other user segments, test and validate their problems and then build solutions that would gradually drive them to your product and deliver value at their pace.

For example, we made a couple of changes in 2020 to simplify and provide clearer guidance when setting up an advertising campaign. As much as this works well for smaller advertisers with a handful of advertising campaigns, it is not relevant to an advertiser like a major retailer with thousands of campaigns spending millions of dollars.

Such users would prefer programmatic access via an API versus walking through a manual setup for campaigns.

Summary

It is important to build a mental model that demonstrates to your team that one size will not fit all and you should dedicate resources to improve the experience for all major customer tiers of your product.