Product Management Skills Benchmark Report

The 280 Group is a Silicon Valley based training, research and consulting organization focusing on product management training and consulting for a long time.Their training and consulting staff are available for online, virtual or in-person training sessions. Best of all, their product management framework and process can be adapted by any organization, using Agile, Waterfall or a Hybrid methodology.

In late 2018, they did a survey of practicing product managers across the globe. The objective was to understand the definition of the role in different regions and industries, the key skills and responsibilities of the PM, and the skill gaps that product managers mentioned in the survey. For this survey, they identified 15 key skills (skill set) that a PM will use over the course of their career. They also include a skills assessment survey, which you can use to benchmark yourself against other respondents.
With more than 1,500 responses, there are a ton of insights from their Skills Benchmark Report. If you want a greater understanding of this role, or want to benchmark yourself against other product managers then you can download this report for free.

Few Points

  • Customer and domain knowledge was the strongest skill among PMs
  • Competitive Analysis, End of Life & Pricing were among the weakest

If you want to move into product management, or want to grow further, then this is a great resource to understand what is actually needed in the role. I hope you get as much value from this report as I did.

5 Reasons Why Scrum Teams May Not Deliver the Backlog

[This is a post from 6 years ago, but I came across this situation recently with a client, hence re-posting it here]

As a Product Manager, you should be used to hearing "NO" from every stakeholder, including the engineering teams. And then comes the hard part of persuading people to listen to you, even when they do not report to you. Of course, if you are talking to a vendor, or an IT services firm, you occasionally face the other challenge, of hearing a "YES", for every product initiative. With engineering teams, sometimes there is a hidden reason behind their "no" for a product/feature concept. Here are 5 reasons why PMs I know were not able to push through product requirements.

It's not cool enough

In the web world, certain technologies and features are considered cool. Others are not. So if you have a strong engineering team, they may simply nix the basic features such as logging, event viewer etc. in favor of features such as cross-domain APIs, "social" features etc. The trick is to keep a judicious balance in every feature review. And in case that's not possible, just promise them that the "cool" features are coming down the road. And be careful about the ever-present "code conversion" projects where they want to migrate the code from JavaScript to TypeScript or to use node.js and introduce SVG viewer and other features. Unless there is a business need or a strong performance reason, the "coolness factor" could be lurking about.

It's too tough

This is what I heard from an intern who joined the engineering team. They had worked on a matrix based hierarchical organization of real-time data for a year, and then they gave the same project to the intern to take analyze. Additionally, this was always the project that got de-prioritized over other initiatives. By sitting with the intern for an hour, it was easy to understand that this was an NP-complete problem, and optimizations were simply too tough for our data dictionary. (Here is a description of NP-complete).

It's too easy

I have been in teams that often said "no" to easy fixes. After developing the core feature, however badly, nobody wants to simply fix all the bugs or add the security requirements. Again, one workaround is to offer a bundle of features to the product team, where they cannot pick and choose specific features. 
In normal circumstances, these are the features that will slip the most in an early release, as they are deemed "non-core" features. For instance, the web-based admin GUI for a SaaS app often falls in this category.

We don't have expertise in that

No true engineering team will admit this, but this is also another hidden reason why teams say "no". In one instance, the team had no idea of the internals of Oracle's 11g release, so they simply delayed releasing a plug-in based on that. After several weeks of waiting and testing alternates, and with shipping of the core product getting delayed, this is the actual reason that came out during a hallway discussion with an engineer. The product management solution was to drop the plug-in and release the product.

If I agree, I will look weak

This is one of my favorites. Engineering managers in world-class organizations have a top educational background, have often won awards for their work and are viewed as stars. So if a great PM comes along with a perfect PRD, and has all the right features dictated by competitive needs, market analysis and user requirements, the engineering manager will simply say "no" to many features to satisfy his ego. (I do not know of any way to solve this problem, except to avoid entering such situations.) And going Agile, and becoming the Product Owner and backlog owner still does not always solve this situation.

SaaS Product Managers - Get your Data Processing Agreement in place

The European Union General Data Protection Regulation (EU GDPR) has come into effect on 25th May 2018. This is a landmark regulation to protect consumer data for SAAS companies that want to do business in the EU.
In essence, data collection requires informed consent of users, a data governance policy and data management tools, which includes the “right to be forgotten”. Actually, a more detailed e-privacy regulation is also in the works within the EU, but is yet to become law. Here is a brief description of how this impacts cross-border SaaS.

Impact on your SaaS website

For marketing and tracking user activities, websites often use cookies. These are either
  • essential cookies (login, session etc.)
  • preference cookies (remember password, language, time zone etc.)
  • statistical cookies (analytics, user activities)
  • marketing cookies (advertising, 3rd party data)
For engaging website visitors in EU countries, you need to allow users to understand what these cookies do and how they are used. Users must be able to opt out of the last 2 categories, or else they must be allowed to exit the site. And your privacy policy must explain clearly how individual user data is being used or anonymized.

Impact on your SaaS marketing

For marketing and advertising on 3rd part websites, or via social media or email, you need explicit consent of users. This consent must be captured, stored and deleted based on the user preference at that time. And there must be an easy way (email or website) to allow the user to change their preferences. Not only this, there should be adequate controls in place for protecting user data, whether it remains with you, or is shared with a 3rd party or vendor.

Data Processing Agreement

Unless you are a multi-billion SaaS business that is completely siloed, with its own data centres, you will rely on vendors for cloud storage, web analytics, email marketing and several other activities. The GDPR specifies that when you share user data, a written DPA is required with these vendors and 3rd parties.

The DPA is a legally binding contract that states the rights and obligations of each party concerning the protection of user data. A Data Processing Agreement identifies the data controller and data processor roles. The data processor must have controls in place, that can be audited, to ensure that user data is not leaked, lost or stolen. The GDPR also specifies hefty fines in case of non-compliance.
More details on this topic are available on the official website.

Typical Use Cases

  • A SaaS marketing team that wants to use an external email marketing service needs a DPA
  • A SaaS product manager who wants to display 3rd party advertising on the website needs a DPA
  • A SaaS product manager wishing to integrate with another SaaS or on-premise service may also need a DPA
 The last use case is often overlooked by integration teams; I will post more about this in the future.

Bottom Line

If you want to engage consumers in the EU region, and are sharing their data with vendors, get a DPA created and processes properly audited. Going forward, such regulations are likely to impact your international reach and expansion, not just in the EU, but in many other regions and countries.

SaaS APIs – Retain Customers and Expand Engagement

Customer retention increases when they find reasons to continue using the software, and they do not have reasons to look at alternatives or substitutes. There is a good economic definition of these substitute goods on Wikipedia. In addition, easy to track retention metrics and churn models simplify the efforts to predict whether a customer will churn or stay. (There is a good blog post on churn measurements here).

Additionally, to expand engagement, every SaaS vendor needs to identify different user personas and their usage patterns. Based on usage or non-usage of the software, new methods of user engagement can be identified. These can either be:
•    departmental (new roles within a department),
•    geographical (users in other countries in a MNC),
•    hierarchical (increase usage in head office vs. branch offices, stores vs. warehouses etc.) or
•    cross-functional (new processes created during organizational transformation that lead to cross-functional teams)

Here are two use cases that indicate how user engagement can be expanded via judicious introduction of APIs for new personas.

Use Case - Feature addition to retain personas

A large Canadian firm is merging with another company in Singapore. The new company has different processes, departments and hierarchy and is undergoing a long term merger/transformation program. Clearly, the existing processes, business rules and personas supported by existing features will not suffice. APIs are the easy way to make sure that existing users and business logic of the Singapore firm are retained and later integrated with your overall solution (Corollary: This will also lead to increase in subscription users).

Use Case - Feature addition to support new personas

A company is transforming its supply chain, and wants to make sure that all vendors are on-boarded into their new SaaS procurement platform. Not only is this an opportunity to sell more subscription to vendor users, but by properly integrating with the existing (potentially siloed) solution, many more customer employees can be on-boarded onto this solution, again leading to sale of configuration services and subscription licenses.

Retention and expansion of engagement are two ways to increase revenues without a large cost of sales. If your product team is not focusing on that, but on chasing new revenues only, then your roadmap is tilted towards short term features. This will harm you in the long run, when the competition’s retention rates increase, and your burn rate causes you to reduce your feature release velocity.

SaaS Revenue APIs – Increase Sale Per Customer

So what happens once a customer registers for your SaaS services?

The next step is to monetize your APIs. As the business owner, you should consider the following:
  • Registration or setup charges for the customer (This is also to deter casual customers who are only experimenting with the business model)
  • Usage charges (~$.02 per 1000 API calls)
  • API category charges (~$.05 per 1000 API calls for bulk APIs, advanced APIs etc.)
  • Consulting or support charges (per hour or per incident is the common model)
Looking at these monetization options, it is evident that the largest opportunity to increase revenue per customer is from usage of your APIs. Incidentally, this is also the model followed by many large platforms or aggregators.

The following is a use case from the online travel industry, of how API consumption and revenue generation occurs. With the right APIs, it is easy to allow more customers to sign up, and offer them differentiated data per API, thus increasing API consumption.

Travel industry API monetization use case

An online ticketing website such as wants to pull data about flights to satisfy a user query. This data is provided by Global Distribution System (GDS) such as Sabre, Amadeus and Travelport, who aggregate the data from different airlines, platforms etc. The user query must return data to allow him to view options, select an option, complete a booking, make a payment and get details of the booking on email, SMS and the site. 
The diagram below shows the high-level communication, and the APIs in red indicate the monetization possibilities.

For API usage, key fields to retrieve data from GDS:
•    Location of passenger
•    Source and destination of travel
•    Date of travel
•    Number of passengers
Key data points to retrieve:
•    Fields input by user (source, destination, date)
•    Airport codes
•    Airline codes
•    Combination of flights that offer the travel option
•    Price per combination
•    Data validity

 Unless the API or set of API support these data fields, the end to end transaction may fail, leading to a lost opportunity for the GDS to monetize the use case. And similar to this ticket booking use case, monetization opportunities also exist for many online platforms.

SaaS Customer Acquisition and On-boarding API

Once you have a deal for a demo, trial or term subscription, you need to make sure that users are on-boarded very quickly. This has three benefits:
  1. It can be a “go-live” indicator to mark start of subscription term
  2. License usage can be tied directly to the number of users logging in
  3. If users are on-boarded in phases, early users can indicate access or usability issues. This feedback can, in turn, simplify on-boarding of users in latter phases.
Here are the key APIs (application programming interface) that your SaaS application must develop and expose for close integration with client’s existing applications.
[Note: Most, if not all, of these API will need to support CRUD operations]

APIs common to most SaaS or Cloud applications

In this case, the SaaS application will need to expose the following User related API or endpoints
  • User import API
  • Bulk user import API
  • User identity API
  • User profile API
  • User security API
 For business processes, the related set of APIs include:
  • Process Life-cycle
  • Process Access Control
  • Process Data Transfer
  • Process Assignment
And for Reporting and Analytics, the APIs include:
  • Standard views of data
  • Data import into Analytics tools
  • Data export to common reporting tools

The first released version (or V1) of any SaaS or Cloud based application, if designed correctly, will definitely include most of these APIs.
Are these API on your SaaS roadmap?

No Man Is an Island, neither is a SaaS Application

Almost five hundred years ago, John Donne said this quote about man’s nature. Well, in today’s hyper-connected world, the same is true of SaaS applications as well. This radically changes the nature of the application, the demands on the talent and even the organization structure.

However, the key SaaS strategic objectives have not changed, which include:
1.    Acquire paying customers
2.    Retain the customers
3.    Increase the sale per customer
4.    Reduce costs and optimize operations
The first two are usually shown as part of the customer acquisition funnel, as in the image below.

SaaS Application Customer Funnel

But how does this play out for SaaS applications? It actually impacts the SaaS strategy in multiple ways. Here is a look at how the integrations or API strategy can impact all 4 objectives.

As you can see, there is tremendous value in thinking through the entire API strategy and how it impacts your business strategy. To think of a SaaS application as just a set of business rules and user interfaces for a few users is a very puerile assessment of the true value of the product. And a large part of that value is captured via the strategic addition of APIs.
In future blog posts, I will share additional details of how the API strategy works for any SaaS application for any vertical.

Three Fundamentals of a Winning B2B SaaS Offering

For a new SaaS product, it is important to have a robust MVP (minimum viable product). To create the MVP, you need to make sure that there is good coverage of a few areas, and reasonable coverage of fundamental user or buyer needs. The product team has to make several critical decisions to prioritize features in the MVP.

However, all great SaaS products cover the following three areas very well.
Three fundamentals of a winning SaaS offering

The business features to be monetized

A client will buy your product for their employees or users. To buy the product, a minimum set of business features are a must. These are the features that either offer parity with existing products or differentiate your offering from other products. Occasionally, certain CX or integrations capabilities are also described as differentiating business features. Salesforce Lightning Platform is one such example.
 Clients use this as the first basis of comparison (in different packages or payment models) with other products when buying a subscription.

 A robust cloud platform 

The platform is the key to supporting business, regulatory and user needs. A good cloud platform is infrastructure agnostic, and can support security and compliance needs, data movements and user life cycle at scale. It offers easy integration with existing IT infrastructure and simplifies the life of the application administrator. Architects and product owners must work with business product managers to ensure that the cloud platform can be built quickly and in increments.

Vertical or department specific features or rules

These are the domain specific business features that impact the usage of the SaaS offering in a vertical. Offering such features out of the box, is a distinct advantage compared to products that require significant configuration.
For example, a business may require configuration to prevent store employees from logging in outside working hours. If your application has a configuration screen to enable this, and easily set working hours, then that is a big plus for your user experience.

If your SaaS offering covers these 3 areas, then you can be confident that your clients are getting value from the MVP as it is enhanced.

SaaS Product Management – 5 Key Changes

(This post is intended for senior audiences)

There is a well known diagram of a software stack that describes the differences between SaaS, PaaS, IaaS and on-premise deployments. Among other places, you can see it on Microsoft's Azure Learning site and on BMC's blog site. I have modified it a bit to show the role of business product managers in SaaS applications.

Looking at the diagram below from left to right, you can see how business cost and value for the customer is shifted from owning to renting, or Cap-ex to Op-ex. Additionally, in SaaS, the only experience layer the client's users interact with is the application layer. And given the tiny footprint of the rented SaaS application, clients can no longer access the remaining layers.

However, every client still has business requirements that must be addressed, including Security, Standards Compliance, Availability and Business Capability. So, for product managers and directors looking to deliver business value from features and capabilities, here are 5 changes to keep in mind:

  • Customer Journey and User Experience(UX) is paramount

 The user experience of your SaaS application is bench-marked against every other web property. It is no longer possible to have navigation that is broken, or clicks that go nowhere. For a consistent user experience, use UX templates. Customer journeys must be created and designed for the smoothest user experience assuming that every touch point is accessible in real time.
  • Real time interactions are key

Because user engagement must be similar to the web or mobile app experience, it is important to have real-time feedback for every action. A wizard or widget must actively engage a user, let him complete his task and show feedback. At the same time,features related to real time user to user interaction, such as a chat widget or an IM become important even for SaaS applications. These are in turn managed either by the application support team, by the service provider, or by a 3rd party vendor. Product managers must consider how to handle and prioritize such features.
  • User privacy and security require new features or extra efforts

With SaaS, you are essentially handing over all data and meta-data about your company and employees, vendors and users to the service provider. Consequently, system architects managing the complete stack will figure out a solution to meet business and compliance requirements. This depends on the application's security posture, and time and investment planned for compliance and risk management. This activity either leads to backlog requests for adding new features related to privacy and security to your bucket, or it leads to investing time and resources to make sure that your features are compliant with the final architecture.
  • Internal teams are critical to deliver high application C-SAT

As a PM, you are pretty much looking at the top layer of the cloud stack. However, internal teams such as delivery, support, training, pre-sales, marketing will also have their own application stacks, without or without access to a live customer deployment. If as a PM you do not include features to make their work life easier (e.g. delegate access to customer environment) it will impact their capabilities on the application, which will hit your C-SAT objectives.
  • Agile development is commonplace, so are Product Owners

So you talked to dozens of key clients, identified all top features and prioritized the business requirements. This is no longer the end of the product specifications handover to engineering. 
You must breakdown the requirements into technical specifications and continuously track their delivery into the cloud application. With a CI/CD pipeline, the Product Owner takes care of this aspect of inward product management. However, the product manager still owns the UX and customer feedback. Net result, it is common place to find both roles in a cloud organization, with the PO reporting to a PM or a Director.