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.