Welcome to our Community Week MVP Insights series! Join ServiceNow MVP Isaac Vicentini as he dives into lessons from real ServiceNow projects about how technical leads can elevate requirements gathering, clarify user needs, and translate them into actionable technical work.
Before Development Begins
As technical leads, we often think our role starts when development begins, but the truth is, our greatest impact happens before a single configuration or script is created.
In this article, I’ll share lessons from real ServiceNow projects about how technical leads can elevate requirements gathering, clarify user needs, and translate them into actionable technical work.
These practices save time, prevent rework, and help bridge the gap between business vision and technical execution.
The Role of the Technical Lead
A technical lead is not just a blocker remover or a code reviewer.
Your influence extends to the most critical phase of any project: Defining what will be built and why.
Broad Vision
Go beyond technical implementation. Understand the business context, user needs, and the downstream impact of every change.
Ask yourself: How will this affect the end user, the process, and the platform?
Preventing Rework
Well-defined requirements are the foundation for avoiding costly rework and unproductive delivery cycles, optimizing both time and resources.
For example, it’s common to see rework in integrations. Why?
Because integrations involve multiple systems, teams, and implicit rules. When requirements aren’t crystal clear, developers make assumptions, and that’s dangerous.
Before building, test the endpoint, understand data formats, identify exception paths, and make sure you’re not discovering these things during development.
Business Impact
Your role is to connect the technical vision to business needs, ensuring that the final product delivers real value.
You’re a translator, not of languages, but of perspectives.
You translate business goals into technical solutions and technical complexity into business understanding.
The Power of Collaboration Moments
Every team has its key moments for collaboration: refinement sessions, planning discussions, or design reviews.
These are opportunities for technical leads to ensure clarity before work begins.
When listening to a new requirement, focus on understanding before proposing solutions.
Ask open-ended questions like:
- “In which scenarios should this field be mandatory?”
- “What happens if this information is missing?”
- “Who uses this functionality and for what purpose?”
These questions reveal the why behind the request, often uncovering hidden needs or misunderstood assumptions.
Understand the Real Problem
One of the biggest risks in any project is assuming the customer already knows the solution. In reality, the customer knows their pain, not the solution.
It’s your job to investigate the root cause before defining the fix.
For example, a customer once requested a scheduled job that would pull thousands of records daily from a third-party system to keep everything in sync. After reviewing their use case, we realized they only needed updates for records that had changed.
We proposed a webhook-based approach where the external system would push updates to ServiceNow in real time.
This reduced load, improved performance, and eliminated unnecessary API calls, saving both time and API quota costs.
That’s what being a consultant means: listen, analyze, and guide.
Bring Clarity to the Backlog
Once you’ve listened and understood, it’s time to ensure everything is documented clearly.
User Stories
A well-written story can be read by anyone on the team and immediately understood. Remove ambiguity, ensure shared understanding, and question anything that feels unclear.
Acceptance Criteria
They’re not decoration; they’re the definition of done.
Good acceptance criteria are specific, testable, and measurable. You might not write them yourself, but as a technical lead, you must validate that they make sense.
Tasks
Even the best user story fails without clear, small, objective tasks. Write tasks that are technical, detailed, and logically sequenced.
Each one should represent a step that can be completed within a workday (about 8 hours).
A Checklist for Quality
Before development begins, confirm that the following are clear and agreed upon:
- Functional Requirements: all user flows, business rules, and use cases.
- Non-functional Requirements: performance, scalability, security, and accessibility.
- Integrations: APIs, systems, data formats, and exception handling.
- Acceptance Criteria: testable and objective success conditions.
If you can confidently check all four, you’re ready to build and avoid future rework.
A Practical Example
Let’s take a simple request:
“I want a UI Policy on the HR Case form so the ‘Document’ field is hidden from the HR Analysts
group.”
At first glance, it sounds clear.
But as a technical lead, you should ask: Is UI Policy the right mechanism? Is the goal to hide the field or to protect the data?
In this case, the correct solution is an ACL (Access Control List), since it enforces security, not just visibility.
Refined story:
As an HR Analyst, I want to view only the essential fields on the HR Case so I don’t access documents restricted to other departments.
Acceptance Criteria:
- The “Document” field on sn_hr_core_case must not be visible to users in the HR Analyst group.
- Access is allowed only for HR Managers and HR Admins.
- Validation tests must confirm the rule across all interfaces.
Tasks:
1. Create a read-level ACL for sn_hr_core_case.document.
2. Configure conditions to allow access only to HR Managers and HR Admins.
3. Test ACL behavior for each user group.
4. Document the change and update internal knowledge base.
That’s how you transform a vague request into a secure, well-documented implementation.
Quality Comes from Clarity
A mature technical lead understands that clarity early on saves weeks of frustration later. Don’t rush the discovery phase; build a foundation that supports scalable, maintainable, and valuable outcomes.
The quality of a delivery is directly proportional to the clarity of its requirements, not the speed of development.
The Triple Focus: Product, Process, and People
A great technical lead balances three elements:
Product: Build features that truly solve business problems.
Process: Streamline workflows for predictability and efficiency.
People: Empower your team, encourage collaboration, and foster trust.
When these three are in sync, projects flow smoothly, teams feel engaged, and the client experiences real value.
Your Turn
Apply these practices in your daily work:
- Invest time to clarify before building.
- Engage your team in understanding the “why.”
- Guide the business with your technical expertise.
- Always think about the impact: on users, on performance, on value.
Be the kind of leader whose work leaves a legacy.
Not just working solutions, but well-designed systems, informed teams, and clients who trust
your expertise.
Questions for Isaac? Leave them in the comments! Mark this post as helpful if you found it as such!
1 Comment
