Questions to ask before implementing a feature
New sprint, you’ve got a new exciting feature ticket to work on. The urge to jump in to code is always high. But rushing in without clarity can lead to wasted effort, poorly designed systems, and flawed products. Worse, it could mean significant rework later.
Few questions you should ask before going all guns blazing on implementation:
Why are we building this feature?
Understand the need for this change. What problem are we trying to solve? Are we confident the end user wants this, or are we assuming about their needs? How does this impact the business of the company?
How well is the feature specced out?
Look at all the details. Who is the target user? Are the acceptance criteria, user flows, and conditional behaviours clearly outlined? Is the feature sliced into manageable iterations? What is the future scope of this feature?
What is the definition of success?
Defining success is essential to understand how well a feature performs once live. Ensure all metrics are identified, the necessary instrumentation is in place to measure user decision points, success & failure scenarios.
When do we want to go live with this feature?
This may seem obvious, but it’s vital to clarify the timeline and deadline. Consider any parallel development - do they complement or obstruct this work? Is the feature dependent on other parts of the system being ready?
Design clarity
Are all the possible flows defined and illustrated correctly - success, failure and loading? Has the design been approved by stakeholders? Do we expect any change in designs, if yes how will they be communicated and managed during development?
More questions if you are a team lead or a manager:
Effort vs Impact
Is the impact of this feature worth the effort required to build it? Think about whether this is the highest-value task to focus on right now. Or if resources could be better used elsewhere.
Team Readiness
Assess whether the team has the necessary skills and resources to deliver this feature. Will research, prototyping, or additional training be required before starting?
What are the risks of building this?
Consider the possibility of compliance failure, user frustration, increased expenses, loss of users, share or revenue. Identifying and mitigating these risks early can save trouble later.
Getting answers to everything is ideal, but perfect clarity isn’t always achievable.
Urgency and other constraints often demand quick decisions and trade-offs. However, keep asking questions. Striving for clarity should remain a continuous process for building better.