Insights
The Reasonable Expectation Principle of Product Management
We all are customers of products and services, both in our personal and professional lives. The overarching requirement is that what we buy meets our expectations for functionality and quality for the price we pay. Regardless of your industry or development methodology (waterfall or agile for example), I suggest that product teams do not lose sight of the reasonable expectations of their customers.
The product team is often thought of as a trio consisting of engineering, operations/manufacturing, and product management. Different organizations may emphasize different responsibilities for product managers. While my activities at Company A may differ somewhat from your activities at Company B, product management teams are typically responsible for product requirements and being the voice of the customer to the product team.
Product development is a challenging balance of too many features, scarce resources, and time-to-market constraints. There are requirements that can and need to be captured formally in a product requirement document (PRD) or user stories. Many of these requirements may be traceable to a technical standard, regulation, or specific line in a customer's request for proposal document. Some other requirements may not get formally captured for a number of reasons.
I find that when engineering asks product managers how the customer wants something or if it is acceptable for the customer deliverable to have a particular issue, the question can often be answered based on the customer's reasonable expectation especially when the team has a strong customer relationship and understands the product applications.
For example when you order a meal at a restaurant, you expect a cold dish to be served cold, a hot meal to be served hot, and all meals are served to your table at the same time. Meals being served to the table simultaneously in a timely manner is analogous to a product development release: all committed features complete and included in the release on the promised date. If development (the kitchen) has a challenge with one feature (a meal), then should the customer with the late meal be forced to tell the table to "please go ahead and eat without me" or "please everyone wait for my meal"? By the way delay negotiation should be done earlier — when the waiter took the order: broiled seafood dinners may take longer.
Another example, every driver I know expects the windshield wipers to work at the selected speed regardless of the transmission gear, the headlights, or the song playing on the radio. Can all of your product features that can be turned on at the same time work at the same time? If not, the customer's reasonable expectation may not be met.
Customers, or product managers as their advocate, do not always have a "voice", especially with new products and services. And if you ask customers too many questions with obvious answers, then you may get some odd looks. What is your requirement for the temperature of your baked potato?
I am not trying to trivialize the product team's process to accomplish their mission. And quite frankly, this is not a product management principle as much as a good fundamental business practice. A foundation of strong product application knowledge and customer intimacy is critical for the product team to understand the reasonable expectations and requirements.
For success do not get too caught up in the technology, development processes, and any other challenges and lose sight of what your customers would reasonably expect of the product — think as if you are the customer for your own product.
Published on LinkedIn