“Make the application faster” needs a more precise requirement.
Faster for someone opening a dashboard? Submitting a request? Waiting for an export while dozens of colleagues do the same? Databricks’ November 5 scaling guide starts with an approach I appreciate: define the user journeys, peak demand, and response-time targets before choosing additional computing capacity.
That connects with my work translating operational needs into enterprise applications, integrations, and reporting. Consider a facilities reporting tool. Opening a work-order summary and generating a detailed annual cost export are different workloads. They deserve different expectations—and potentially different ways of running. I would describe the requirement in terms users can recognize: the summary should open within an agreed time during the morning rush; the export should show progress and let the user return for the result. Then measure the complete experience, including slower requests and busy periods. Those measurements give developers and stakeholders a shared basis for deciding what to improve. Before the next performance discussion, choose one important user journey, define an acceptable experience, and test it under expected peak demand. That turns a broad request into a requirement the team can verify.
#ProductManagement #EnterpriseSoftware #SoftwareEngineering