Requirement intake
Understand business problems raised by headquarters functions and frontline sales.
PROJECT 02 / OPERATING MODEL
SFA Sales Execution Product Line Practice
SFA was not a one-off large project, but a product line that continuously absorbed sales execution needs: I translated complex store-scoring standards into executable system capabilities, and traced permission exceptions back to organizational and store relationships to keep reducing business usage and management cost.
Multiple scenariosSales execution product scope
Closed loopFrom requirement to launch feedback
Continuous governanceFrom feature iteration to relationship model
01 / PRODUCT LINE
The long-term value of SFA is not how many features are launched, but whether business requirements become easier to execute, frontline complexity becomes visible, and repeated issues become maintainable processes, data and relationship models.
Store visitsCampaign executionDisplay inspectionExpense collectionStore scoringMaster dataPermission management
02 / FROM REQUEST TO GOVERNANCE
How a product line keeps forming closed loops
Daily requirements are not a pile of isolated features. Starting from business problems, they pass through rule clarification, productization and launch feedback, gradually becoming maintainable processes and relationship models.
Requirement clarification
Clarify goals, user roles, workflows, fields and judgment rules.
Product solution
Design pages, data formats, configuration logic and permission relationships.
Engineering collaboration
Break down requirements, coordinate resources and handle implementation differences.
Testing and acceptance
Validate functionality, calculation rules, data results and exception scenarios.
Launch release
Complete release preparation, usage support and issue collection.
Continuous governance
Distinguish functional defects, process issues, master-data issues and organizational-relationship issues.
03 / TWO REPRESENTATIVE ITERATIONS
Two cases that validate product-line capability
The two iterations below represent two typical kinds of work: turning complex business standards into system capability, and tracing functional exceptions further back to organizational relationships.
High-potential store scoring
Productizing complex business standards
Business problem
The business team wanted to use more refined store metrics to identify key and high-potential stores, supporting resource allocation and store management.
Mandatory and optional SKUsShelf and display positionsDisplay format and facing sharePrice and stock ageInspection coverage and sub-item scores
Responsibility boundary
The business team was responsible for metric definitions and scoring rules; I was responsible for turning those rules into configurable, executable and traceable product capabilities.
My actions
- Overall product architecture and data format
- Scoring configuration and page display design
- Engineering resource coordination
- Testing and release
Outcome
- The campaign launched successfully, forming a multidimensional store inspection, scoring and tracking flow
- Scoring complexity, frontline input burden and calculation exceptions became issues for later iterations
When headquarters gains single-item management precision, the frontline carries the execution cost of all requirements combined.
Permission relationship governance
Tracing functional exceptions back to business relationships
Business problem
After organizational and regional function adjustments, supervisors and frontline staff experienced invisible stores and approval exceptions.
Organizational relationship changesPosition and personnel affiliationStore visibility scopeApproval-chain exceptions
Responsibility boundary
Under the overall marketing product plan, I led the permission-issue initiative: from exception diagnosis and relationship-model design to business-engineering coordination, testing, launch and result tracking, I was responsible for closing the solution loop.
My actions
- Located root causes
- Mapped organization-store relationships
- Prepared a relationship-model redesign
- Coordinated business and engineering
- Drove testing, launch and result tracking
Outcome
- Invisible-store issues decreased
- The impact of organizational adjustment on permission usage was reduced
- Later organizational adjustments did not trigger large-scale recurrence of similar issues
Repeated permission failures are often not page-configuration problems; they reflect dynamic business relationships that the system has not expressed stably.