I’m often reminded that even experienced executives, salespeople, project managers, and business analysts have different processes and ways of working. Not everyone has had the same opportunities or experiences when it comes to executing software projects. We all come from different backgrounds, and not everyone has had the benefit of hands-on experience across the full project lifecycle. Over time, some may become removed from day-to-day operations and lose sight of the detailed steps required to implement a project successfully.

The process I describe here is one I’ve developed in collaboration with various teams, across multiple agencies, and on dozens of projects—while working in roles spanning development, project management, sales, and strategy. It has evolved through trial and error and been refined through real-world application. While it’s framed around frontend user interfaces (or “theme” implementation) for ecommerce websites, I’ve found it flexible enough to apply to almost any software project—including fully custom implementations.

Following this structured feature implementation process allows projects to run more smoothly, improves estimate accuracy, sets clearer client expectations, and ultimately leads to higher-quality outcomes—efficiently and effectively.

Initiating the Process

The following process outlines the standardized steps for implementing any new feature, regardless of when it is identified:

This process is triggered whenever a new feature is requested—whether it arises before the project is sold, during discovery, during implementation, or after launch as part of ongoing maintenance.

---

Step 1: Gather Preliminary Requirements

Before a solution can be designed or implemented, the team must develop a clear understanding of the feature’s purpose, behavior, and business value. This step focuses on capturing the preliminary high-level business requirements directly from the client. At this stage, the goal is to define what is needed, not how it will be implemented.

1. Obtain System Access
   Secure access to any relevant systems, platforms, or environments that support feature evaluation or discovery. Early access helps surface platform constraints or opportunities that may affect the solution.

2. Gather Preliminary Requirements
   Conduct discovery with the client—typically through calls or written communications—to understand the business objectives, user needs, and functional expectations of the feature.

3. Document Preliminary Requirements
   Summarize the requirements in a centralized format, capturing key functionality, edge cases, open questions, and any available references or examples. This may be as little as one sentence. (Often this can be found within the Statement of Work, if it exists.)

4. Obtain Approval of Preliminary Requirements
   Review the documented requirements with stakeholders to confirm alignment. Address gaps or clarifications as needed and secure formal approval before proceeding to solution discovery.

Accountability for this step is typically owned by the Salesperson, the Project Manager (PM), or the Business Systems Analyst (BSA), acting as the initial point of contact for receiving and documenting the feature request.

Estimate Accuracy: Low (≈30–50%)
At this stage, estimates are inherently rough and broad. The focus is on identifying what the client needs, not how it will be implemented. Without a defined solution or technical details, any estimate is likely to be range-based or padded to account for unknowns in feasibility, effort, and complexity.

---

Step 2: Solutions Discovery

Different implementation options may carry distinct tradeoffs, costs, and technical implications. Before creating mockups or finalizing technical specifications, it is essential to evaluate potential solutions and align with the client on a selected path forward.

1. Explore and Evaluate Solutions
   Investigate viable implementation options, which may include custom development, leveraging platform-native capabilities, or prebuilt third-party integrations. Assess each solution’s feasibility based on business requirements, system constraints, and technical dependencies. Provide demos or visual walkthroughs to help the client understand how each option addresses their goals.

2. Document Proposed Solution(s)
   Based on the evaluation, present one or more possible solutions, but clearly recommend a single preferred solution. Include a high-level technical approach for the recommended path, covering relevant architectural considerations, system interactions, integration points, and known limitations. The documentation must clearly outline the pros, cons, and any high-level concessions or tradeoffs associated with the recommendation. The purpose is to present the rationale behind the recommendation—not to define every implementation detail.

3. Obtain Approval of Solution
   Present the available options and the team’s recommended solution to the client. Facilitate discussion to ensure that the client understands the tradeoffs and implications of each path. The goal is to reach a decision and confirm a single selected solution. Once confirmed, the team can proceed with mockups (if applicable) and define the detailed technical approach in Step 3.

4. Create Task Tracking (“Stub”/Outline) Tickets
   Establish a high-level “stub” ticket or an initial set of tickets for the feature, broken down by known, predictable tasks and subtasks (e.g., Design, Implementation). The scope of these preliminary tickets is limited to the preliminary requirements and proposed solution details approved in this step. This ensures the feature’s progress, including time spent in planning and design, is immediately visible, tracked, and prioritized. Note that the need for additional tickets may emerge during future steps; this generally constitutes a scope change.

Accountability for this step is typically owned by the (Sales) Solutions Engineer or the Business Systems Analyst (BSA), who evaluate viable options and recommend a single path forward.

Estimate Accuracy: Moderate (≈50–75%)
With a preferred solution identified, there is now better visibility into technical direction and complexity. However, estimates remain moderately accurate due to remaining unknowns such as detailed technical requirements, UI decisions, or integration constraints.

---

Step 3: Implementation Planning

Once a single solution has been confirmed, the team must establish a clear, detailed plan for how the feature will be built. This step involves validating and refining client expectations, aligning technical stakeholders, and preparing the documentation needed for developers to begin work confidently.

1. Finalize Design and Scope (when UI changes are required…)
   This phase ensures all visual and interactive requirements are defined and signed off before detailed technical planning begins.

   1. Obtain UI Mockups¹
      If the feature includes new or modified user interface components, request mockups from the design team. Designers should conduct client workshops, reviews and incorporate feedback into final designs.² The goal is to resolve ambiguity early and ensure that all visual and interactive aspects of the feature are well-defined.

   2. Obtain Approval of UI Mockups
      Present finalized mockups to the client for review. Address any outstanding questions or revisions. Approval of these mockups serves as a visual contract for the scope and design of the feature.

2. Define Acceptance Criteria
   This phase establishes the measurable conditions that must be met for the feature to be considered successfully completed (“done”).

   1. Document the Acceptance Criteria: Define clear and measurable acceptance criteria that describe what successful completion of the feature looks like. Each criterion should be specific, testable, and aligned with business objectives and user needs. Document these criteria in a central location (e.g., requirements document, ticket, or feature brief) to ensure shared understanding across teams.

   2. Obtain Approval of Acceptance Criteria
      Share the documented acceptance criteria with key stakeholders, including project managers, product owners, and client representatives. Review each criterion together to confirm mutual understanding and agreement on what will constitute “done.” Formal approval indicates that the feature’s success conditions are clearly defined and accepted by all parties.

3. Define Technical Approach
   This phase translates the approved requirements and design into a comprehensive plan for development and serves as the final gateway before implementation begins.

   1. Document the Technical Approach
      Create a comprehensive technical specification that describes how the feature will be implemented. This should include system architecture, data flows, APIs, component interactions, and any third-party integrations or dependencies. Clearly identify assumptions, constraints, and known limitations. This document serves as the blueprint for development and should be detailed enough for engineers to begin work without additional clarification.

   2. Obtain Approval of the Technical Approach
      Present the documented technical approach to relevant stakeholders, including technical leads, project managers, and client representatives. Review the proposed design, confirm alignment on implementation details, and verify that it supports the agreed acceptance criteria. Formal approval signifies that the team is ready to proceed to development without further discovery or solutioning.

Accountability for this step is typically coordinated by the Project Manager (PM), who directs the planning beginning with the Designer (mockups) deliverables, followed by the Business Systems Analyst (BSA) (acceptance criteria), and concluding with the Tech Lead (technical specification).

Estimate Accuracy: High (≈75–90%)
At this point, the full implementation plan is documented, including system architecture, workflows, user experience, and known limitations. Most major risks have been addressed, and remaining variability tends to come from minor edge cases or unforeseen technical challenges.

---

Step 4: Implementation

Once the technical plan is approved, the team proceeds with execution. This phase involves building, testing, documenting, and validating the feature to ensure it meets expectations and integrates successfully into the broader system.

1. Implement the Solution
   Begin development in accordance with the approved technical documentation. Assign tasks and track progress using the designated project management tools. Developers should follow coding standards, reuse shared components where appropriate, and log key decisions made during implementation. Conduct regular check-ins and peer reviews to maintain alignment and ensure code quality.

2. Test the Implementation
   Perform thorough quality assurance (QA) to verify that the feature behaves as expected, including under edge cases identified during earlier phases. Testing should validate both functional and non-functional requirements (e.g., performance, security, responsiveness). Document and resolve any defects before client review.

3. Create Instructional Documentation
   If the feature requires end-user interaction or client-side configuration, prepare clear documentation that explains how to use it. This may include written instructions, annotated screenshots, or demo videos. Instructional documentation should be created before client review, as it often helps guide their testing and improves the approval process.

4. Obtain Approval of Implementation
   Once internal QA and documentation are complete, present the feature to the client for review (User Acceptance Testing/”UAT”). This may involve a live demo, access to a staging environment, or shared recordings. Capture feedback, make any necessary adjustments, and obtain formal sign-off before proceeding to deployment.

Accountability for this step is divided between Development (building the feature), QA (testing), and the BSA or Client (User Acceptance Testing/UAT).

Estimate Accuracy: Very High (≈90–100%)
With development underway, estimates are highly reliable. Work is being tracked in real time, and variance from the plan is minimal. While unexpected discoveries and edge cases can still emerge, generally adjustments at this stage are small refinements, making estimates highly reliable.

---

Step 5: Release (Deployment)

After client approval, the feature must be deployed using a structured, well-coordinated release process. This ensures a smooth rollout with minimal disruption and clear communication to all stakeholders.

1. Prepare the Release
   Document a clear summary of what is being released, including the feature’s purpose, key functionality, configuration requirements, and any follow-up actions. Tailor the content to your audience (e.g., technical teams, client stakeholders, end users), and highlight known limitations or caveats. At the same time, coordinate with the client and internal stakeholders to schedule the release. Ensure the timing aligns with business priorities, user readiness, and any relevant blackout periods or dependencies. If needed, involve QA, DevOps, and other cross-functional teams to prepare for deployment.

2. Deploy the Feature
   Execute the deployment using the approved procedures. Confirm success through post-deployment validation such as smoke testing, monitoring logs, and verifying feature functionality in the live environment.

3. Obtain Approval of Release
   Communicate the successful deployment to relevant stakeholders. Share release notes, outline any required next steps, and confirm that the release meets expectations. Provide support channels for feedback or issues, and secure formal acknowledgment from the client that the feature has been successfully released.

Accountability for this step is typically managed by the Tech Lead or the DevOps team, who coordinate the deployment.

Estimate Accuracy: Certain (100%)
rakThe feature is functionally complete and approved by the client. Final deployment represents the end of scoped implementation work. Post-release effort may still be required to address bugs, edge cases, or user feedback.

---

Choosing Between Waterfall and Agile Approaches

The feature implementation process described above can be applied within either a Waterfall or an Agile project management model. Each approach offers distinct benefits and tradeoffs, serving different purposes depending on the stage of the project and the priorities of stakeholders.

Waterfall: Best for High-Confidence Scope and Estimates

A Waterfall process is a linear, milestone-driven approach where each phase must be completed for all known tasks before the next phase begins. All work is blocked until a certain level of completion or clarity has been achieved for all known tasks.

Use Waterfall when:

• Estimate accuracy is critical, and stakeholders must make go/no-go decisions based on comprehensive scope and cost information.
• Budget or timeline constraints are inflexible, and failure to meet them could cancel or derail the project.
• Clients require full clarity before committing, such as before signing an SOW or initiating development.

Examples:

• A technical solution must be fully identified for all requested features before a contract is signed. (To ensure scope accuracy.)
• All UI/UX designs must be finalized and approved before any development begins. (To avoiding rework.)

Waterfall enables scoping rigor and estimate confidence—key ingredients for establishing presales contractual and financial commitments; it supports more predictable outcomes and minimizes rework, but may require more upfront time to complete discovery and/or design phases.

Agile: Best for Progress and Adaptability

An Agile process emphasizes iterative progress and flexibility. Work on various tasks can proceed in parallel, even if other areas of the project remain undefined.

Use Agile when:

• The priority is delivering value quickly, not upfront scope certainty.
• Scope is expected to evolve, and stakeholders are comfortable adapting to new insights as work progresses, even if this results in rework.
• Stakeholders are aligned with an iterative workflow, where budget and timeline may shift as the scope evolves.

Examples:

• Development begins on homepage components while the design team is still working on the Product Detail Page.
• Some features may change mid-project based on client feedback or technical discovery which may result in refactoring prior work.

Agile supports early momentum and just-in-time learning—accelerating delivery while introducing greater variability in timelines and budgets due to incomplete discovery at the outset.

---

Purpose of a Discovery Checklist

A discovery checklist is a strategic tool used during the early stages of project planning to identify what needs to be implemented—not how it will be done. Its primary goal is to uncover the features that are required before more detailed scoping begins.

A discovery checklist is a feature identification aid—its purpose is to generate a comprehensive list of features that require further scoping and estimation. It does not produce an implementation plan or an estimate on its own. For each feature uncovered when using a discovery checklist, the implementation process outlined above must be followed in order to obtain a scope and estimate.

By systematically reviewing key functional areas and facilitating in-depth discussions with stakeholders, the checklist ensures that all critical features of the project have been identified. This organized approach minimizes the risk of overlooking key features that might otherwise be assumed or missed during initial scoping.

While using a discovery checklist does not guarantee that every functional need will be identified, it significantly reduces the likelihood of missing features. As a result, it improves the accuracy of future scope definition and project estimation.

A discovery checklist is one of several tools available for identifying features. For instance, a component inventory may be better suited for pinpointing specific requirements within a theme. These early-stage tools are meant to generate a preliminary list of elements to be explored in greater depth during future steps of the implementation process.

---

How the Implementation Process relates to Estimate Accuracy

As a feature progresses through the implementation process, the accuracy of any associated time or effort estimate improves. Early estimates are inherently imprecise due to limited information and evolving requirements. As more is learned—through discovery, solutioning, and technical planning—unknowns are reduced and estimates become more reliable.

The table below illustrates how each phase of the implementation process correlates with estimate accuracy, along with the intended purpose of the estimate at each stage. Understanding this relationship helps set realistic expectations with stakeholders and supports better planning across the lifecycle of a feature.

Note: A discovery checklist feeds into Step 1, meaning any estimate derived from it is only as accurate as the preliminary requirements gathered—and should be treated accordingly.