Every Product Manager is a ninja when it comes to dealing with functional requirements. But it doesn’t end there in the B2B space. You may not be a technical product manager, but you still need to understand and address some non-functional requirements without which your product isn’t ready to sell – especially if its transactional in nature, holds sensitive data or requires integration with the client’s IT eco-system. By ‘address’, I don’t mean you need to plan these as features or get involved in the R&D – it’s just about getting answers to what has been done in this regard.

What makes non-functional requirements so important?

Good question! If your product touches any of the 3 aspects mentioned above, the client’s decision to buy the product is incomplete without involvement of the IT team. You might have the CXO’s approval, but even if a single IT executive deems your product unfit for the IT security standards the client is committed to – the sale is likely to fold. You need to make a compelling offer, not just to the functional decision makers, but also to these non-functional evaluators whose buying is equally important. And there is a fair reason to it. Imagine, if you’ve worked hard to keep a floor clean, and someone wants to walk in with their own shoes – no matter how clean they claim to be, would you let them in? IT doesn’t want to risk their network either. I really don’t see this coming in the way of B2C sales – a LinkedIn premium membership or even Online Banking for that matter.

What needs to be taken care of?

Here at at-least 7 areas for which you will need clear answers.

1. Software requirements: With SaaS, customers have fallen in love with apps that railed on web browsers. But IT remains unsatisfied with the ‘my app runs in a browser’ response. They need to understand whether it runs ‘best’ on a particular browser or a specific version. As a product manager, you need to know the share of each browser version and build support accordingly. Dependency on components (e.g. FLASH) can cause the deal to hit a road-block.
2. Data Security: Customers always question the security of their data while using hosted services. And this becomes all the more critical when you’re selling a multi-tenant application. If you’re able to help them get over the SaaS phobia, the next questions could be around data security & access control, data center certifications, third-party quality assurance reports, etc. Apart from this, customers solicit information about user authentication and authorization capabilities, user management from the application console and integration with existing user management solutions like LDAP. Don’t be surprised if a client demands a sandbox for a hands-on verification.
3. Flexible application stack: Customers may explicitly specify software requirements such as the use of specific database engines or application servers. In some cases, they are even willing to pick the tab for additional license fees to ensure that the application stack is as per required standards set by their organization’s IT Policy. In this situation, the application should be capable to run on multiple technology stacks.
4. QoS & SLA: Customers often demand clarity in terms of the Quality of Service (QoS) and Service Level Agreement (SLA). Common metrics used to define the SLA include the application up-time (usually 99.X%), response times, issue turn-around-time, etc. Limiting the down-time (for any reason, including upgrades) to a few hours every calendar period is commonplace these days.
5. Implementation time: Businesses in the past have been spent large amounts of capital, human and financial, for the implementation of enterprise-class business applications. Project Managers are wary of burning their fingers in another project and risking their jobs. It is not just about presenting a shiny business case or an optimistic project plan, but demonstrating the ability to get the software up-and-running in no time. It adds a lot of credibility to the RoI promises.
6. Data back-up & export: SaaS-based applications are mostly sold through a subscription model. This gives customers the flexibility to change their decision based on budget and satisfaction level. Due to this, the exit clause of the contract plays a critical role in the deal. Customers are keen to understand if there is a lock-in and how their data can be extracted on exit. The application should be able to export the customer’s (tenant’s) data in human-readable format.
7. Data center location: Beyond, data center certifications, customers are often concerned about where the physical location of their data. For an organization’s strategic advantage, or for political reasons in a region, a customer may want to chose where their data is hosted. Some customers may want data to be hosted locally, while some countries may have legistation around this. (E.g. safe  harbor requirement)

What does a Product Manager need to?

You don’t need to answer these yourself. But don’t wear the ‘I’m a non-technical, market-facing PM’ hat and sit idle. Start working with your Engineering, IT Infrastructure & Support teams to get answers to these questions. Prepare artifacts to make your point, get copies of certifications and third-party reports to support your answers. And if resources permit, setup a sandbox for the client to verify your claims.

This post is part of the SaaS Application Development series, extracted from my final dissertation submission at BITS, Pilani that closely looked at rapid-development of SaaS-based applications.