Boundaries – What You Can Specify and What You Can’t

All boundaries are conventions, waiting to be transcended. One may transcend any convention if only one can first conceive of doing so.

— David Mitchell

I get this question from Product Managers / Product Owners all the time (and a little less often, but still often from Engineers who feel infringed upon). The question is:

What can a Product Owner specify and what can’t they specify?

This is actually related to the previous post and my bold statement that:

Nearly every (meaningful) technical decision is a business decision

As a bit of a corollary, there are a lot of surprisingly many business requirements that result in a technical requirement. So the question is, “Which technical requirements can the business owner specify?”

The answer is (as always): it depends.

Let’s talk about a specific example before we generalize. Let’s consider the choice of a specific database: e.g., Oracle vs. Microsoft SQL Server. The answer to whether the Product Owner can specify a specific database depends (among other things) on whether the database is visible to the Customer. Let’s look at a few different scenarios:

1. Your company provides an enterprise application for use on your Customer’s premises and the Customer provides the database servers and licenses. In this case, the choice of which databases to support is almost certainly a business-driven one. Let’s say that 80% of your Customers use Oracle and 20% use Microsoft SQL Server. The Product Owner is entitled to make specific requirements related to the databases supported. So, for example, the specifications can say that the software must work on Oracle, or both Oracle and SQL Server. The Engineering team can’t arbitrarily decide to support a completely different database.
2. Your company provides a cloud-based service and the database is under your control. In this case, it might be up to the Engineering team to choose a database. However, if your current Cloud Operations team only uses MySQL, then the Product Owner can specify that, due to cost factors for Cloud Ops, the system must use MySQL.
3. You are starting a new cloud service and have no current cloud operations or company-standard database. If your product is the first to require a database and there is no other justifiable business reason to mandate a specific database, then the Product Owner cannot specify one.

In the last scenario, the Product Owner can only specify Non-Functional Requirements (NFRs) such as “the database is expected to hold data for up to 1,000,000 users” and “all UI functions should have sub-second response times” (from which Engineering should figure out that database queries must be much less than 1 second) or “the database must not require license fees to meet the budgetary requirements of the overall project”.

We could walk through other specific examples, but here are a (non-exhaustive) list of situations where a Product Owner can be more specific about technology choices:

• When specific technologies or standards are required by Customers (e.g., “it must run on Windows 10 because all computers in the Customer’s Call Center use Windows 10” or “the system must support RESTful JSON API calls because this is the standard in the [insert industry name here] industry”). The requirement should offer proof of why this is a Customer-driven requirement [1].
• When specific technologies or standards are the basis of the marketing value of the product. If the product is being sold as having a SOAP API, the Engineering team can’t unilaterally decide that SOAP is old fashioned [2] and implement a RESTful JSON API. As ancient and uncool as it is, SOAP may be the defacto standard in the industry for which the software is developed [3].
• When specific technologies or standards are less expensive to operate for our Customers or internally. A Product Manager might mandate an open source database, since our Customers tend to be concerned about Operations costs. However, in this case, they cannot mandate a specific open source database.
• When specific technologies or standards are more acceptable to our Customers or internally. On the flip side of the previous point, certain technologies, even if they are free, are too new or unregulated to be accepted to comply with (for example) our internal Information Security standards or (for example) by our banking Customers who don’t mind paying for a well-supported, secure, dependable product.

Outside of these scenarios, as mentioned before, the Product Owner should stick to Non-Functional Requirements that help guide technology choices, but not ones that dictate any specific technology. And, if you read some of the disaster stories in the Introductory Series, you’ll realize that Product Managers need to add more NFRs to their requirements to avoid disasters related to scalability, performance, security, cost and many other factors.

One important implied NFR to never lose sight of is the deadline for the project. Some technical approaches or technologies will need to be rejected solely because they will not be able to be implemented within the time and budget constraints of the project.

I hope this gives both the business team and Engineers a better idea of the boundaries and I look forward to your comments below.

This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker

Footnotes:

[1] Keep in mind that I will always advise Engineers to question requirements with shaky or no evidence.

[2] Make your own jokes here, business people!

[3] Only about three years ago, I had to ask an Engineering team to implement a fax interface for an application because that was the standard technology used within a specific industry (Pharmacies). Some of them didn’t even know what a fax was :).