07
Stage 1
Business Use Case
“Beauty is in the eye of the beholder”
The quest to meet and hopefully exceed stakeholders’ expectations when developing a new application can be like the quest for true beauty — it’s always seen in the eye of the beholder. And in most cases, there will be plenty of beholders. Ask 10 different people within your organization what they expect from the app, and you’ll likely hear 12 different opinions! With all the possible different ideas and perspectives on what constitutes “success,” it’s easy to get caught up in seeking to please all stakeholders. If you do this, you risk losing focus on the high-priority requirements that must be met for your app to be successful.
Therefore, it’s critical to begin with a clear and focused understanding of the essential business requirements before you dive into designing and building your app. This is the intent of the first stage of the no-code methodology — the Business Use Case, which will define the intended business requirements and outcomes. The business use case should be in clear and simple language and defined by the designated business sponsor of the application.
It may be tempting to rush through this stage in the excitement of building apps. This can be especially true for no-code apps, given how easy and simple no-code tools are. It can seem easy to start defining the application by diving straight into the rapid construction of forms and workflows. Yet, even with no-code, you will still fail to deliver on expectations if you haven’t thought through the business requirements upfront. So, it’s important not to skip this stage. Make sure you have captured the essential business vision. Most applications that fail to meet business needs fail at this stage in the process, so pay careful attention to the business use cases.
Understanding the Development Requirements Pyramid
The term “requirements” is often overloaded with many loose meanings. It can cover a broad range of statements about what an application must do. Throughout any application development project, there is typically a broad spectrum of requirement statements gathered — from high-level business statements (“what” are the outcomes that must be achieved) down to highly detailed technical statements (“how” should the application be built). To help provide clarity on what we intended for the Business Use Case stage, refer to the Development Requirements Pyramid.
The Pyramid divides requirements into three levels: business, user, and system.
-
The business requirements focus on the project goals and objectives. It defines the business process at a high level that is being automated or transformed by the application. Sitting at the top of the pyramid, this level is the primary focus of our Business Use Case stage.
-
The user level of requirements sits in the middle and begins to capture more detailed information about the functionality your app will need. It’s typically expressed through a user’s eyes. In traditional software development, these detailed requirements are often developed using intermediate design artifacts, such as user stories or user journeys, to describe both user flows and inputs/outputs of the app. This is not in scope for the Business Use Case stage, but we will discuss how similar considerations are captured later during the Design and Prototyping stage.
-
The system level of requirements is at the base of the pyramid and addresses nonfunctional and system requirements, typically describing the technical details of the application, such as platforms supported, APIs, and required environments as well as quality attributes and service levels (e.g., response time and performance/throughput). This is not in scope for the Business Use Case stage either because when you’re developing a no-code app, the no-code platform typically abstracts these considerations. The system requirements typically undergo a thorough assessment during the software selection process for your no-code tools.
At its most simplistic level, the business use case should define the following: no-code stakeholder, business processes, process use cases, process consistency, and success criteria. We’ll briefly look at each of these key elements as follows.
No-code stakeholder
The no-code stakeholder is the primary business owner of the requirements and is the person ultimately accountable and responsible for representing the sponsoring business function or unit. There should only be one business owner, and they will act as the ultimate viewpoint when it comes to making any decisions on requirements or priorities.
Business processes
The best way to frame the requirements for a no-code app is by describing the highest-level definition of the business processes that will be addressed. Any application ultimately will either automate a new business process or digitize an existing one. Starting with the business process frame of reference enables you to describe the app in a way that is easily mapped to the business function.
Process use cases
A business process will typically consist of multiple subprocesses. Getting more granular in your description is an important part of defining the business scope. You will want to describe the business vision by decomposing the impacted process into smaller units, often referred to as process use cases, which will be addressed by the app. Do not yet start to artificially narrow the scope down to the initial release. Keeping the business vision broad is important in this stage. We will discuss how to address scoping the first release later in the Project Assignment stage in Chapter 10.
Best practice tip:
Drilling into successful techniques for process decomposition is outside the scope of this book. Thankfully, however, there are a lot of resources available to help if you are new to this activity. Most business analysis training or handbooks will include tips and practices for process decomposition as a core concept.
Process consistency
While a high-level process may seem globally consistent at first, as you decompose it into more granular process use cases, you may often find variations in implementations across the organization based on regional or business unit differences. The business use case should describe where known variations exist and discuss the desired target state for the business function (do they remain highly autonomous or should they become entirely globally consistent?). This will be further analyzed during the Design and Prototyping stage.
Success criteria
Lastly, how do you measure success? When will you know the initiative has been completed? The no-code stakeholder should specify this because they will most likely be held accountable to these success criteria by their leadership. Getting clear and measurable on the success criteria is critical as this will be essential when defining the initial release and the app’s ongoing evolution.
The participants contributing to this phase will usually come from within the business function itself to ensure that it’s as close to the front line and operational function as possible. Typically, the key roles (discussed in Chapter 4) who will contribute to the work activity include the no-code stakeholder and the no-code architect. It may also include a no-code creator as a way to ramp some members of the actual development team into the early definition of the project scope. These resources will almost always be directly from the business group (function or unit) that has chartered the application and should have deep domain and subject matter expertise about the business process and functional requirements.
Real-world no-code example: Territory Management Application
Let’s put this in action by presenting a short example based on a use case for a no-code application built by a fast-growing outsourcing company. The company sought to accelerate its revenue growth with a new solution for automating territory management for enterprise customers.
No-code stakeholder
The primary owner within the business is the VP of Sales who is responsible for growing the sales funnel with qualified enterprise opportunities.
Business processes
The company builds its sales pipeline through multiple sources, including inbound lead generation, channel partners, and outbound activity. The territory management approach is meant to streamline and boost the outbound activity by introducing a well-structured process focused on selected enterprise accounts. The process will be executed by the enterprise sales team. Each sales rep will receive 30 target accounts with up to 20 associated personas. The goal of the enterprise rep is to generate and qualify sales leads by matching personas with the company’s possible solution use cases.
Process use cases
Territory management can be further decomposed into these use cases:
-
The ability of the sales team to assign accounts to each team and individual rep. Access to the assigned accounts and the ability to segment them based on different criteria.
-
A 360-degree view of the assigned account.
-
Ability to upload and view the associated contacts (including needed details) within the account with the ability to specify role and engagement strategy.
-
Ability to manage engagement cadences with the account — plan, execute, and report activities (calls, emails, messages, and meetings) per each associated and validated contact.
-
Proactive alerts (marketing touches, responses, news, and scoops) associated with the account.
-
Ability to generate leads and opportunities within the account.
-
Ongoing access to engagement-based key performance indicators (KPIs) in different dimensions — teams, individual reps, territories, etc.
Process consistency
In this example, the process followed by each of the regional sales teams (The Americas, EMEA, and APAC) has a fair amount of variability depending on regional priorities, assigned verticals, and strategies. It was decided in this case that the teams would move to this new territory management app to standardize around a globally consistent process across regions to gain greater efficiency and ease overall organizational sales execution.
Success criteria
The success criteria for the new no-code app were centered around increasing the overall volume of the qualified pipeline. This included increasing:
-
Annual recurring revenue generated from the territory.
-
Pipeline volume created from the territory.
-
Number of opportunities promoted within the territory.
-
Number of sales qualified leads generated from the territory.
-
Conversion rates.
Tips on Best Practices
-
Let the no-code stakeholder explain the business use case in a simple way with a focus on expected value and business goals.
-
Stay at the right level of detail by focusing on the “what” and the “why” but not the “how”; focus on higher-level requirements and business processes and avoid discussing detailed recommendations regarding the foreseen solution (e.g., what fields or objects shall be used, etc.).
-
Understand the workflow and outcomes first.
-
Provide real-life examples to support the business requirements.
Final Takeaways
It’s easy to be impatient and push to get started quickly. However, as John W. Bergman famously said, “There is never enough time to do it right, but there is always enough time to do it over.” Likewise, it may not seem as if there is enough time for a proper business use case, but this upfront investment will help eliminate a lot of downstream errors and wrong decisions later.
The Business Use Case stage can be the most important part of the entire lifecycle because it helps identify your target and how you will measure success. Resist the temptation to skip or rush through this process. Instead, thoughtfully identify as clear of a definition as possible — this will act as the “true North” that will keep the team on track throughout the project and the evolution of the app.
As you start turning the business use case into a high-level architecture for your application, you’ll need to start making some key choices. How do you pick the right components? In the next chapter, we will explore how to conduct an effective analysis of your options.