​
Before You Build: The Architect’s First Job

The success of a 📋 Function is determined long before you configure your first Workflow. The architect’s first and most important job is not to build, but to understand. Building an elegant solution to the wrong problem is a common path to failure. This initial step is the foundation upon which your entire solution will rest.
This phase is about asking the right questions to uncover the real business need. A well-defined problem is already half-solved. Rushing this step often leads to rework and a solution that doesn’t deliver the expected value.

​
Phase 1: Requirements Analysis — Understanding the “Why”

Before you can design the ideal future state, you must gain a deep and empathetic understanding of the current reality.

​
1. Identify the Core Pain Point

Start by articulating the central problem in a single, clear sentence. What is the primary business pain that this Function is intended to solve?
  • Bad Example: “We need a CRM.” (This is a solution, not a problem).
  • Good Example: “Our sales team loses track of new leads because they are managed across three different spreadsheets, causing slow and inconsistent follow-up.”

​
2. Interview Stakeholders

You are not building this Function for yourself. Conduct short interviews with the people who will actually use and benefit from it. Ask different questions based on their roles:
  • To End-Users (e.g., Sales Reps): “What is the most frustrating or time-consuming part of your current process? If you had a magic wand, what would you change?”
  • To Managers (e.g., Sales Manager): “What data do you need to make better decisions? Where do you lack visibility into your team’s performance?”
  • To Executives (e.g., VP of Sales): “What is the strategic business outcome we are aiming for with this initiative? (e.g., increase market share, reduce customer churn).“

​
3. Map the “As-Is” Process

Visually map the current workflow, even if it’s just a simple flowchart on a whiteboard. This will immediately highlight redundancies, bottlenecks, and opportunities for improvement that stakeholders might not even be aware of.

​
Phase 2: Scope Definition — Drawing the Boundaries

Once you understand the problem, your next task is to define the boundaries of your solution. A clear scope prevents “scope creep”—the tendency for a project to grow uncontrollably—and ensures you can deliver value quickly.

​
1. Define “In-Scope” vs. “Out-of-Scope”

Be explicit about what this first version of the Function will and will not do.
  • In-Scope: “Track leads from creation to qualification.” “Automate follow-up reminders.” “Provide a dashboard of lead sources.”
  • Out-of-Scope: “Handle customer invoicing.” “Manage marketing email campaigns.” (These could be separate Functions later).

​
2. Prioritize with MoSCoW

Use the MoSCoW method to categorize features and requirements for your first release:
  • Must-Have: The Function is useless without these. (e.g., Ability to create a new lead).
  • Should-Have: Important, but not vital for initial launch. (e.g., Automated lead scoring).
  • Could-Have: Desirable but can be added later if time permits. (e.g., Integration with a mapping service).
  • Won’t-Have (This Time): Explicitly excluded to be considered for a future version.

​
3. Define Success Metrics

How will you know if your Function is successful? Define clear, measurable metrics from the start.
  • Bad Example: “Improve sales.”
  • Good Example: “Reduce average lead response time from 24 hours to 2 hours within the first month.” or “Increase lead-to-deal conversion rate by 10% in the first quarter.”

​
What’s Next?

With a clear problem statement, a defined scope, and measurable success criteria, you are now ready to start the actual design work. The next step is to translate these business requirements into the core data structure of your Function.