Competitive Analysis – Briefs and Features

Everything is fair-game between qualitative and quantitative user and competitor research. For SaaS-based businesses especially, there’s a need to stay knowledgeable of the market and its competitive landscape. It’s hard enough focusing on features that bring delight to customers, but there’s also a perspective that staying even-keel within your competitive space brings on real help to your product line and the people that aim to support it.

Let’s take an example, let’s say Sally Sue is talking to a prospective customer who’s knowledgeable about multiple options available to her. She asks about X, Y, and Z features and to see if the product supports it. For the Sales rep, let’s call him Dan, he needs to be knowledgeable that not only do we have support, but the product also does support these base-line features (or at least has a number of other features that fit well for Sally). Sally just wants to know enough to make an inspired decision.

Competitive analysis for a product manager isn’t just about feature-development, but also about ensuring a holistic view of the product. For me, I like to take a qualitative view with competitor briefs and append a quantitative analysis that is feature based. It uses a weighted-value analysis with a likert scale approach to cross-match User Interest and Features across the market. On the far right, there’s a percentage column for aggregated value fit of features provided to users (AH) and a weighted value fit (AI). You don’t worry about doing any formula work, I was able to add in a weighted value analysis formula onto the sheet.

What does this help with? A lot of things:

1. You have an understanding of the competitive landscape for your particular product area or space.

2. You can share a static document to your Sales, Customer Support, or any Field team member in a SaaS model to support prospective customers.

3. This helps your tech writers and documentation team to ensure knowledge is spread throughout the organization.

4. Product development efforts are propelled to ensure your base-level feature set is known, understood, and ideated on.

Feel free to use the templates for the brief and feature-based weighted value analysis; if you find them useful, let me know. You can reach me via Twitter @aakashhdesai or Linkedin @aakashhdesai.

Thoughts on SaaS Product Pricing

Pricing is very important to the overall value of a product offering. It’s a first-order property of a product alongside its feature set that’s required to build the formula of value for any customer. In no real order, they pay attention to design, features, and price when making a purchasing decision. For pricing, it directly relates to the value that a user/customer will derive from that product.

For any product I’ve managed, I’ve been lucky enough to have pricing responsibility and owned it outright. Typically, SaaS-based organizations like to move price modeling off to finance or other groups. Product manager owns the success of the product; that means they own the price too. Just like with design and engineering, they need to work with cross-functional teams to find the right model (sales, finance, business systems, etc.). That includes customer research, modeling, and institutionalizing pricing to succeed out in the market. It’s required to set up a product and have it evolve as quickly and easily as possible with Sales and their customers.

Selfishly, I’ve been developing a price modeling and strategy template over the years. Want to share it out and make it available as a draft to iterate on. Hopefully, other PM’s out there find it useful.


  • Pricing Scenarios – Lists out various pricing strategies for a product you’re aiming to ship to a customer base. Segments out price models based off of target adoption and purpose of the pricing strategy.
  • Customer Monthly SaaS Tiered Blend – Spreadsheet input form for various MRR, Upfront, customer adoption, and top-level SaaS metrics you’ll need to accurately model and strategically align your product with its pricing methodology. Below lists the top values you’ll need to input into this sheet to model it all.
  • Tier Blend – Annualized view of key inputs and metrics set up in the above tab that applies a table-based view of the various customer segments, run-rates, and customer base growth across a five-year span.

Key Metrics (a primer on key SaaS metrics):

  • MRR – Monthly recurring revenue you expect to charge for the product applied on a tier-based view.
  • Upfront – Tier-segmented initial price to the customer for the product.
  • Total % of Customer Base – Segmentation of the customer base, in the initial year, that adopts the product.
  • Customer Base Adoption – Segmentation of the customer base, for subsequent years, that adopts the product.
  • Customer Base – Total initial count of customers expect to adopt the product in the first year.
  • Annual Growth Rate – Expected growth rate of the customer base on an annualized basis.
  • Churn – Expected churn rate of product’s entire customer base on an annualized basis.

The modeling template has helped quite a bit just looking into various models for customer research, modeling, and communications out to business teams who are ensuring its success. There’s a deeper question just how useful it is to a product manager to do this compared to just handing it off. I’ve always been of the opinion that you a pm puts their teams in the best position possible and that means to being over-prepared and know context better than any other team member. Take a look at the modeling and strategy template, let me know what you think via Twitter @aakashhdesai or Linkedin @aakashhdesai.

Note on Product Prioritization Frameworks

Always looking for ways to improve how to prioritize features appropriately to a roadmap. Each sprint is full of items to juggle between buckets of customer requests, items that improve customer retention, or (of course) increasing revenue. Features working towards on the roadmap are no doubt important, but fixing an issue customers see out in the field could potentially improve retention and apply a greater impact to the company’s bottom line.

The 1st approach calculated “ROI” by dividing using an averaged set of “Impact” ratings using a simple 1-5 likert scale (by my Eng Lead, UX Designer, Technical Support SME, and myself) and then divided the average by “Cost” (i.e. t-shirt sizing) to find ROI. It worked reasonably well; we were able to get to a prioritized list of features, but there was a skewing towards items that were quick wins and less towards major user features.

So, taking in some of the great PM content out on in the interwebs – I took the cue for my own team by trying to find a methodology. The latest approach uses weighted-values for 2 top-level product themes and “customer satisfaction” to identifying priority for each backlog item. Thus far, the priorities for each backlog item have all passed my PM gut. Also, there’s been solid feedback from the team too.

Take a look, hope you find it useful! If you find a way to improve on it, would love to hear about it.

Tripping on Accelerating Change

I felt inclined to re-read Bill Joy’s 4/2000 Wired piece today after reading up on Vicarious, Magic Leap and a few other companies around AI and augmented reality.

Why? I think it was really due to nerves. Feels like the rate of technological improvement is the highest its ever been in the history of human civilization. It’s invigorating to be a part of, but also very disconcerting. To me, it feels like we’re in a system that’s stuck in a constantly accelerating rate of change.

I believe humans were built to manage and direct systems that persist at steady paces, not those that accelerate exponentially. Sure, we can sprint in specific directions, but our minds and bodies require breaks inbetween to review and manage our general path. We don’t have the natural/genetic capability to accelerate and course correct at the same time continuously. If we want to continue this pace while still ensuring we’re on the right direction, we’ll eventually either stop, augment ourselves, or build something that can and have it do it for us.

At this pace, I think we’re going to sprint too hard in one or many very risky areas and create problem(s) we can’t fix.