Before You Write Code, Ask Better Questions

When embarking on software development, particularly for a SaaS platform, it's crucial to start with a solid foundation of understanding the underlying business requirements. A common mistake is to jump directly to coding, assuming that developers can accurately interpret vague client requests. However, this approach often leads to building the wrong system, even when the code itself is well-written.

The process of creating great software begins with great questions. This involves transforming business goals into user problems, then into clear requirements, data structures, workflows, architecture, and finally, implementation. Breaking this chain at any point can lead to building a flawed system.

A key issue in software development is the ambiguity surrounding requirements. Consider a simple requirement: "Managers can manage employees." The interpretation of what "manage" entails can vary widely, affecting everything from database structure to UI workflows, security measures, testing, and even operational costs. Establishing clear requirements is essential to avoid these problems.

Requirements should not be confused with features. For instance, a client requesting a "dashboard" doesn't specify the problem they're trying to solve. Instead, the real issue might be that finance managers need an easy way to identify overdue customer payments. This transforms the requirement into something more useful: "Authorized finance users must be able to identify overdue customer balances and prioritize collection actions."

The final feature could be a payment aging dashboard with features such as filtering, notifications, and a collection workflow.

To uncover these requirements, engineers need to ask three critical questions when presented with a requirement: "Why?" to understand the business problem; "What?" to determine the necessary system capability; and "Under What Conditions?" to identify any rules, permissions, or constraints. For example, the requirement to transfer organization ownership becomes much clearer when asked why (the current owner is leaving), what (ownership must be transferred to another member), and under what conditions (the target must belong to the organization, cannot transfer to themselves, and must be approved, among others).

Requirements often emerge from conversations, observations, existing systems, documents, and prototypes. To discover these requirements, engage with people to explain their workflows. When building an expense management system, asking, "Do you need expense approval?" is less effective than asking, "What happens when an employee submits a $500 expense?"

This might reveal a complex workflow involving multiple approvals, validations, and audit trails, suggesting that the real requirement might be to "reduce manual reconciliation effort while preserving traceable exception handling."

Stakeholders often have different expectations based on their departments. HR may want managers to edit employee information, while finance might argue that managers shouldn't edit salary information. Security might require all sensitive changes to be audited. By bringing stakeholders together in workshops, these contradictions can be resolved before implementation begins.

Leveraging existing systems can also provide valuable insights. When replacing an old system, study its workflows, spreadsheets, reports, APIs, database schemas, approval forms, and policies. Existing software often contains accumulated business rules that may hold the key to the real requirements.

In summary, great software starts with great questions. By focusing on understanding the underlying business requirements, breaking down the requirement-to-implementation chain, and uncovering implicit requirements through conversation, observation, and stakeholder collaboration, developers can avoid the pitfalls of building the wrong system and deliver solutions that truly meet the client's needs.