Workload Patterns Matter

Last modification on

TLDR;

Find your customers' workload patterns.

Every PM should ask themselves: What did my feature contribute to a pattern?

Notes:

For platform products, product managers need to discover: Workload Patterns.

Why do these difficulties often arise?

  1. Product managers of different modules seem to be working according to their own priorities, but when users start using the product, various problems arise and experience sucks.
  1. Sales and Solution Architects seem unable to clearly explain which scenarios are most suitable. There is no efficient way to qualify-out through PoC attempts. The scenario that seems to be suitable may end up losing in the technical PoC.
  1. R&D often falls into the dilemma of 'wanting both', but cannot explain why

If you are facing similar difficulties, chances are that you already have some customers and achieved some success, but the key to the next step is to find the Workload Pattern. Usually, when we look for commonalities, we use a top-down approach, such as classification based on industry/scenario, such as an online payment system for a bank, or an inventory management system for an e-commerce platform. However, for platform products (for example: databases system), just having top-down classification is not enough. For example, the technical architecture used in two different banks' payment systems may be completely different, or the same SQL workload may belong to completely different scenarios in different industries. This is normal.

For platform product planning, not only top-down but also bottom-up approach is needed. Take a database product as an example:

  1. What are the common SQL statements?
  1. What are the common cluster topologies and scales?
  1. What are the common operation and maintenance methods? And cost?
  1. What did users use to solve problems before using your product? Why should they use your product?

Especially for database software, question 1 is crucial. Every product has its comfortable scenarios, and usually the SQL in these scenarios will have certain characteristics. Every product manager should ask themselves a core question: what did my feature contribute to this pattern (or limit it)?

Why are Sysbench/TPC-C/TPC-H not enough? Simply put, business in the real world is more complicated, and it is difficult for developers to directly map business scenarios to standard benchmarks.

When you can summarize the features of your successful customer scenarios bottom-up, congratulations, you are not far from finding a replicable PMF, and these should be the directions your product roadmap should contribute to. The remaining work is to convert these patterns into top-down business value, so top-down is still necessary because you need to explain the value and increase confidence to the decision makers of your customers, which your marketing team understands.